diff --git a/_data/versions.json b/_data/versions.json
index 0f20ab0b..40fa7d17 100644
--- a/_data/versions.json
+++ b/_data/versions.json
@@ -1 +1 @@
-[{"version":"v1.3","path":"/docs/v1.3"},{"version":"v1.2","path":"/docs/v1.2"},{"version":"v1.1","path":"/docs/v1.1"},{"version":"v1.0","path":"/docs/v1.0"},{"version":"v0.14","path":"/docs/v0.14"},{"version":"v0.13","path":"/docs/v0.13"},{"version":"v0.12","path":"/docs/v0.12"},{"version":"v0.11","path":"/docs/v0.11"},{"version":"v0.10","path":"/docs/v0.10"},{"version":"v0.9","path":"/docs/v0.9"},{"version":"v0.8","path":"/docs/v0.8"},{"version":"v0.7","path":"/docs/v0.7"},{"version":"v0.6","path":"/docs/v0.6"},{"version":"v0.5","path":"/docs/v0.5"},{"version":"v0.4","path":"/docs/v0.4"},{"version":"v0.3","path":"/docs/v0.3"},{"version":"v0.2","path":"/docs/v0.2"},{"version":"v0.1","path":"/docs/v0.1"},{"version":"master","path":"/docs/master"}]
+[{"version":"v1.3","path":"/docs/v1.3"},{"version":"v1.2","path":"/docs/v1.2"},{"version":"v1.1","path":"/docs/v1.1"},{"version":"master","path":"/docs/master"}]
diff --git a/docs/v0.1/README.md b/docs/v0.1/README.md
deleted file mode 100644
index ff7dc9d2..00000000
--- a/docs/v0.1/README.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Crossplane
-
-Crossplane is an open source multicloud control plane. It introduces workload and resource abstractions on-top of existing managed services that enables a high degree of workload portability across cloud providers. A single crossplane enables the provisioning and full-lifecycle management of services and infrastructure across a wide range of providers, offerings, vendors, regions, and clusters. Crossplane offers a universal API for cloud computing, a workload scheduler, and a set of smart controllers that can automate work across clouds.
-
-
-
-Crossplane presents a declarative management style API that covers a wide range of portable abstractions including databases, message queues, buckets, data pipelines, serverless, clusters, and many more coming. It’s based on the declarative resource model of the popular [Kubernetes](https://github.com/kubernetes/kubernetes) project, and applies many of the lessons learned in container orchestration to multicloud workload and resource orchestration.
-
-Crossplane supports a clean separation of concerns between developers and administrators. Developers define workloads without having to worry about implementation details, environment constraints, and policies. Administrators can define environment specifics, and policies. The separation of concern leads to a higher degree of reusability and reduces complexity.
-
-Crossplane includes a workload scheduler that can factor a number of criteria including capabilities, availability, reliability, cost, regions, and performance while deploying workloads and their resources. The scheduler works alongside specialized resource controllers to ensure policies set by administrators are honored.
-
-For a deeper dive into Crossplane, see the [architecture](https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit?usp=sharing) document.
-
-## Table of Contents
-
-* [Quick Start Guide](quick-start.md)
-* [Getting Started](getting-started.md)
- * [Installing Crossplane](install-crossplane.md)
- * [Adding Your Cloud Providers](cloud-providers.md)
- * [Deploying Workloads](deploy.md)
- * [Running Resources](running-resources.md)
- * [Troubleshooting](troubleshoot.md)
-* [Concepts](concepts.md)
-* [FAQs](faqs.md)
-* [Contributing](contributing.md)
diff --git a/docs/v0.1/cloud-providers.md b/docs/v0.1/cloud-providers.md
deleted file mode 100644
index b08530bf..00000000
--- a/docs/v0.1/cloud-providers.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Adding Your Cloud Providers
-toc: true
-weight: 330
-indent: true
----
-# Adding Your Cloud Providers
-
-In order for Crossplane to be able to manage resources across all your clouds, you will need to add your cloud provider credentials to Crossplane.
-Use the links below for specific instructions to add each of the following cloud providers:
-
-* [Google Cloud Platform (GCP)](cloud-providers/gcp/gcp-provider.md)
-* [Microsoft Azure](cloud-providers/azure/azure-provider.md)
-* [Amazon Web Services (AWS)](cloud-providers/aws/aws-provider.md)
diff --git a/docs/v0.1/cloud-providers/aws/aws-provider.md b/docs/v0.1/cloud-providers/aws/aws-provider.md
deleted file mode 100644
index 4b5dfc2b..00000000
--- a/docs/v0.1/cloud-providers/aws/aws-provider.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# Adding Amazon Web Services (AWS) to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your AWS account to be ready for integration with Crossplane.
-
-## AWS Credentials
-
-### Option 1: aws Command Line Tool
-
-If you have already installed and configured the [`aws` command line tool](https://aws.amazon.com/cli/), you can simply find your AWS credentials file in `~/.aws/credentials`.
-
-### Option 2: AWS Console in Web Browser
-
-If you do not have the `aws` tool installed, you can alternatively log into the [AWS console](https://aws.amazon.com/console/) and export the credentials.
-The steps to follow below are from the [AWS SDK for GO](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/setting-up.html):
-
-1. Open the IAM console.
-1. On the navigation menu, choose Users.
-1. Choose your IAM user name (not the check box).
-1. Open the Security credentials tab, and then choose Create access key.
-1. To see the new access key, choose Show. Your credentials resemble the following:
- - Access key ID: AKIAIOSFODNN7EXAMPLE
- - Secret access key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
-1. To download the key pair, choose Download .csv file.
-
-Then convert the `*.csv` file to the below format and save it to `~/.aws/credentials`:
-
-```
-[default]
-aws_access_key_id = AKIAIOSFODNN7EXAMPLE
-aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
-```
-
-After the steps above, you should have your AWS credentials stored in `~/.aws/credentials`.
diff --git a/docs/v0.1/cloud-providers/azure/azure-provider.md b/docs/v0.1/cloud-providers/azure/azure-provider.md
deleted file mode 100644
index 24dc425e..00000000
--- a/docs/v0.1/cloud-providers/azure/azure-provider.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# Adding Microsoft Azure to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your Azure account to be ready for integration with Crossplane.
-The general steps we will take are summarized below:
-
-* Create a new service principal (account) that Crossplane will use to create and manage Azure resources
-* Add the required permissions to the account
-* Consent to the permissions using an administrator account
-
-## Preparing your Microsoft Azure Account
-
-In order to manage resources in Azure, you must provide credentials for a Azure service principal that Crossplane can use to authenticate.
-This assumes that you have already [set up the Azure CLI client](https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli?view=azure-cli-latest) with your credentials.
-
-Create a JSON file that contains all the information needed to connect and authenticate to Azure:
-
-```console
-# create service principal with Owner role
-az ad sp create-for-rbac --sdk-auth --role Owner > crossplane-azure-provider-key.json
-```
-
-Take note of the `clientID` value from the JSON file that we just created, and save it to an environment variable:
-
-```console
-export AZURE_CLIENT_ID=
-```
-
-Now add the required permissions to the service principal that will allow it to manage the necessary resources in Azure:
-
-```console
-# add required Azure Active Directory permissions
-az ad app permission add --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --api-permissions 1cda74f2-2616-4834-b122-5cb1b07f8a59=Role 78c8a3c8-a07e-4b9e-af1b-b5ccab50a175=Role
-
-# grant (activate) the permissions
-az ad app permission grant --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --expires never
-```
-
-You might see an error similar to the following, but that is OK, the permissions should have gone through still:
-
-```console
-Operation failed with status: 'Conflict'. Details: 409 Client Error: Conflict for url: https://graph.windows.net/e7985bc4-a3b3-4f37-b9d2-fa256023b1ae/oauth2PermissionGrants?api-version=1.6
-```
-
-After these steps are completed, you should have the following file on your local filesystem:
-
-* `crossplane-azure-provider-key.json`
-
-## Grant Consent to Application Permissions
-
-One more step is required to fully grant the permissions to the new service principal.
-From the Azure Portal, you need to grant consent for the permissions using an admin account.
-The steps to perform this action are listed below:
-
-1. `echo ${AZURE_CLIENT_ID}` and note this ID value
-1. Navigate to the Azure Portal: https://portal.azure.com
-1. Click `Azure Active Directory`, or find it in the `All services` list
-1. Click `App registrations (Preview)`
-1. Click on the application from the list where the application (client) ID matches the value from step 1
-1. Click `API permissions`
-1. Click `Grant admin consent for Default Directory`
-1. Click `Yes`
diff --git a/docs/v0.1/cloud-providers/gcp/gcp-provider.md b/docs/v0.1/cloud-providers/gcp/gcp-provider.md
deleted file mode 100644
index 8cca906d..00000000
--- a/docs/v0.1/cloud-providers/gcp/gcp-provider.md
+++ /dev/null
@@ -1,99 +0,0 @@
-# Adding Google Cloud Platform (GCP) to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your GCP account to be ready for integration with Crossplane.
-The general steps we will take are summarized below:
-
-* Create a new example project that all resources will be deployed to
-* Enable required APIs such as Kubernetes and CloudSQL
-* Create a service account that will be used to perform GCP operations from Crossplane
-* Assign necessary roles to the service account
-* Enable billing
-
-For your convenience, the specific steps to accomplish those tasks are provided for you below using either the `gcloud` command line tool, or the GCP console in a web browser.
-You can choose whichever you are more comfortable with.
-
-## Option 1: gcloud Command Line Tool
-
-If you have the `gcloud` tool installed, you can run below commands from the example directory.
-It
-Instructions for installing `gcloud` can be found in the [Google docs](https://cloud.google.com/sdk/install).
-
-```bash
-# list your organizations (if applicable), take note of the specific organization ID you want to use
-# if you have more than one organization (not common)
-gcloud organizations list
-
-# create a new project
-export EXAMPLE_PROJECT_NAME=crossplane-example-123
-gcloud projects create $EXAMPLE_PROJECT_NAME --enable-cloud-apis [--organization ORGANIZATION_ID]
-
-# record the PROJECT_ID value of the newly created project
-export EXAMPLE_PROJECT_ID=$(gcloud projects list --filter NAME=$EXAMPLE_PROJECT_NAME --format="value(PROJECT_ID)")
-
-# enable Kubernetes API
-gcloud --project $EXAMPLE_PROJECT_ID services enable container.googleapis.com
-# enable CloudSQL API
-gcloud --project $EXAMPLE_PROJECT_ID services enable sqladmin.googleapis.com
-
-# create service account
-gcloud --project $EXAMPLE_PROJECT_ID iam service-accounts create example-123 --display-name "Crossplane Example"
-# export service account email
-export EXAMPLE_SA="example-123@$EXAMPLE_PROJECT_ID.iam.gserviceaccount.com"
-
-# create service account key (this will create a `key.json` file in your current working directory)
-gcloud --project $EXAMPLE_PROJECT_ID iam service-accounts keys create --iam-account $EXAMPLE_SA key.json
-
-# assign roles
-gcloud projects add-iam-policy-binding $EXAMPLE_PROJECT_ID --member "serviceAccount:$EXAMPLE_SA" --role="roles/iam.serviceAccountUser"
-gcloud projects add-iam-policy-binding $EXAMPLE_PROJECT_ID --member "serviceAccount:$EXAMPLE_SA" --role="roles/cloudsql.admin"
-gcloud projects add-iam-policy-binding $EXAMPLE_PROJECT_ID --member "serviceAccount:$EXAMPLE_SA" --role="roles/container.admin"
-```
-
-## Option 2: GCP Console in a Web Browser
-
-If you chose to use the `gcloud` tool, you can skip this section entirely.
-
-Create a GCP example project which we will use to host our example GKE cluster, as well as our example CloudSQL instance.
-
-- Login into [GCP Console](https://console.cloud.google.com)
-- Create a new project (either stand alone or under existing organization)
-- Create Example Service Account
- - Navigate to: [Create Service Account](https://console.cloud.google.com/iam-admin/serviceaccounts)
- - `Service Account Name`: type "example"
- - `Service Account ID`: leave auto assigned
- - `Service Account Description`: type "Crossplane example"
- - Click `Create` button
- - This should advance to the next section `2 Grant this service account to project (optional)`
- - We will assign this account 3 roles:
- - `Service Account User`
- - `Cloud SQL Admin`
- - `Kubernetes Engine Admin`
- - Click `Create` button
- - This should advance to the next section `3 Grant users access to this service account (optional)`
- - We don't need to assign any user or admin roles to this account for the example purposes, so you can leave following two fields blank:
- - `Service account users role`
- - `Service account admins role`
- - Next, we will create and export service account key
- - Click `+ Create Key` button.
- - This should open a `Create Key` side panel
- - Select `json` for the Key type (should be selected by default)
- - Click `Create`
- - This should show `Private key saved to your computer` confirmation dialog
- - You also should see `crossplane-example-1234-[suffix].json` file in your browser's Download directory
- - Save (copy or move) this file into example (this) directory, with new name `key.json`
-- Enable `Cloud SQL API`
- - Navigate to [Cloud SQL Admin API](https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview)
- - Click `Enable`
-- Enable `Kubernetes Engine API`
- - Navigate to [Kubernetes Engine API](https://console.developers.google.com/apis/api/container.googleapis.com/overview)
- - Click `Enable`
-
-## Enable Billing
-
-No matter what option you chose to configure the previous steps, you will need to enable billing for your account in order to create and use Kubernetes clusters with GKE.
-
-- Go to [GCP Console](https://console.cloud.google.com)
- - Select example project
- - Click `Enable Billing`
-- Go to [Kubernetes Clusters](https://console.cloud.google.com/kubernetes/list)
- - Click `Enable Billing`
\ No newline at end of file
diff --git a/docs/v0.1/concepts.md b/docs/v0.1/concepts.md
deleted file mode 100644
index 7a0e4fa5..00000000
--- a/docs/v0.1/concepts.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: Concepts
-toc: true
-weight: 410
----
-# Concepts
-
-## Control Plane
-
-Crossplane is an open source multicloud control plane that consists of smart controllers that can work across clouds to enable workload portability, provisioning and full-lifecycle management of infrastructure across a wide range of providers, vendors, regions, and offerings.
-The control plane presents a declarative management style API that covers a wide range of portable abstractions that facilitate these goals across disparate environments, clusters, regions, and clouds.
-Crossplane can be thought of as a higher-order orchestrator across cloud providers.
-For convenience, Crossplane can run directly on-top of an existing Kubernetes cluster without requiring any changes, even though Crossplane does not necessarily schedule or run any containers on the host cluster.
-
-## Resources and Workloads
-
-In Crossplane, a *resource* represents an external piece of infrastructure ranging from low level services like clusters and servers, to higher level infrastructure like databases, message queues, buckets, and more.
-Resources are represented as persistent object within the crossplane, and they typically manage one or more pieces of external infrastructure within a cloud provider or cloud offering.
-Resources can also represent local or in-cluster services.
-
-We model *workloads* as a schedulable units of work that the user intends to run on a cloud provider.
-Crossplane will support multiple types of workloads including container and serverless.
-You can think of workloads as units that run **your** code and applications.
-Every type of workload has a different kind of payload.
-For example, a container workload can include a set of objects that will be deployed on a managed Kubernetes cluster, or a reference to helm chart, etc.
-A serverless workload could include a function that will run on a serverless managed service.
-Workloads can contain requirements for where and how the workload can run, including regions, providers, affinity, cost, and others that the scheduler can use when assigning the workload.
-
-
-## Resource Claims and Resource Classes
-
-To support workload portability we expose the concept of a resource claim and a resource class.
-A resource claim is a persistent object that captures the desired configuration of a resource from the perspective of a workload or application.
-Its configuration is cloud-provider and cloud-offering independent and it’s free of implementation and/or environmental details.
-A resource claim can be thought of as a request for an actual resource and is typically created by a developer or application owner.
-
-A resource class is configuration that contains implementation details specific to a certain environment or deployment, and policies related to a kind of resource.
-A ResourceClass acts as a template with implementation details and policy for resources that will be dynamically provisioned by the workload at deployment time.
-A resource class is typically created by an admin or infrastructure owner.
-
-
-## Dynamic and Static Provisioning
-
-A resource can be statically or dynamically provisioned.
-Static provisioning is when an administrator creates the resource manually.
-They set the configuration required to provision and manage the corresponding external resource within a cloud provider or cloud offering.
-Once provisioned, resources are available to be bound to resource claims.
-
-Dynamic provisioning is when an resource claim does not find a matching resource and provisions a new one instead.
-The newly provisioned resource is automatically bound to the resource claim.
-To enable dynamic provisioning the administrator needs to create one or more resource class objects.
-
-## Connection Secrets
-
-Workloads reference all the resources the consume in their `resources` section.
-This helps Crossplane setup connectivity between the workload and resource, and create objects that hold connection information.
-For example, for a database provisioned and managed by Crossplane, a secret will be created that contains a connection string, user and password.
-This secret will be propagated to the target cluster so that it can be used by the workload.
diff --git a/docs/v0.1/contributing.md b/docs/v0.1/contributing.md
deleted file mode 100644
index 4da16cca..00000000
--- a/docs/v0.1/contributing.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Contributing
-toc: true
-weight: 610
----
-# Contributing
-
-Crossplane is a community driven project and we welcome contributions.
-That includes [opening issues](https://github.com/crossplaneio/crossplane/issues) for improvements you'd like to see as well as submitting changes to the code base.
-
-For more information about the contribution process, please see the [contribution guide](https://github.com/crossplaneio/crossplane/blob/master/CONTRIBUTING.md).
\ No newline at end of file
diff --git a/docs/v0.1/deploy.md b/docs/v0.1/deploy.md
deleted file mode 100644
index 060188cc..00000000
--- a/docs/v0.1/deploy.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: Deploying Workloads
-toc: true
-weight: 340
-indent: true
----
-# Deploying Workloads
-
-## Guides
-
-This section will walk you through how to deploy workloads to various cloud provider environments in a highly portable way.
-For detailed instructions on how to deploy workloads to your cloud provider of choice, please visit the following guides:
-
-* [Deploying a Workload on Google Cloud Platform (GCP)](workloads/gcp/wordpress-gcp.md)
-* [Deploying a Workload on Microsoft Azure](workloads/azure/wordpress-azure.md)
-* [Deploying a Workload on Amazon Web Services](workloads/aws/wordpress-aws.md)
-
-## Workload Overview
-
-A workload is a schedulable unit of work and contains a payload as well as defines its requirements for how the workload should run and what resources it will consume.
-This helps Crossplane setup connectivity between the workload and resources, and make intelligent decisions about where and how to provision and manage the resources in their entirety.
-Crossplane's scheduler is responsible for deploying the workload to a target cluster, which in this guide we will also be using Crossplane to deploy within your chosen cloud provider.
-
-This walkthrough also demonstrates Crossplane's concept of a clean "separation of concerns" between developers and administrators.
-Developers define workloads without having to worry about implementation details, environment constraints, and policies.
-Administrators can define environment specifics, and policies.
-The separation of concern leads to a higher degree of reusability and reduces complexity.
-
-During this walkthrough, we will assume two separate identities:
-
-1. Administrator (cluster or cloud) - responsible for setting up credentials and defining resource classes
-2. Application Owner (developer) - responsible for defining and deploying the application and its dependencies
-
-## Workload Example
-
-### Dependency Resource
-
-Let's take a closer look at a dependency resource that a workload will declare:
-
-```yaml
-## WordPress MySQL Database Instance
-apiVersion: storage.crossplane.io/v1alpha1
-kind: MySQLInstance
-metadata:
- name: demo
- namespace: default
-spec:
- classReference:
- name: standard-mysql
- namespace: crossplane-system
- engineVersion: "5.7"
-```
-
-This will request to create a `MySQLInstance` version 5.7, which will be fulfilled by the `standard-mysql` `ResourceClass`.
-Note that the application developer is not aware of any further specifics when it comes to the `MySQLInstance` beyond their requested engine version.
-This enables highly portable workloads, since the environment specific details of the database are defined by the administrator in a `ResourceClass`.
-
-### Workload
-
-Now let's look at the workload itself, which will reference the dependency resource from above, as well as other information such as the target cluster to deploy to.
-
-```yaml
-## WordPress Workload
-apiVersion: compute.crossplane.io/v1alpha1
-kind: Workload
-metadata:
- name: demo
- namespace: default
-spec:
- resources:
- - name: demo
- secretName: demo
- targetCluster:
- name: demo-gke-cluster
- namespace: crossplane-system
- targetDeployment:
- apiVersion: extensions/v1beta1
- kind: Deployment
- metadata:
- name: wordpress
- labels:
- app: wordpress
- spec:
- selector:
- app: wordpress
- strategy:
- type: Recreate
- template:
- metadata:
- labels:
- app: wordpress
- spec:
- containers:
- - name: wordpress
- image: wordpress:4.6.1-apache
- env:
- - name: WORDPRESS_DB_HOST
- valueFrom:
- secretKeyRef:
- name: demo
- key: endpoint
- - name: WORDPRESS_DB_USER
- valueFrom:
- secretKeyRef:
- name: demo
- key: username
- - name: WORDPRESS_DB_PASSWORD
- valueFrom:
- secretKeyRef:
- name: demo
- key: password
- ports:
- - containerPort: 80
- name: wordpress
- targetNamespace: demo
- targetService:
- apiVersion: v1
- kind: Service
- metadata:
- name: wordpress
- spec:
- ports:
- - port: 80
- selector:
- app: wordpress
- type: LoadBalancer
-```
-
-This `Workload` definition contains multiple components that informs Crossplane on how to deploy the workload and its resources:
-
-- Resources: list of the resources required by the payload application
-- TargetCluster: the cluster where the payload application and all its requirements should be deployed
-- TargetNamespace: the namespace on the target cluster
-- Workload Payload:
- - TargetDeployment
- - TargetService
diff --git a/docs/v0.1/faqs.md b/docs/v0.1/faqs.md
deleted file mode 100644
index 754d2d62..00000000
--- a/docs/v0.1/faqs.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: FAQs
-toc: true
-weight: 510
----
-# Frequently Asked Questions (FAQs)
-
-### Where did the name Crossplane come from?
-
-Crossplane is the fusing of cross-cloud control plane. We wanted to use a noun that refers to the entity responsible for connecting different cloud providers and acts as control plane across them. Cross implies “cross-cloud” and “plane” brings in “control plane”.
-
-### What's up with popsicle?
-
-We believe in a multi-flavor cloud.
-
-### Why is Upbound open sourcing this project? What are Upbound’s monetization plans?
-
-Upbound’s mission is to create a more open cloud-computing platform, with more choice and less lock-in. We believe the Crossplane as an important step towards this vision and that it’s going to take a village to solve this problem. We believe that multicloud control plane is a new category of open source software, and it will ultimately disrupt closed source and proprietary models. Upbound aspires to be a commercial provider of a more open cloud-computing platform.
-
-### What kind of governance model will be used for Crossplane?
-
-Crossplane will be an independent project and we plan on making a community driven project and not a vendor driven project. It will have an independent brand, github organization, and an open governance model. It will not be tied to single organization or individual.
-
-### Will Crossplane be donated to an open source foundation?
-
-We don’t know yet. We are open to doing so but we’d like to revisit this after the project has gotten some end-user community traction.
-
-### Does using multicloud mean you will use the lowest common denominator across clouds?
-
-Not necessarily. There are numerous best of breed cloud offerings that run on multiple clouds. For example, CockroachDB and ElasticSearch are world class implementations of platform software and run well on cloud providers. They compete with managed services offered by a cloud provider. We believe that by having a open control plane for they to integrate with, and providing a common API, CLI and UI for all of these services, that more of these offerings will exist and get first-class experience in the cloud.
-
-### How are resources and claims related to PersistentVolumes in Kubernetes?
-
-We modeled resource claims and classes after PersistentVolumes and PersistentVolumeClaims in Kubernetes. We believe many of the lessons learned from managing volumes in Kubernetes apply to managing resources within cloud providers. One notable exception is that we avoided creating a plugin model within Crossplane.
-
-### How is workload scheduling related to pod scheduling in Kubernetes?
-
-We modeled workload scheduling after the Pod scheduler in Kubernetes. We believe many of the lessons learned from Pod scheduling apply to scheduling workloads across cloud providers.
-
-### Can I use Crossplane to consistently provision and manage multiple Kubernetes clusters?
-
-Crossplane includes an portable API for Kubernetes clusters that will include common configuration including node pools, auto-scalers, taints, admission controllers, etc. These will be applied to the specific implementations within the cloud providers like EKS, GKE and AKS. We see the Kubernetes Cluster API to be something that will be used by administrators and not developers.
-
-### Other attempts at building a higher level API on-top of a multitude of inconsistent lower level APIs have not been successful, will Crossplane not have the same issues?
-
-We agree that building a consistent higher level API on top of multitudes of inconsistent lower level API's is well known to be fraught with peril (e.g. dumbing down to lowest common denominator, or resulting in so loosely defined an API as to be impossible to practically develop real portable applications on top of it).
-
-Crossplane follows a different approach here. The portable API extracts the pieces that are common across all implementations, and from the perspective of the workload. The rest of the implementation details are captured in full fidelity by the admin in resource classes. The combination of the two is what results in full configuration that can be deployed. We believe this to be a reasonable tradeoff that avoids the dumbing down to lowest common denominator problem, while still enabling portability.
diff --git a/docs/v0.1/getting-started.md b/docs/v0.1/getting-started.md
deleted file mode 100644
index 78c9241f..00000000
--- a/docs/v0.1/getting-started.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: Getting Started
-toc: true
-weight: 310
----
-# Getting Started
-
-* [Installing Crossplane](install-crossplane.md)
-* [Adding Your Cloud Providers](cloud-providers.md)
-* [Deploying Workloads](deploy.md)
-* [Running Resources](running-resources.md)
-* [Troubleshooting](troubleshoot.md)
\ No newline at end of file
diff --git a/docs/v0.1/install-crossplane.md b/docs/v0.1/install-crossplane.md
deleted file mode 100644
index 9d111a25..00000000
--- a/docs/v0.1/install-crossplane.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: Install
-toc: true
-weight: 320
-indent: true
----
-# Installing Crossplane
-
-Crossplane can be easily installed into any existing Kubernetes cluster using the regularly published Helm chart.
-The Helm chart contains all the custom resources and controllers needed to deploy and configure Crossplane.
-
-## Pre-requisites
-
-* [Kubernetes cluster](https://kubernetes.io/docs/setup/)
- * For example [Minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/), minimum version `v0.28+`
-* [Helm](https://docs.helm.sh/using_helm/), minimum version `v2.9.1+`.
-
-## Installation
-
-Helm charts for Crossplane are currently published to the `alpha` and `master` channels.
-In the future, `beta` and `stable` will also be available.
-
-### Alpha
-
-The alpha channel is the most recent release of Crossplane that is considered ready for testing by the community.
-
-```console
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-### Master
-
-The `master` channel contains the latest commits, with all automated tests passing.
-`master` is subject to instability, incompatibility, and features may be added or removed without much prior notice.
-It is recommended to use one of the more stable channels, but if you want the absolute newest Crossplane installed, then you can use the `master` channel.
-
-To install the Helm chart from master, you will need to pass the specific version returned by the `search` command:
-
-```console
-helm repo add crossplane-master https://charts.crossplane.io/master/
-helm search crossplane
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version
-```
-
-For example:
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version 0.0.0-249.637ccf9
-```
-
-## Uninstalling the Chart
-
-To uninstall/delete the `crossplane` deployment:
-
-```console
-helm delete --purge crossplane
-```
-
-That command removes all Kubernetes components associated with Crossplane, including all the custom resources and controllers.
-
-## Configuration
-
-The following tables lists the configurable parameters of the Crossplane chart and their default values.
-
-| Parameter | Description | Default |
-| ------------------------- | --------------------------------------------------------------- | ------------------------------------------------------ |
-| `image.repository` | Image | `crossplane/crossplane` |
-| `image.tag` | Image tag | `master` |
-| `image.pullPolicy` | Image pull policy | `Always` |
-| `imagePullSecrets` | Names of image pull secrets to use | `dockerhub` |
-| `replicas` | The number of replicas to run for the Crossplane operator | `1` |
-| `deploymentStrategy` | The deployment strategy for the Crossplane operator | `RollingUpdate` |
-
-### Command Line
-
-You can pass the settings with helm command line parameters.
-Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`.
-For example, the following command will install Crossplane with an image pull policy of `IfNotPresent`.
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane --set image.pullPolicy=IfNotPresent
-```
-
-### Settings File
-
-Alternatively, a yaml file that specifies the values for the above parameters (`values.yaml`) can be provided while installing the chart.
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane -f values.yaml
-```
-
-Here are the sample settings to get you started.
-
-```yaml
-replicas: 1
-
-deploymentStrategy: RollingUpdate
-
-image:
- repository: crossplane/crossplane
- tag: master
- pullPolicy: Always
-
-imagePullSecrets:
-- dockerhub
-```
diff --git a/docs/v0.1/media/arch.png b/docs/v0.1/media/arch.png
deleted file mode 100644
index 8205e62e..00000000
Binary files a/docs/v0.1/media/arch.png and /dev/null differ
diff --git a/docs/v0.1/media/banner.png b/docs/v0.1/media/banner.png
deleted file mode 100644
index 0a495e1d..00000000
Binary files a/docs/v0.1/media/banner.png and /dev/null differ
diff --git a/docs/v0.1/media/logo.svg b/docs/v0.1/media/logo.svg
deleted file mode 100644
index 3af90369..00000000
--- a/docs/v0.1/media/logo.svg
+++ /dev/null
@@ -1,310 +0,0 @@
-
-
-
diff --git a/docs/v0.1/quick-start.md b/docs/v0.1/quick-start.md
deleted file mode 100644
index 65e3bbf4..00000000
--- a/docs/v0.1/quick-start.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Quick Start Guide
-toc: true
-weight: 210
----
-# Quick Start Guide
-
-This quick start will demonstrate using Crossplane to deploy a portable stateful workload in the cloud provider of your choice.
-It will first dynamically provision a Kubernetes cluster within the cloud provider environment, followed by a stateful application and its database to the same environment.
-The database will also be dynamically provisioned using a managed service hosted by the cloud provider.
-The Workload will be deployed into the target Kubernetes cluster, and be configured to consume the database resource in a completely portable way.
-
-The general steps for this example are as follows:
-
-1. Install Crossplane so it is ready to manage resources on your behalf: [Install Crossplane](install-crossplane.md)
-1. Set up a cloud provider and add it to Crossplane: [Adding a Cloud Provider](cloud-providers.md)
-1. Deploy a portable workload to the cloud provider: [Deploying Workloads](deploy.md)
diff --git a/docs/v0.1/running-resources.md b/docs/v0.1/running-resources.md
deleted file mode 100644
index 766fec33..00000000
--- a/docs/v0.1/running-resources.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: Running Resources
-toc: true
-weight: 350
-indent: true
----
-# Running Resources
-
-Crossplane enables you to run a number of different resources in a portable and cloud agnostic way, allowing you to author an application that runs without modifications on multiple environments and cloud providers.
-A single Crossplane enables the provisioning and full-lifecycle management of infrastructure across a wide range of providers, vendors, regions, and offerings.
-
-## Running Databases
-
-Database managed services can be statically or dynamically provisioned by Crossplane in AWS, GCP, and Azure.
-An application developer simply has to specify their general need for a database such as MySQL, without any specific knowledge of what environment that database will run in or even what specific type of database it will be at runtime.
-The following sample is all the application developer needs to specify in order to get the correct MySQL database (CloudSQL, RDS, Azure MySQL) provisioned and configured for their application:
-
-```yaml
-apiVersion: storage.crossplane.io/v1alpha1
-kind: MySQLInstance
-metadata:
- name: demo-mysql
-spec:
- classReference:
- name: standard-mysql
- namespace: crossplane-system
- engineVersion: "5.7"
-```
-
-The cluster administrator specifies a resource class that acts as a template with the implementation details and policy specific to the environment that the generic MySQL resource is being deployed to.
-This enables the database to be dynamically provisioned at deployment time without the application developer needing to know any of the details, which promotes portability and reusability.
-An example resource class that will provision a CloudSQL instance in GCP in order to fulfill the applications general MySQL requirement would look like this:
-
-```yaml
-apiVersion: core.crossplane.io/v1alpha1
-kind: ResourceClass
-metadata:
- name: standard-mysql
- namespace: crossplane-system
-parameters:
- tier: db-n1-standard-1
- region: us-west2
- storageType: PD_SSD
-provisioner: cloudsqlinstance.database.gcp.crossplane.io/v1alpha1
-providerRef:
- name: gcp-provider
-reclaimPolicy: Delete
-```
-
-## Running Kubernetes Clusters
-
-Kubernetes clusters are another type of resource that can be dynamically provisioned using a generic resource claim by the application developer and an environment specific resource class by the cluster administrator.
-
-Generic Kubernetes cluster resource claim created by the application developer:
-
-```yaml
-apiVersion: compute.crossplane.io/v1alpha1
-kind: KubernetesCluster
-metadata:
- name: demo-cluster
- namespace: crossplane-system
-spec:
- classReference:
- name: standard-cluster
- namespace: crossplane-system
-```
-
-Environment specific GKE cluster resource class created by the admin:
-
-```yaml
-apiVersion: core.crossplane.io/v1alpha1
-kind: ResourceClass
-metadata:
- name: standard-cluster
- namespace: crossplane-system
-parameters:
- machineType: n1-standard-1
- numNodes: "1"
- zone: us-central1-a
-provisioner: gkecluster.compute.gcp.crossplane.io/v1alpha1
-providerRef:
- name: gcp-provider
-reclaimPolicy: Delete
-```
-
-## Future support
-
-As the project continues to grow with support from the community, support for more resources will be added.
-This includes all of the essential managed services from cloud providers as well as local or in-cluster services that deploy using the operator pattern.
-Crossplane will provide support for serverless, databases, object storage (buckets), analytics, big data, AI, ML, message queues, key-value stores, and more.
\ No newline at end of file
diff --git a/docs/v0.1/troubleshoot.md b/docs/v0.1/troubleshoot.md
deleted file mode 100644
index 05f294f7..00000000
--- a/docs/v0.1/troubleshoot.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: Troubleshooting
-toc: true
-weight: 360
-indent: true
----
-# Troubleshooting
-
-* [Crossplane Logs](#crossplane-logs)
-* [Resource Status and Conditions](#resource-status-and-conditions)
-* [Pausing Crossplane](#pausing-crossplane)
-* [Deleting a Resource Hangs](#deleting-a-resource-hangs)
-
-## Crossplane Logs
-
-The first place to look to get more information or investigate a failure would be in the Crossplane pod logs, which should be running in the `crossplane-system` namespace.
-To get the current Crossplane logs, run the following:
-
-```console
-kubectl -n crossplane-system logs $(kubectl -n crossplane-system get pod -l app=crossplane -o jsonpath='{.items[0].metadata.name}')
-```
-
-## Resource Status and Conditions
-
-All of the objects that represent managed resources such as databases, clusters, etc. have a `status` section that can give good insight into the current state of that particular object.
-In general, simply getting the `yaml` output of a Crossplane object will give insightful information about its condition:
-
-```console
-kubetl get -o yaml
-```
-
-For example, to get complete information about an Azure AKS cluster object, the following command will generate the below sample (truncated) output:
-
-```console
-> kubectl -n crossplane-system get akscluster -o yaml
-...
- status:
- Conditions:
- - LastTransitionTime: 2018-12-04T08:03:01Z
- Message: 'failed to start create operation for AKS cluster aks-demo-cluster:
- containerservice.ManagedClustersClient#CreateOrUpdate: Failure sending request:
- StatusCode=400 -- Please see https://aka.ms/acs-sp-help for more details."'
- Reason: failed to create cluster
- Status: "False"
- Type: Failed
- - LastTransitionTime: 2018-12-04T08:03:14Z
- Message: ""
- Reason: ""
- Status: "False"
- Type: Creating
- - LastTransitionTime: 2018-12-04T09:59:43Z
- Message: ""
- Reason: ""
- Status: "True"
- Type: Ready
- bindingPhase: Bound
- endpoint: crossplane-aks-14af6e93.hcp.centralus.azmk8s.io
- state: Succeeded
-```
-
-We can see a few conditions in that AKS cluster's history.
-It first encountered a failure, then it moved into the `Creating` state, then it finally became `Ready` later on.
-Conditions that have `Status: "True"` are currently active, while conditions with `Status: "False"` happened in the past, but are no longer happening currently.
-
-## Pausing Crossplane
-
-Sometimes, it can be useful to pause Crossplane if you want to stop it from actively attempting to manage your resources, for instance if you have encountered a bug.
-To pause Crossplane without deleting all of its resources, run the following command to simply scale down its deployment:
-
-```console
-kubectl -n crossplane-system scale --replicas=0 deployment/crossplane
-```
-
-Once you have been able to rectify the problem or smooth things out, you can unpause Crossplane simply by scaling its deployment back up:
-
-```console
-kubectl -n crossplane-system scale --replicas=1 deployment/crossplane
-```
-
-## Deleting a Resource Hangs
-
-The resources that Crossplane manages will automatically be cleaned up so as not to leave anything running behind.
-This is accomplished by using finalizers, but in certain scenarios, the finalizer can prevent the Kubernetes object from getting deleted.
-
-To deal with this, we essentially want to patch the object to remove its finalizer, which will then allow it to be deleted completely.
-Note that this won't necessarily delete the external resource that Crossplane was managing, so you will want to go to your cloud provider's console and look there for any lingering resources to clean up.
-
-In general, a finalizer can be removed from an object with this command:
-
-```console
-kubectl patch -p '{"metadata":{"finalizers": []}}' --type=merge
-```
-
-For example, for a Workload object (`workloads.compute.crossplane.io`) named `test-workload`, you can remove its finalizer with:
-
-```console
-kubectl patch workloads.compute.crossplane.io test-workload -p '{"metadata":{"finalizers": []}}' --type=merge
-```
diff --git a/docs/v0.1/workloads/aws/wordpress-aws.md b/docs/v0.1/workloads/aws/wordpress-aws.md
deleted file mode 100644
index 4da97bf8..00000000
--- a/docs/v0.1/workloads/aws/wordpress-aws.md
+++ /dev/null
@@ -1,229 +0,0 @@
-# Deploying a WordPress Workload on AWS
-
-This guide will walk you through how to use Crossplane to deploy a stateful workload in a portable way to AWS.
-In this environment, the following components will be dynamically provisioned and configured during this guide:
-
-* EKS Kubernetes cluster
-* RDS MySQL database
-* WordPress application
-
-## Pre-requisites
-
-Before starting this guide, you should have already [configured your AWS account](../../cloud-providers/aws/aws-provider.md) for usage by Crossplane.
-
-You should have a `~/.aws/credentials` file on your local filesystem.
-
-## Administrator Tasks
-
-This section covers the tasks performed by the cluster or cloud administrator, which includes:
-
-- Import AWS provider credentials
-- Define Resource classes for cluster and database resources
-- Create all EKS pre-requisite artifacts
-- Create a target EKS Kubernetes cluster (using dynamic provisioning with the cluster resource class)
-
-**Note**: all artifacts created by the administrator are stored/hosted in the `crossplane-system` namespace, which has
-restricted access, i.e. `Application Owner(s)` should not have access to them.
-
-For the next steps, make sure your `kubectl` context points to the cluster where `Crossplane` was deployed.
-
-### Create credentials
-
-1. Get base64 encoded credentials with `cat ~/.aws/credentials|base64|tr -d '\n'`
-1. Replace `BASE64ENCODED_AWS_PROVIDER_CREDS` in `cluster/examples/workloads/wordpress-aws/provider.yaml` with value from previous step.
-
-### Configure EKS Cluster Pre-requisites
-
-EKS cluster deployment is somewhat of an arduous process right now.
-A number of artifacts and configuration needs to be set up within the AWS console first before proceeding with the provisioning of an EKS cluster using Crossplane.
-We anticipate that AWS will make improvements on this user experience in the near future.
-
-#### Create a named keypair
-* You can either reuse an existing ec2 key pair or create a new key pair with [these steps](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)
-* Replace your key pair name in `cluster/examples/workloads/wordpress-aws/provider.yaml` in `EKS_WORKER_KEY_NAME`
-
-#### Create your Amazon EKS Service Role
-[Original Source Guide](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)
-
-1. Open the [IAM console](https://console.aws.amazon.com/iam/).
-1. Choose Roles, then Create role.
-1. Choose EKS from the list of services, then Allows Amazon EKS to manage your clusters on your behalf for your use case, then Next: Permissions.
-1. Choose Next: Review.
-1. For Role name, enter a unique name for your role, such as eksServiceRole, then choose Create role.
-1. Replace `EKS_ROLE_ARN` in `cluster/examples/workloads/wordpress-aws/provider.yaml` with role arn from previous step.
-
-#### Create your Amazon EKS Cluster VPC
-[Original Source Guide](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)
-
-1. Open the [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation).
-1. From the navigation bar, select a Region that supports Amazon EKS.
- ```> Note
- Amazon EKS is available in the following Regions at this time:
- * US West (Oregon) (us-west-2)
- * US East (N. Virginia) (us-east-1)
- * EU (Ireland) (eu-west-1)
- ```
-
-1. Choose Create stack.
-1. For Choose a template, select Specify an Amazon S3 template URL.
-1. Paste the following URL into the text area and choose Next:
- ```
- https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2018-11-07/amazon-eks-vpc-sample.yaml
- ```
-1. On the Specify Details page, fill out the parameters accordingly, and then choose Next.
- ```
- * Stack name: Choose a stack name for your AWS CloudFormation stack. For example, you can call it eks-vpc.
- * VpcBlock: Choose a CIDR range for your VPC. You may leave the default value.
- * Subnet01Block: Choose a CIDR range for subnet 1. You may leave the default value.
- * Subnet02Block: Choose a CIDR range for subnet 2. You may leave the default value.
- * Subnet03Block: Choose a CIDR range for subnet 3. You may leave the default value.
- ```
-1. (Optional) On the Options page, tag your stack resources. Choose Next.
-1. On the Review page, choose Create.
-1. When your stack is created, select it in the console and choose Outputs.
-1. Replace `EKS_VPC`, `EKS_ROLE_ARN`, `EKS_SUBNETS`, `EKS_SECURITY_GROUP` in `cluster/examples/workloads/wordpress-aws/provider.yaml` with values from previous step (vpcId, subnetIds, securityGroupIds). Note `EKS_SECURITY_GROUP` needs to be replaced twice in file.
-1. Replace `REGION` in `cluster/examples/workloads/wordpress-aws/provider.yaml` with the region you selected in VPC creation.
-
-#### Create an RDS subnet group
-1. Navigate to aws console in same region as the EKS clsuter
-1. Navigate to `RDS` service
-1. Navigate to `Subnet groups` in left hand pane
-1. Click `Create DB Subnet Group`
-1. Name your subnet i.e. `eks-db-subnets`
-1. Select the VPC created in the EKS VPC step
-1. Click `Add all subnets related to this VPC`
-1. Click Create
-1. Replace `RDS_SUBNET_GROUP` in `cluster/examples/workloads/wordpress-aws/provider.yaml` with the `DBSubnetgroup` name you just created.
-
-#### Create an RDS Security Group (example only)
-
-**Note**: This will make your RDS instance visible from Anywhere on the internet.
-This if for **EXAMPLE PURPOSES ONLY**, and is **NOT RECOMMENDED** for production system.
-
-1. Navigate to ec2 in the region of the EKS cluster
-1. Navigate to security groups
-1. Select the same VPC from the EKS cluster.
-1. On the Inbound Rules tab, choose Edit.
- - For Type, choose `MYSQL/Aurora`
- - For Port Range, type `3306`
- - For Source, choose `Anywhere` from drop down or type: `0.0.0.0/0`
-1. Choose Add another rule if you need to add more IP addresses or different port ranges.
-1. Replace `RDS_SECURITY_GROUP` in `cluster/examples/workloads/wordpress-aws/provider.yaml` with the security group we just created.
-
-### Deploy all Workload Resources
-
-Now deploy all the workload resources, including the RDS database and EKS cluster with the following single commands:
-
-Create provider:
-```console
-kubectl create -f cluster/examples/workloads/wordpress-aws/provider.yaml
-```
-
-Create cluster:
-```console
-kubectl create -f cluster/examples/workloads/wordpress-aws/cluster.yaml
-```
-
-It will take a while (~15 minutes) for the EKS cluster to be deployed and becoming ready.
-You can keep an eye on its status with the following command:
-
-```console
-kubectl -n crossplane-system get ekscluster -o custom-columns=NAME:.metadata.name,STATE:.status.state,CLUSTERNAME:.status.clusterName,ENDPOINT:.status.endpoint,LOCATION:.spec.location,CLUSTERCLASS:.spec.classRef.name,RECLAIMPOLICY:.spec.reclaimPolicy
-```
-
-Once the cluster is done provisioning, you should see output similar to the following (note the `STATE` field is `ACTIVE` and the `ENDPOINT` field has a value):
-
-```console
-NAME STATE CLUSTERNAME ENDPOINT LOCATION CLUSTERCLASS RECLAIMPOLICY
-eks-8f1f32c7-f6b4-11e8-844c-025000000001 ACTIVE https://B922855C944FC0567E9050FCD75B6AE5.yl4.us-west-2.eks.amazonaws.com standard-cluster Delete
-```
-
-## Application Developer Tasks
-
-This section covers the tasks performed by the application developer, which includes:
-
-- Define Workload in terms of Resources and Payload (Deployment/Service) which will be deployed into the target Kubernetes Cluster
-- Define the dependency resource requirements, in this case a `MySQL` database
-
-Now that the EKS cluster is ready, let's begin deploying the workload as the application developer:
-
-```console
-kubectl -n demo create -f cluster/examples/workloads/wordpress-aws/workload.yaml
-```
-
-This will also take awhile to complete, since the MySQL database needs to be deployed before the WordPress pod can consume it.
-You can follow along with the MySQL database deployment with the following:
-
-```console
-kubectl -n crossplane-system get rdsinstance -o custom-columns=NAME:.metadata.name,STATUS:.status.state,CLASS:.spec.classRef.name,VERSION:.spec.version
-```
-
-Once the `STATUS` column is `available` like below, then the WordPress pod should be able to connect to it:
-
-```console
-NAME STATUS CLASS VERSION
-mysql-2a0be04f-f748-11e8-844c-025000000001 available standard-mysql
-```
-
-Now we can watch the WordPress pod come online and a public IP address will get assigned to it:
-
-```console
-kubectl -n demo get workload -o custom-columns=NAME:.metadata.name,CLUSTER:.spec.targetCluster.name,NAMESPACE:.spec.targetNamespace,DEPLOYMENT:.spec.targetDeployment.metadata.name,SERVICE-EXTERNAL-IP:.status.service.loadBalancer.ingress[0].ip
-```
-
-When a public IP address has been assigned, you'll see output similar to the following:
-
-```console
-NAME CLUSTER NAMESPACE DEPLOYMENT SERVICE-EXTERNAL-IP
-demo demo-cluster demo wordpress 104.43.240.15
-```
-
-Once WordPress is running and has a public IP address through its service, we can get the URL with the following command:
-
-```console
-echo "http://$(kubectl get workload test-workload -o jsonpath='{.status.service.loadBalancer.ingress[0].ip}')"
-```
-
-Paste that URL into your browser and you should see WordPress running and ready for you to walk through the setup experience. You may need to wait a few minutes for this to become active in the AWS load balancer.
-
-## Connect to your EKSCluster (optional)
-
-Requires:
- * awscli
- * aws-iam-authenticator
-
-Please see [Install instructions](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) section: `Install and Configure kubectl for Amazon EKS`
-
-When the EKSCluster is up and running, you can update your kubeconfig with:
-```console
-aws eks update-kubeconfig --name
-```
-
-Node pool is created after the master is up, so expect a few more minutes to wait, but eventually you can see that nodes joined with:
-```console
-kubectl config use-context
-kubectl get nodes
-```
-
-## Clean-up
-
-First delete the workload, which will delete WordPress and the MySQL database:
-
-```console
-kubectl -n demo delete -f cluster/examples/workloads/wordpress-aws/workload.yaml
-```
-
-Then delete the EKS cluster:
-
-```console
-kubectl delete -f cluster/examples/workloads/wordpress-aws/cluster.yaml
-```
-
-Finally, delete the provider credentials:
-
-```console
-kubectl delete -f cluster/examples/workloads/wordpress-aws/provider.yaml
-```
-
-> Note: There may still be an ELB that was not properly cleaned up, and you will need
-to go to EC2 > ELBs and delete it manually.
diff --git a/docs/v0.1/workloads/azure/wordpress-azure.md b/docs/v0.1/workloads/azure/wordpress-azure.md
deleted file mode 100644
index d1a56bc7..00000000
--- a/docs/v0.1/workloads/azure/wordpress-azure.md
+++ /dev/null
@@ -1,128 +0,0 @@
-# Deploying a WordPress Workload on Microsoft Azure
-
-This guide will walk you through how to use Crossplane to deploy a stateful workload in a portable way to Azure.
-In this environment, the following components will be dynamically provisioned and configured during this guide:
-
-* AKS Kubernetes cluster
-* Azure MySQL database
-* WordPress application
-
-## Pre-requisites
-
-Before starting this guide, you should have already [configured your Azure account](../../cloud-providers/azure/azure-provider.md) for usage by Crossplane.
-
-You should have a `crossplane-azure-provider-key.json` file on your local filesystem, preferably at the root of where you cloned the [Crossplane repo](https://github.com/crossplaneio/crossplane).
-
-## Administrator Tasks
-
-This section covers the tasks performed by the cluster or cloud administrator, which includes:
-
-- Import Azure provider credentials
-- Define Resource classes for cluster and database resources
-- Create a target Kubernetes cluster (using dynamic provisioning with the cluster resource class)
-
-**Note**: all artifacts created by the administrator are stored/hosted in the `crossplane-system` namespace, which has
-restricted access, i.e. `Application Owner(s)` should not have access to them.
-
-For the next steps, make sure your `kubectl` context points to the cluster where `Crossplane` was deployed.
-
-- Create the Azure provider object in your cluster:
-
- ```console
- sed "s/BASE64ENCODED_AZURE_PROVIDER_CREDS/`cat crossplane-azure-provider-key.json|base64|tr -d '\n'`/g;" cluster/examples/workloads/wordpress-azure/provider.yaml | kubectl create -f -
- ```
-
-- Next, create the AKS cluster that will eventually be the target cluster for your Workload deployment:
-
- ```console
- kubectl create -f cluster/examples/workloads/wordpress-azure/cluster.yaml
- ```
-
- It will take a while (~15 minutes) for the AKS cluster to be deployed and becoming ready. You can keep an eye on its status with the following command:
-
- ```console
- kubectl -n crossplane-system get akscluster -o custom-columns=NAME:.metadata.name,STATE:.status.state,CLUSTERNAME:.status.clusterName,ENDPOINT:.status.endpoint,LOCATION:.spec.location,CLUSTERCLASS:.spec.classRef.name,RECLAIMPOLICY:.spec.reclaimPolicy
- ```
-
- Once the cluster is done provisioning, you should see output similar to the following (note the `STATE` field is `Succeeded` and the `ENDPOINT` field has a value):
-
- ```console
- NAME STATE CLUSTERNAME ENDPOINT LOCATION CLUSTERCLASS RECLAIMPOLICY
- aks-587762b3-f72b-11e8-bcbe-0800278fedb1 Succeeded aks-587762b3-f72b-11e8-bcbe-080 crossplane-aks-653c32ef.hcp.centralus.azmk8s.io Central US standard-cluster Delete
- ```
-
-To recap the operations that we just performed as the administrator:
-
-- Defined a `Provider` with Microsoft Azure service principal credentials
-- Defined `ResourceClasses` for `KubernetesCluster` and `MySQLInstance`
-- Provisioned (dynamically) an AKS Cluster using the `ResourceClass`
-
-## Application Developer Tasks
-
-This section covers the tasks performed by the application developer, which includes:
-
-- Define Workload in terms of Resources and Payload (Deployment/Service) which will be deployed into the target Kubernetes Cluster
-- Define the dependency resource requirements, in this case a `MySQL` database
-
-Let's begin deploying the workload as the application developer:
-
-- Now that the target AKS cluster is ready, we can deploy the Workload that contains all the Wordpress resources, including the SQL database, with the following single command:
-
- ```console
- kubectl create -f cluster/examples/workloads/wordpress-azure/workload.yaml
- ```
-
- This will also take awhile to complete, since the MySQL database needs to be deployed before the Wordpress pod can consume it.
- You can follow along with the MySQL database deployment with the following:
-
- ```console
- kubectl -n crossplane-system get mysqlserver -o custom-columns=NAME:.metadata.name,STATUS:.status.state,CLASS:.spec.classRef.name,VERSION:.spec.version
- ```
-
- Once the `STATUS` column is `Ready` like below, then the Wordpress pod should be able to connect to it:
-
- ```console
- NAME STATUS CLASS VERSION
- mysql-58425bda-f72d-11e8-bcbe-0800278fedb1 Ready standard-mysql 5.7
- ```
-
-- Now we can watch the Wordpress pod come online and a public IP address will get assigned to it:
-
- ```console
- kubectl get workload -o custom-columns=NAME:.metadata.name,CLUSTER:.spec.targetCluster.name,NAMESPACE:.spec.targetNamespace,DEPLOYMENT:.spec.targetDeployment.metadata.name,SERVICE-EXTERNAL-IP:.status.service.loadBalancer.ingress[0].ip
- ```
-
- When a public IP address has been assigned, you'll see output similar to the following:
-
- ```console
- NAME CLUSTER NAMESPACE DEPLOYMENT SERVICE-EXTERNAL-IP
- test-workload demo-cluster demo wordpress 104.43.240.15
- ```
-
-- Once Wordpress is running and has a public IP address through its service, we can get the URL with the following command:
-
- ```console
- echo "http://$(kubectl get workload test-workload -o jsonpath='{.status.service.loadBalancer.ingress[0].ip}')"
- ```
-
-- Paste that URL into your browser and you should see Wordpress running and ready for you to walk through the setup experience.
-
-## Clean-up
-
-First delete the workload, which will delete Wordpress and the MySQL database:
-
-```console
-kubectl delete -f cluster/examples/workloads/wordpress-azure/workload.yaml
-```
-
-Then delete the AKS cluster:
-
-```console
-kubectl delete -f cluster/examples/workloads/wordpress-azure/cluster.yaml
-```
-
-Finally, delete the provider credentials:
-
-```console
-kubectl delete -f cluster/examples/workloads/wordpress-azure/provider.yaml
-```
diff --git a/docs/v0.1/workloads/gcp/wordpress-gcp.md b/docs/v0.1/workloads/gcp/wordpress-gcp.md
deleted file mode 100644
index fc21aee2..00000000
--- a/docs/v0.1/workloads/gcp/wordpress-gcp.md
+++ /dev/null
@@ -1,175 +0,0 @@
-# Deploying a WordPress Workload on GCP
-
-This guide will walk you through how to use Crossplane to deploy a stateful workload in a portable way to GCP.
-In this environment, the following components will be dynamically provisioned and configured during this guide:
-
-* GKE Kubernetes cluster
-* CloudSQL database
-* WordPress application
-
-## Pre-requisites
-
-Before starting this guide, you should have already [configured your GCP account](../../cloud-providers/gcp/gcp-provider.md) for usage by Crossplane.
-
-You should have a `key.json` file on your local filesystem, preferably at the root of where you cloned the [Crossplane repo](https://github.com/crossplaneio/crossplane).
-
-## Administrator Tasks
-
-This section covers the tasks performed by the cluster or cloud administrator, which includes:
-
-- Import GCP provider credentials
-- Define Resource classes for cluster and database resources
-- Create a target Kubernetes cluster (using dynamic provisioning with the cluster resource class)
-
-**Note**: all artifacts created by the administrator are stored/hosted in the `crossplane-system` namespace, which has
-restricted access, i.e. `Application Owner(s)` should not have access to them.
-
-For the next steps, make sure your `kubectl` context points to the cluster where `Crossplane` was deployed.
-
-- Export Project ID
-
- **NOTE** you can skip this step if you generated GCP Service Account using `gcloud`
- ```bash
- export DEMO_PROJECT_ID=[your-demo-project-id]
- ```
-
-- Patch and Apply `provider.yaml`:
- ```bash
- sed "s/BASE64ENCODED_CREDS/`cat key.json|base64 | tr -d '\n'`/g;s/DEMO_PROJECT_ID/$DEMO_PROJECT_ID/g" cluster/examples/workloads/wordpress-gcp/provider.yaml | kubectl create -f -
- ```
-
- - Verify that GCP Provider is in `Ready` state
- ```bash
- kubectl -n crossplane-system get providers.gcp.crossplane.io -o custom-columns=NAME:.metadata.name,STATUS:.status.Conditions[0].Type,PROJECT-ID:.spec.projectID
- ```
- Your output should look similar to:
- ```bash
- NAME STATUS PROJECT-ID
- gcp-provider Ready [your-project-id]
- ```
-
- - Verify that Resource Classes have been created
- ```bash
- kubectl -n crossplane-system get resourceclass -o custom-columns=NAME:metadata.name,PROVISIONER:.provisioner,PROVIDER:.providerRef.name,RECLAIM-POLICY:.reclaimPolicy
- ```
- Your output should be:
- ```bash
- NAME PROVISIONER PROVIDER RECLAIM-POLICY
- standard-cluster gkecluster.compute.gcp.crossplane.io/v1alpha1 gcp-provider Delete
- standard-mysql cloudsqlinstance.database.gcp.crossplane.io/v1alpha1 gcp-provider Delete
- ```
-- Create a target Kubernetes cluster where `Application Owner(s)` will deploy their `WorkLoad(s)`
-
- As administrator, you will create a Kubernetes cluster leveraging the Kubernetes cluster `ResourceClass` that was created earlier and
- `Crossplane` Kubernetes cluster dynamic provisioning.
- ```bash
- kubectl apply -f cluster/examples/workloads/wordpress-gcp/kubernetes.yaml
- ```
-
- - Verify that Kubernetes Cluster resource was created
- ```bash
- kubectl -n crossplane-system get kubernetescluster -o custom-columns=NAME:.metadata.name,CLUSTERCLASS:.spec.classReference.name,CLUSTERREF:.spec.resourceName.name
- ```
-
- Your output should look similar to:
- ```bash
- NAME CLUSTERCLASS CLUSTERREF
- demo-gke-cluster standard-cluster gke-67419e79-f5b3-11e8-9cec-9cb6d08bde99
- ```
-
- - Verify that the target GKE cluster was successfully created
- ```bash
- kubectl -n crossplane-system get gkecluster -o custom-columns=NAME:.metadata.name,STATE:.status.state,CLUSTERNAME:.status.clusterName,ENDPOINT:.status.endpoint,LOCATION:.spec.zone,CLUSTERCLASS:.spec.classRef.name,RECLAIMPOLICY:.spec.reclaimPolicy
- ```
-
- Your output should look similar to:
- ```bash
- NAME STATE CLUSTERNAME ENDPOINT LOCATION CLUSTERCLASS RECLAIMPOLICY
- gke-67419e79-f5b3-11e8-9cec-9cb6d08bde99 RUNNING gke-6742fe8d-f5b3-11e8-9cec-9cb6d08bde99 146.148.93.40 us-central1-a standard-cluster Delete
- ```
-
-To recap the operations that we just performed as the administrator:
-
-- Defined a `Provider` with Google Service Account credentials
-- Defined `ResourceClasses` for `KubernetesCluster` and `MySQLInstance`
-- Provisioned (dynamically) a GKE Cluster using the `ResourceClass`
-
-## Application Developer Tasks
-
-This section covers the tasks performed by the application developer, which includes:
-
-- Define Workload in terms of Resources and Payload (Deployment/Service) which will be deployed into the target Kubernetes Cluster
-- Define the dependency resource requirements, in this case a `MySQL` database
-
-Let's begin deploying the workload as the application developer:
-
-- Deploy workload
- ```bash
- kubectl apply -f cluster/examples/workloads/wordpress-gcp/workload.yaml
- ```
-- Wait for `MySQLInstance` to be in `Bound` State
-
- You can check the status via:
- ```bash
- kubectl get mysqlinstance -o custom-columns=NAME:.metadata.name,VERSION:.spec.engineVersion,STATE:.status.bindingPhase,CLASS:.spec.classReference.name
- ```
- Your output should look like:
- ```bash
- NAME VERSION STATE CLASS
- demo 5.7 Bound standard-mysql
- ```
-
- **Note**: to check on the concrete resource type status as `Administrator` you can run:
- ```bash
- kubectl -n crossplane-system get cloudsqlinstance -o custom-columns=NAME:.metadata.name,STATUS:.status.state,CLASS:.spec.classRef.name,VERSION:.spec.databaseVersion
- ```
- Your output should be similar to:
- ```bash
- NAME STATUS CLASS VERSION
- mysql-2fea0d8e-f5bb-11e8-9cec-9cb6d08bde99 RUNNABLE standard-mysql MYSQL_5_7
- ```
-
-- Wait for `Workload` External IP Address
- ```bash
- kubectl get workload -o custom-columns=NAME:.metadata.name,CLUSTER:.spec.targetCluster.name,NAMESPACE:.spec.targetNamespace,DEPLOYMENT:.spec.targetDeployment.metadata.name,SERVICE-EXTERNAL-IP:.status.service.loadBalancer.ingress[0].ip
- ```
- **Note** the `Workload` is defined in Application Owner's (`default`) namespace
-
- Your output should look similar to:
- ```bash
- NAME CLUSTER NAMESPACE DEPLOYMENT SERVICE-EXTERNAL-IP
- demo demo-gke-cluster demo wordpress 35.193.100.113
- ```
-
-- Verify that `WordPress` service is accessible via `SERVICE-EXTERNAL-IP` by:
- - Navigate in your browser to `SERVICE-EXTERNAL-IP`
-
-At this point, you should see the setup page for WordPress in your web browser.
-
-## Clean Up
-
-Once you are done with this example, you can clean up all its artifacts with the following commands:
-
-- Remove `Workload`
-```bash
-kubectl delete -f cluster/examples/workloads/wordpress-gcp/workload.yaml
-```
-
-- Remove `KubernetesCluster`
-```bash
-kubectl delete -f cluster/examples/workloads/wordpress-gcp/kubernetes.yaml
-```
-
-- Remove GCP `Provider` and `ResourceClasses`
-```bash
-kubectl delete -f cluster/examples/workloads/wordpress-gcp/provider.yaml
-```
-
-- Delete Google Project
-```bash
-# list all your projects
-gcloud projects list
-
-# delete demo project
-gcloud projects delete [demo-project-id
-```
diff --git a/docs/v0.10/README.md b/docs/v0.10/README.md
deleted file mode 100644
index 53037ef2..00000000
--- a/docs/v0.10/README.md
+++ /dev/null
@@ -1,63 +0,0 @@
-# Overview
-
-
-
-Crossplane is an open source control plane that allows you to manage
-applications and infrastructure the Kubernetes way. It provides the following
-features:
-
-- Deployment and management of cloud provider managed services using the
- Kubernetes API.
-- Management and scheduling of configuration data across multiple Kubernetes
- clusters.
-- Separation of concern between infrastructure owners, application owners, and
- developers.
-- Infrastructure agnostic packaging of applications and their dependencies.
-- Scheduling applications into different clusters, zones, and regions.
-
-Crossplane does not:
-
-- Require that you run your workloads on Kubernetes.
-- Manage the data plane across Kubernetes clusters.
-- Manage or provision non-hosted Kubernetes clusters.
-
-Crossplane can be [installed] into any Kubernetes cluster, and is compatible
-with any Kubernetes-native project. It manages external services by installing
-[Custom Resource Definitions] (CRDs) and [reconciling] instances of those Custom
-Resources. Crossplane is built to be extensible, meaning that anyone can add
-functionality for an new or existing cloud provider.
-
-Crossplane is comprised of four main components:
-
-1. **Core Crossplane**: the set of Kubernetes CRDs and controllers that manage
- installation of `providers`, `stacks`, and `applications`, as well as the
- scheduling of configuration data to remote Kubernetes clusters.
-2. **Providers**: the set of Kubernetes CRDs and controllers that provision and
- manage services on cloud providers. A cloud provider is any service that
- exposes infrastructure via an API.
- - Examples: [Google Cloud Platform], [Amazon Web Services], [Azure],
- [Alibaba], [Github]
-3. **Stacks**: a bundled set of custom resources that together represent an
- environment on a cloud provider. The bundle of instances can be created by a
- single custom resource.
- - Examples: [Sample GCP Stack], [Sample AWS Stack], [Sample Azure Stack]
-4. **Applications**: a deployable unit of code and configuration, which, when
- created, may involve provisioning new services which are managed by a
- `provider`, or consuming services created by a `stack`.
- - Examples: [Wordpress]
-
-
-
-[installed]: getting-started/install.md
-[Custom Resource Definitions]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[reconciling]: https://kubernetes.io/docs/concepts/architecture/controller/
-[Google Cloud Platform]: https://github.com/crossplane/provider-gcp
-[Amazon Web Services]: https://github.com/crossplane/provider-aws
-[Azure]: https://github.com/crossplane/provider-azure
-[Alibaba]: https://github.com/crossplane/provider-alibaba
-[Github]: https://github.com/crossplane/provider-github
-[Sample GCP Stack]: https://github.com/crossplane/stack-gcp-sample
-[Sample AWS Stack]: https://github.com/crossplane/stack-aws-sample
-[Sample Azure Stack]: https://github.com/crossplane/stack-azure-sample
-[Wordpress]: https://github.com/crossplane/app-wordpress
-
diff --git a/docs/v0.10/api-docs/overview.md b/docs/v0.10/api-docs/overview.md
deleted file mode 100644
index e9a92c48..00000000
--- a/docs/v0.10/api-docs/overview.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: API Documentation
-toc: true
-weight: 400
----
-
-# API Documentation
-
-The Crossplane ecosystem contains many CRDs that map to API types represented by
-external infrastructure providers. The documentation for these CRDs are
-auto-generated on [doc.crds.dev]. To find the CRDs available for providers
-maintained by the Crossplane organization, you can search for the Github URL, or
-append it in the [doc.crds.dev] URL path.
-
-For instance, to find the CRDs available for [provider-azure], you would go to:
-
-[doc.crds.dev/github.com/crossplane/provider/azure]
-
-By default, you will be served the latest CRDs on the `master` branch for the
-repository. If you prefer to see the CRDs for a specific version, you can append
-the git tag for the release:
-
-[doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0]
-
-Crossplane repositories that are not providers but do publish CRDs are also
-served on [doc.crds.dev]. For instance, the [crossplane/crossplane] repository.
-
-Bugs and feature requests for API documentation should be [opened as issues] on
-the open source [doc.crds.dev repo].
-
-
-
-[doc.crds.dev]: https://doc.crds.dev/
-[provider-azure]: https://github.com/crossplane/provider-azure
-[doc.crds.dev/github.com/crossplane/provider/azure]: https://doc.crds.dev/github.com/crossplane/provider-azure
-[doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0]: https://doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0
-[crossplane/crossplane]: https://doc.crds.dev/github.com/crossplane/crossplane
-[opened as issues]: https://github.com/crdsdev/doc/issues/new
-[doc.crds.dev repo]: https://github.com/crdsdev/doc
diff --git a/docs/v0.10/cloud-providers/aws/aws-provider.md b/docs/v0.10/cloud-providers/aws/aws-provider.md
deleted file mode 100644
index 5f27eef0..00000000
--- a/docs/v0.10/cloud-providers/aws/aws-provider.md
+++ /dev/null
@@ -1,143 +0,0 @@
-# Adding Amazon Web Services (AWS) to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your AWS
-account to be ready for integration with Crossplane. This will be done by adding
-an AWS `Provider` resource type, which enables Crossplane to communicate with an
-AWS account.
-
-## Requirements
-
-Prior to adding AWS to Crossplane, following steps need to be taken
-
-- Crossplane is installed in a k8s cluster
-- AWS Stack is installed in the same cluster
-- `kubectl` is configured to communicate with the same cluster
-
-## Step 1: Configure `aws` CLI
-
-Crossplane uses [AWS security credentials], and stores them as a [secret] which
-is managed by an AWS `Provider` instance. In addition, the AWS default region is
-also used for targeting a specific region. Crossplane requires to have [`aws`
-command line tool] [installed] and [configured]. Once installed, the credentials
-and configuration will reside in `~/.aws/credentials` and `~/.aws/config`
-respectively.
-
-## Step 2: Setup `aws` Provider
-
-Run [setup.sh] script to read `aws` credentials and region, and create an `aws
-provider` instance in Crossplane:
-
-```bash
-./cluster/examples/aws-setup-provider/setup.sh [--profile aws_profile]
-```
-
-The `--profile` switch is optional and specifies the [aws named profile] that
-was set in Step 1. If not provided, the `default` profile will be selected.
-
-Once the script is successfully executed, Crossplane will use the specified aws
-account and region in the given named profile to create subsequent AWS managed
-resources.
-
-You can confirm the existense of the AWS `Provider` by running:
-
-```bash
-kubectl -n crossplane-system get provider/aws-provider
-```
-
-## Optional: Setup AWS Provider Manually
-
-An AWS [user][aws user] with `Administrative` privileges is needed to enable
-Crossplane to create the required resources. Once the user is provisioned, an
-[Access Key][] needs to be created so the user can have API access.
-
-Using the set of [access key credentials][AWS security credentials] for the user
-with the right access, we need to [install][install-aws] [`aws cli`][aws command
-line tool], and then [configure][aws-cli-configure] it.
-
-When the AWS cli is configured, the credentials and configuration will be in
-`~/.aws/credentials` and `~/.aws/config` respectively. These will be consumed in
-the next step.
-
-When configuring the AWS cli, the user credentials could be configured under a
-specific [AWS named profile][], or under `default`. Without loss of generality,
-in this guide let's assume that the credentials are configured under the
-`aws_profile` profile (which could also be `default`). We'll use this profile to
-setup cloud provider in the next section.
-
-Crossplane uses the AWS user credentials that were configured in the previous
-step to create resources in AWS. These credentials will be stored as a
-[secret][kubernetes secret] in Kubernetes, and will be used by an AWS `Provider`
-instance. The default AWS region is also pulled from the cli configuration, and
-added to the AWS provider.
-
-To store the credentials as a secret, run:
-
-```bash
-# retrieve profile's credentials, save it under 'default' profile, and base64 encode it
-BASE64ENCODED_AWS_ACCOUNT_CREDS=$(echo -e "[default]\naws_access_key_id = $(aws configure get aws_access_key_id --profile $aws_profile)\naws_secret_access_key = $(aws configure get aws_secret_access_key --profile $aws_profile)" | base64 | tr -d "\n")
-# retrieve the profile's region from config
-AWS_REGION=$(aws configure get region --profile ${aws_profile})
-```
-
-At this point, the region and the encoded credentials are stored in respective
-variables. Next, we'll need to create an instance of AWS provider:
-
-```bash
-cat > provider.yaml <
-
-[`aws` command line tool]: https://aws.amazon.com/cli/
-[AWS SDK for GO]: https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/setting-up.html
-[installed]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html
-[configured]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html
-[AWS security credentials]: https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html
-[secret]:https://kubernetes.io/docs/concepts/configuration/secret/
-[setup.sh]: https://github.com/crossplane/crossplane/blob/master/cluster/examples/aws-setup-provider/setup.sh
-[aws named profile]: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html
-[aws user]: https://docs.aws.amazon.com/mediapackage/latest/ug/setting-up-create-iam-user.html
-[Access Key]: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
-[AWS security credentials]: https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html
-[aws command line tool]: https://aws.amazon.com/cli/
-[install-aws]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html
-[aws-cli-configure]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html
-[kubernetes secret]: https://kubernetes.io/docs/concepts/configuration/secret/
-[AWS named profile]: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html
diff --git a/docs/v0.10/cloud-providers/azure/azure-provider.md b/docs/v0.10/cloud-providers/azure/azure-provider.md
deleted file mode 100644
index c566b61f..00000000
--- a/docs/v0.10/cloud-providers/azure/azure-provider.md
+++ /dev/null
@@ -1,125 +0,0 @@
-# Adding Microsoft Azure to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your Azure
-account to be ready for integration with Crossplane. The general steps we will
-take are summarized below:
-
-* Create a new service principal (account) that Crossplane will use to create
- and manage Azure resources
-* Add the required permissions to the account
-* Consent to the permissions using an administrator account
-
-## Preparing your Microsoft Azure Account
-
-In order to manage resources in Azure, you must provide credentials for a Azure
-service principal that Crossplane can use to authenticate. This assumes that you
-have already [set up the Azure CLI
-client](https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli?view=azure-cli-latest)
-with your credentials.
-
-Create a JSON file that contains all the information needed to connect and
-authenticate to Azure:
-
-```bash
-# create service principal with Owner role
-az ad sp create-for-rbac --sdk-auth --role Owner > crossplane-azure-provider-key.json
-```
-
-Take note of the `clientID` value from the JSON file that we just created, and
-save it to an environment variable:
-
-```bash
-export AZURE_CLIENT_ID=
-```
-
-Now add the required permissions to the service principal that will allow it to
-manage the necessary resources in Azure:
-
-```bash
-# add required Azure Active Directory permissions
-az ad app permission add --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --api-permissions 1cda74f2-2616-4834-b122-5cb1b07f8a59=Role 78c8a3c8-a07e-4b9e-af1b-b5ccab50a175=Role
-
-# grant (activate) the permissions
-az ad app permission grant --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --expires never
-```
-
-You might see an error similar to the following, but that is OK, the permissions
-should have gone through still:
-
-```console
-Operation failed with status: 'Conflict'. Details: 409 Client Error: Conflict for url: https://graph.windows.net/e7985bc4-a3b3-4f37-b9d2-fa256023b1ae/oauth2PermissionGrants?api-version=1.6
-```
-
-Finally, you need to grant admin permissions on the Azure Active Directory to
-the service principal because it will need to create other service principals
-for your `AKSCluster`:
-```bash
-# grant admin consent to the service princinpal you created
-az ad app permission admin-consent --id "${AZURE_CLIENT_ID}"
-```
-
-Note: You might need `Global Administrator` role to `Grant admin consent for
-Default Directory`. Please contact the administrator of your Azure subscription.
-To check your role, go to `Azure Active Directory` -> `Roles and
-administrators`. You can find your role(s) by clicking on `Your Role (Preview)`
-
-After these steps are completed, you should have the following file on your
-local filesystem:
-
-* `crossplane-azure-provider-key.json`
-
-## Setup Azure Provider
-
-Before creating any resources, we need to create and configure an Azure cloud
-provider resource in Crossplane, which stores the cloud account information in
-it. All the requests from Crossplane to Azure Cloud will use the credentials
-attached to this provider resource. The following command assumes that you have
-a `crossplane-azure-provider-key.json` file that belongs to the account you’d
-like Crossplane to use.
-
-```bash
-BASE64ENCODED_AZURE_ACCOUNT_CREDS=$(base64 crossplane-azure-provider-key.json | tr -d "\n")
-```
-
-Now we’ll create our `Secret` that contains the credential and `Provider`
-resource that refers to that secret:
-
-```bash
-cat > provider.yaml < provider.yaml <
-
-[not yet implemented]: https://github.com/crossplane/crossplane/issues/314
-[Events]: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#event-v1-core
-[debugging an application cluster]: https://kubernetes.io/docs/tasks/debug-application-cluster/
-[Dave Cheney article]: https://dave.cheney.net/2015/11/05/lets-talk-about-logging
-[`event`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/event
-[`logging`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/logging
-[Do]: https://peter.bourgon.org/go-best-practices-2016/#logging-and-instrumentation
-[not]: https://dave.cheney.net/2017/01/23/the-package-level-logger-anti-pattern
-[`Reconciler`]: https://godoc.org/sigs.k8s.io/controller-runtime/pkg/reconcile#Reconciler
-[managed resource reconciler]: https://github.com/crossplane/crossplane-runtime/blob/a6bb0/pkg/reconciler/managed/reconciler.go#L436
-[wrapping errors]: https://godoc.org/github.com/pkg/errors#Wrap
-[API conventions]: https://github.com/kubernetes/community/blob/09f55c6/contributors/devel/sig-architecture/api-conventions.md#events
diff --git a/docs/v0.10/contributing/overview.md b/docs/v0.10/contributing/overview.md
deleted file mode 100644
index b686c143..00000000
--- a/docs/v0.10/contributing/overview.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: Contributing
-toc: true
-weight: 100
----
-
-# Contributing
-
-The following documentation is for developers who wish to contribute to or
-extend Crossplane. Please [open an
-issue](https://github.com/crossplane/crossplane/issues/new) for any additional
-documentation you would like to see in this section.
-
-1. [Services Developer Guide]
-2. [Observability Developer Guide]
-
-
-
-[Services Developer Guide]: services_developer_guide.md
-[Observability Developer Guide]: observability_developer_guide.md
diff --git a/docs/v0.10/contributing/services_developer_guide.md b/docs/v0.10/contributing/services_developer_guide.md
deleted file mode 100644
index 6b87f735..00000000
--- a/docs/v0.10/contributing/services_developer_guide.md
+++ /dev/null
@@ -1,1180 +0,0 @@
----
-title: Services Developer Guide
-toc: true
-weight: 101
-indent: true
----
-
-# Services Developer Guide
-
-Crossplane Services supports managed service provisioning using `kubectl`. It
-applies the Kubernetes pattern for Persistent Volume (PV) claims and classes to
-managed service provisioning with support for a strong separation of concern
-between app teams and cluster administrators. This guide will walk through the
-process of adding support for a new managed service.
-
-## What Makes a Crossplane Managed Service?
-
-Crossplane builds atop Kubernetes's powerful architecture in which declarative
-configuration, known as resources, are continually 'reconciled' with reality by
-one or more controllers. A controller is an endless loop that:
-
-1. Observes the desired state (the declarative configuration resource).
-1. Observes the actual state (the thing said configuration resource represents).
-1. Tries to make the actual state match the desired state.
-
-A typical Crossplane managed service consists of five configuration resources
-and five controllers. The GCP Provider's support for Google Cloud Memorystore
-illustrates this. First, the configuration resources:
-
-1. A [managed resource]. Managed resources are cluster scoped, high-fidelity
- representations of a resource in an external system such as a cloud
- provider's API. Managed resources are _non-portable_ across external systems
- (i.e. cloud providers); they're tightly coupled to the implementation details
- of the external resource they represent. Managed resources are defined by a
- Provider. The GCP Provider's [`CloudMemorystoreInstance`] resource is an
- example of a managed resource.
-1. A [resource claim]. Resource claims are namespaced abstract declarations of a
- need for a service. Resource claims are frequently portable across external
- systems. Crossplane defines a series of common resource claim kinds,
- including [`RedisCluster`]. A resource claim is satisfied by _binding_ to a
- managed resource.
-1. A [resource class]. Resource classes represent a class of a specific kind of
- managed resource. They are the template used to create a new managed resource
- in order to satisfy a resource claim during [dynamic provisioning]. Resource
- classes are cluster scoped, and tightly coupled to the managed resources they
- template. [`CloudMemorystoreInstanceClass`] is an example of a resource
- class.
-1. A provider. Providers enable access to an external system, typically by
- indicating a Kubernetes Secret containing any credentials required to
- authenticate to the system, as well as any other metadata required to
- connect. Providers are cluster scoped, like managed resources and classes.
- The GCP [`Provider`] is an example of a provider.
-
-These resources are powered by:
-
-1. The managed resource controller. This controller is responsible for taking
- instances of the aforementioned high-fidelity managed resource kind and
- reconciling them with an external system. Managed resource controllers are
- unaware of resource claims or classes. The `CloudMemorystoreInstance`
- controller watches for changes to `CloudMemorystoreInstance` resources and
- calls Google's Cloud Memorystore API to create, update, or delete an instance
- as necessary.
-1. The resource claim scheduling controller. A claim scheduling controller
- exists for each kind of resource class that could satisfy a resource claim.
- This controller is unaware of any external system - it simply schedules
- resource claims to resource classes that match their class selector labels,
- so that they may be handled by the resource claim controller.
-1. The resource claim defaulting controller. A claim defaulting controller
- exists for each kind of resource class that could satisfy a resource claim.
- This controller is unaware of any external system - it allocates resource
- claims that do not specify a class selector to a resource class annotated as
- the default, if any, so that they may be handled by the claim controller.
-1. The resource claim controller. A resource claim controller exists for each
- kind of managed resource that could satisfy a resource claim. This controller
- is unaware of any external system - it responsible only for taking resource
- claims and binding them to a managed resource. The
- `CloudMemorystoreInstance` resource claim controller watches for
- `RedisCluster` resource claims that should be satisfied by a
- `CloudMemorystoreInstance`. It either binds to an explicitly referenced
- `CloudMemorystoreInstance` (static provisioning) or creates a new one and
- then binds to it (dynamic provisioning).
-1. The secret propagation controller. Like the resource claim controller, a
- secret propagation controller exists for each kind of managed resource that
- could satisfy a resource claim. Its job is simply to ensure that changes to
- the connection secret of a managed resource are always propagated to the
- connection secret of the resource claim it is bound to. The secret
- propagation controller is optional - managed resources that only write to
- their connection secret at creation time may omit this controller.
-
-Crossplane does not require controllers to be written in any particular
-language. The Kubernetes API server is our API boundary, so any process capable
-of [watching the API server] and updating resources can be a Crossplane
-controller.
-
-## Getting Started
-
-At the time of writing all Crossplane Services controllers are written in Go,
-and built using [kubebuilder] v0.2.x and [crossplane-runtime]. Per [What Makes a
-Crossplane Managed Service] it is possible to write a controller using any
-language and tooling with a Kubernetes client, but this set of tools are the
-"[golden path]". They're well supported, broadly used, and provide a shared
-language with the Crossplane maintainers. This guide targets [crossplane-runtime
-v0.4.0].
-
-This guide assumes the reader is familiar with the Kubernetes [API Conventions]
-and the [kubebuilder book]. If you're not adding a new managed service to an
-existing Crossplane Provider you should start by working through the [Stacks
-quick start] to scaffold a new Provider in which the new types and controllers
-will live.
-
-## Defining Resource Kinds
-
-Let's assume we want to add Crossplane support for your favourite cloud's
-database-as-a-service. Your favourite cloud brands these instances as "Favourite
-DB instances". Under the hood they're powered by the open source FancySQL
-engine. We'll name the new managed resource kind `FavouriteDBInstance` and the
-new resource claim `FancySQLInstance`.
-
-The first step toward implementing a new managed service is to define the code
-level schema of its configuration resources. These are referred to as
-[resources], (resource) [kinds], and [objects] interchangeably. The kubebuilder
-scaffolding is a good starting point for any new Crossplane API kind, whether
-they'll be a managed resource, resource class, or resource claim.
-
-```console
-# The resource claim.
-kubebuilder create api \
- --group example --version v1alpha1 --kind FancySQLInstance \
- --resource=true --controller=false
-```
-
-The above command should produce a scaffold similar to the below example:
-
-```go
-type FancySQLInstanceSpec struct {
- // INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
- // Important: Run "make" to regenerate code after modifying this file
-}
-
-// FancySQLInstanceStatus defines the observed state of FancySQLInstance
-type FancySQLInstanceStatus struct {
- // INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
- // Important: Run "make" to regenerate code after modifying this file
-}
-
-// +kubebuilder:object:root=true
-
-// FancySQLInstance is the Schema for the fancysqlinstances API
-type FancySQLInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FancySQLInstanceSpec `json:"spec,omitempty"`
- Status FancySQLInstanceStatus `json:"status,omitempty"`
-}
-```
-
-Crossplane requires that these newly generated API type scaffolds be extended
-with a set of struct fields, getters, and setters that are standard to all
-Crossplane resource kinds. The fields and setters differ depending on whether
-the new resource kind is a managed resource, resource claim, or resource class.
-The getters and setter methods required to satisfy the various
-crossplane-runtime interfaces are omitted from the below examples for brevity.
-They can be added by hand, but new services are encouraged to use [`angryjet`]
-to generate them automatically using a `//go:generate` comment per the
-[`angryjet` documentation].
-
-Note that in many cases a suitable provider and resource claim will already
-exist. Frequently adding support for a new managed service requires only the
-definition of a new managed resource and resource class.
-
-### Managed Resource Kinds
-
-Managed resources must:
-
-* Satisfy crossplane-runtime's [`resource.Managed`] interface.
-* Embed a [`ResourceStatus`] struct in their `Status` struct.
-* Embed a [`ResourceSpec`] struct in their `Spec` struct.
-* Embed a `Parameters` struct in their `Spec` struct.
-* Use the `+kubebuilder:subresource:status` [comment marker].
-* Use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-The `Parameters` struct should be a _high fidelity_ representation of the
-writeable fields of the external resource's API. Put otherwise, if your
-favourite cloud represents Favourite DB instances as a JSON object then
-`FavouriteDBParameters` should marshal to a something as close to that JSON
-object as possible while still complying with Kubernetes API conventions.
-
-For example, assume the external API object for Favourite DB instance was:
-
-```json
-{
- "id": 42,
- "name": "mycoolinstance",
- "fanciness_level": 100,
- "version": "2.3",
- "status": "ONLINE",
- "hostname": "cool.fcp.example.org"
-}
-```
-
-Further assume the `id`, `status`, and `hostname` fields were output only, and
-the `version` field was optional. The `FavouriteDBInstance` managed resource
-should look as follows:
-
-```go
-// FavouriteDBInstanceParameters define the desired state of an FavouriteDB
-// instance. Most fields map directly to an Instance:
-// https://favourite.example.org/api/v1/db#Instance
-type FavouriteDBInstanceParameters struct {
-
- // We're still working on a standard for naming external resources. See
- // https://github.com/crossplane/crossplane/issues/624 for context.
-
- // Name of this instance.
- Name string `json:"name"`
-
- // Note that fanciness_level becomes fancinessLevel below. Kubernetes API
- // conventions trump cloud provider fidelity.
-
- // FancinessLevel specifies exactly how fancy this instance is.
- FancinessLevel int `json:"fancinessLevel"`
-
- // Version specifies what version of FancySQL this instance will run.
- // +optional
- Version *string `json:"version,omitempty"`
-}
-
-// A FavouriteDBInstanceSpec defines the desired state of a FavouriteDBInstance.
-type FavouriteDBInstanceSpec struct {
- runtimev1alpha1.ResourceSpec `json:",inline"`
- ForProvider FavouriteDBInstanceParameters `json:"forProvider"`
-}
-
-// A FavouriteDBInstanceStatus represents the observed state of a
-// FavouriteDBInstance.
-type FavouriteDBInstanceStatus struct {
- runtimev1alpha1.ResourceStatus `json:",inline"`
-
- // Note that we add the three "output only" fields here in the status,
- // instead of the parameters. We want this representation to be high
- // fidelity just like the parameters.
-
- // ID of this instance.
- ID int `json:"id,omitempty"`
-
- // Status of this instance.
- Status string `json:"status,omitempty"`
-
- // Hostname of this instance.
- Hostname string `json:"hostname,omitempty"`
-}
-
-// A FavouriteDBInstance is a managed resource that represents a Favourite DB
-// instance.
-// +kubebuilder:subresource:status
-type FavouriteDBInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FavouriteDBInstanceSpec `json:"spec"`
- Status FavouriteDBInstanceStatus `json:"status,omitempty"`
-}
-```
-
-Note that Crossplane uses the GoDoc strings of API kinds to generate user facing
-API documentation. __Document all fields__ and prefer GoDoc that assumes the
-reader is running `kubectl explain`, or reading an API reference, not reading
-the code. Refer to the [Managed Resource API Patterns] one pager for more detail
-on authoring high fidelity managed resources.
-
-### Resource Class Kinds
-
-The resource class kind for a particular managed resource kind are typically
-defined in the same file as their the managed resource. Resource classes must:
-
-* Satisfy crossplane-runtime's [`resource.Class`] interface.
-* Have a `SpecTemplate` struct field instead of a `Spec`.
-* Embed a [`ClassSpecTemplate`] struct in their `SpecTemplate` struct.
-* Embed their managed resource's `Parameters` struct as `ForProvider` in their
- `SpecTemplate` struct.
-* Not have a `Status` struct.
-* Use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-A resource class for the above `FavouriteDBInstance` would look as follows:
-
-```go
-// A FavouriteDBInstanceClassSpecTemplate is a template for the spec of a
-// dynamically provisioned FavouriteDBInstance.
-type FavouriteDBInstanceClassSpecTemplate struct {
- runtimev1alpha1.ClassSpecTemplate `json:",inline"`
- ForProvider FavouriteDBInstanceParameters `json:"forProvider"`
-}
-
-// A FavouriteDBInstanceClass is a resource class. It defines the desired spec
-// of resource claims that use it to dynamically provision a managed resource.
-type FavouriteDBInstanceClass struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- // SpecTemplate is a template for the spec of a dynamically provisioned
- // FavouriteDBInstance.
- SpecTemplate FavouriteDBInstanceSpecTemplate `json:"specTemplate,omitempty"`
-}
-```
-
-### Resource Claim Kinds
-
-Once the underlying managed resource and its resource class have been defined
-the next step is to define the resource claim. Resource claim controllers
-typically live alongside their managed resource controllers (i.e. in an
-infrastructure provider), but at the time of writing all resource claim kinds
-are defined in Crossplane core. This is because resource claims can frequently
-be satisfied by binding to managed resources from more than one cloud. Consider
-[opening a Crossplane issue] to propose adding your new resource claim kind to
-Crossplane if it could be satisfied by managed resources from more than one
-infrastructure provider.
-
-Resource claims must:
-
-* Satisfy crossplane-runtime's [`resource.Claim`] interface.
-* Use (not embed) a [`ResourceClaimStatus`] struct as their `Status` field.
-* Embed a [`ResourceClaimSpec`] struct in their `Spec` struct.
-* Use the `+kubebuilder:subresource:status` [comment marker].
-* **Not** use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-The `FancySQLInstance` resource claim would look as follows:
-
-```go
-// A FancySQLInstanceSpec defines the desired state of a FancySQLInstance.
-type FancySQLInstanceSpec struct {
- runtimev1alpha1.ResourceClaimSpec `json:",inline"`
-
- // Resource claims typically expose few to no spec fields, instead
- // leveraging resource classes to specify detailed configuration. A resource
- // claim should only support a very small set of fields that:
- //
- // * Are applicable to every conceivable managed resource kind that might
- // ever satisfy the claim kind.
- // * Are more likely than average to be interesting to resource claim
- // authors, who frequently want to be concerned with as few configuration
- // details as possible.
-
- // Version specifies what version of FancySQL this instance will run.
- // +optional
- Version *string `json:"version,omitempty"`
-}
-
-// A FancySQLInstance is a portable resource claim that may be satisfied by
-// binding to FancySQL managed resources such as a Favourite Cloud FavouriteDB
-// instance or an Other Cloud AmbivalentDB instance.
-// +kubebuilder:subresource:status
-type FancySQLInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FancySQLInstanceSpec `json:"spec,omitempty"`
- Status runtimev1alpha1.ResourceClaimStatus `json:"status,omitempty"`
-}
-
-// SetBindingPhase of this FancySQLInstance.
-func (i *FancySQLInstance) SetBindingPhase(p runtimev1alpha1.BindingPhase) {
- i.Status.SetBindingPhase(p)
-}
-```
-
-### Provider Kinds
-
-You'll typically only need to add a new Provider kind if you're creating an
-infrastructure provider that adds support for a new infrastructure provider.
-
-Providers must:
-
-* Be named exactly `Provider`.
-* Embed a [`ProviderSpec`] struct in their `Spec` struct.
-* Use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-The Favourite Cloud `Provider` would look as follows. Note that the cloud to
-which it belongs should be indicated by its API group, i.e. its API Version
-would be `favouritecloud.crossplane.io/v1alpha1` or similar.
-
-```go
-// A ProviderSpec defines the desired state of a Provider.
-type ProviderSpec struct {
- runtimev1alpha1.ProviderSpec `json:",inline"`
-
- // Information required outside of the Secret referenced in the embedded
- // runtimev1alpha1.ProviderSpec that is required to authenticate to the provider.
- // ProjectID is used as an example here.
- ProjectID string `json:"projectID"`
-}
-
-// A Provider configures a Favourite Cloud 'provider', i.e. a connection to a
-// particular Favourite Cloud project using a particular Favourite Cloud service
-// account.
-type Provider struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec ProviderSpec `json:"spec"`
-}
-```
-
-### Finishing Touches
-
-At this point we've defined all of the resource kinds necessary to start
-building controllers - a managed resource, a resource class, and a resource
-claim. Before moving on to the controllers:
-
-* Add any kubebuilder [comment markers] that may be useful for your resource.
- Comment markers can be used to validate input, or add additional columns to
- the standard `kubectl get` output, among other things.
-* Run `make generate && make manifests` (or `make reviewable` if you're working
- in one of the projects in the [crossplane org]) to generate Custom Resource
- Definitions and additional helper methods for your new resource kinds.
-* Make sure a `//go:generate` comment exists for [angryjet] and you ran `go
- generate -v ./...`
-* Make sure any package documentation (i.e. `// Package v1alpha1...` GoDoc,
- including package level comment markers) are in a file named `doc.go`.
- kubebuilder adds them to `groupversion_info.go`, but several code generation
- tools only check `doc.go`.
-
-Finally, add convenience [`GroupVersionKind`] variables for each new resource
-kind. These are typically added to either `register.go` or
-`groupversion_info.go` depending on which version of kubebuilder scaffolded the
-API type:
-
-```go
-// FancySQLInstance type metadata.
-var (
- FancySQLInstanceKind = reflect.TypeOf(FancySQLInstance{}).Name()
- FancySQLInstanceKindAPIVersion = FancySQLInstanceKind + "." + GroupVersion.String()
- FancySQLInstanceGroupVersionKind = GroupVersion.WithKind(FancySQLInstanceKind)
-)
-```
-
-Consider opening a draft pull request and asking a Crossplane maintainer for
-review before you start work on the controller!
-
-## Adding Controllers
-
-Crossplane controllers, like those scaffolded by kubebuilder, are built around
-the [controller-runtime] library. controller-runtime flavoured controllers
-encapsulate most of their domain-specific logic in a [`reconcile.Reconciler`]
-implementation. Most Crossplane controllers are one of the three kinds mentioned
-under [What Makes a Crossplane Managed Service]. Each of these controller kinds
-are similar enough across implementations that [crossplane-runtime] provides
-'default' reconcilers. These reconcilers encode what the Crossplane community
-has learned about managing external systems and narrow the problem space from
-reconciling a Kubernetes resource kind with an arbitrary system down to
-Crossplane-specific tasks.
-
-crossplane-runtime provides the following `reconcile.Reconcilers`:
-
-* The [`managed.Reconciler`] reconciles managed resources with external systems
- by instantiating a client of the external API and using it to create, update,
- or delete the external resource as necessary.
-* [`claimscheduling.Reconciler`] reconciles resource claims by scheduling them
- to a resource class that matches their class selector labels (if any).
-* [`claimdefaulting.Reconciler`] reconciles resource claims that omit their
- class selector by defaulting them to a resource class annotated as the default
- (if any).
-* [`claimbinding.Reconciler`] reconciles resource claims with managed resources
- by either binding or dynamically provisioning and then binding them.
-* [`secret.NewReconciler`] reconciles secrets by propagating their data to
- another secret. This controller is typically used to ensure resource claim
- connection secrets remain in sync with the connection secrets of their bound
- managed resources.
-* [`target.Reconciler`] reconciles `KubernetesTarget` resources that reference
- managed resources that provide a hosted Kubernetes service (i.e. GKE, EKS,
- AKS). This controller is used to propagate the connection information of the
- referenced Kubernetes cluster to the namespace of the `KubernetesTarget` in
- the form of a secret.
-
-Crossplane controllers typically differ sufficiently from those scaffolded by
-kubebuilder that there is little value in using kubebuilder to generate a
-controller scaffold.
-
-### Managed Resource Controllers
-
-Managed resource controllers should use [`managed.NewReconciler`] to wrap a
-managed-resource specific implementation of [`managed.ExternalConnecter`]. Parts
-of `managed.Reconciler`'s behaviour is customisable; refer to the
-[`managed.NewReconciler`] GoDoc for a list of options. The following is an
-example controller for the `FavouriteDBInstance` managed resource we defined
-earlier:
-
-```go
-import (
- "context"
- "fmt"
- "strings"
-
- "github.com/pkg/errors"
- corev1 "k8s.io/api/core/v1"
- "k8s.io/apimachinery/pkg/types"
- ctrl "sigs.k8s.io/controller-runtime"
- "sigs.k8s.io/controller-runtime/pkg/client"
-
- // An API client of the hypothetical FavouriteDB service.
- "github.com/fcp-sdk/v1/services/database"
-
- runtimev1alpha1 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
- "github.com/crossplane/crossplane-runtime/pkg/meta"
- "github.com/crossplane/crossplane-runtime/pkg/resource"
- "github.com/crossplane/crossplane-runtime/pkg/reconciler/managed"
-
- "github.com/crossplane/provider-fcp/apis/database/v1alpha3"
- fcpv1alpha3 "github.com/crossplane/provider-fcp/apis/v1alpha3"
-)
-
-type FavouriteDBInstanceController struct{}
-
-// SetupWithManager instantiates a new controller using a managed.Reconciler
-// configured to reconcile FavouriteDBInstances using an ExternalClient produced by
-// connecter, which satisfies the ExternalConnecter interface.
-func (c *FavouriteDBInstanceController) SetupWithManager(mgr ctrl.Manager) error {
- return ctrl.NewControllerManagedBy(mgr).
- Named(strings.ToLower(fmt.Sprintf("%s.%s", v1alpha3.FavouriteDBInstanceKind, v1alpha3.Group))).
- For(&v1alpha3.FavouriteDBInstance{}).
- Complete(managed.NewReconciler(mgr,
- resource.ManagedKind(v1alpha3.FavouriteDBInstanceGroupVersionKind),
- managed.WithExternalConnecter(&connecter{client: mgr.GetClient()})))
-}
-
-// Connecter satisfies the resource.ExternalConnecter interface.
-type connecter struct{ client client.Client }
-
-// Connect to the supplied resource.Managed (presumed to be a
-// FavouriteDBInstance) by using the Provider it references to create a new
-// database client.
-func (c *connecter) Connect(ctx context.Context, mg resource.Managed) (managed.ExternalClient, error) {
- // Assert that resource.Managed we were passed in fact contains a
- // FavouriteDBInstance. We told NewControllerManagedBy that this was a
- // controller For FavouriteDBInstance, so something would have to go
- // horribly wrong for us to encounter another type.
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return nil, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Get the Provider referenced by the FavouriteDBInstance.
- p := &fcpv1alpha3.Provider{}
- if err := c.client.Get(ctx, meta.NamespacedNameOf(i.Spec.ProviderReference), p); err != nil {
- return nil, errors.Wrap(err, "cannot get Provider")
- }
-
- // Get the Secret referenced by the Provider.
- s := &corev1.Secret{}
- n := types.NamespacedName{Namespace: p.Namespace, Name: p.Spec.Secret.Name}
- if err := c.client.Get(ctx, n, s); err != nil {
- return nil, errors.Wrap(err, "cannot get Provider secret")
- }
-
- // Create and return a new database client using the credentials read from
- // our Provider's Secret.
- client, err := database.NewClient(ctx, s.Data[p.Spec.Secret.Key])
- return &external{client: client}, errors.Wrap(err, "cannot create client")
-}
-
-// External satisfies the resource.ExternalClient interface.
-type external struct{ client database.Client }
-
-// Observe the existing external resource, if any. The managed.Reconciler
-// calls Observe in order to determine whether an external resource needs to be
-// created, updated, or deleted.
-func (e *external) Observe(ctx context.Context, mg resource.Managed) (managed.ExternalObservation, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalObservation{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Use our FavouriteDB API client to get an up to date view of the external
- // resource.
- existing, err := e.client.GetInstance(ctx, i.Spec.Name)
-
- // If we encounter an error indicating the external resource does not exist
- // we want to let the managed.Reconciler know so it can create it.
- if database.IsNotFound(err) {
- return managed.ExternalObservation{ResourceExists: false}, nil
- }
-
- // Any other errors are wrapped (as is good Go practice) and returned to the
- // managed.Reconciler. It will update the "Synced" status condition
- // of the managed resource to reflect that the most recent reconcile failed
- // and ensure the reconcile is reattempted after a brief wait.
- if err != nil {
- return managed.ExternalObservation{}, errors.Wrap(err, "cannot get instance")
- }
-
- // The external resource exists. Copy any output-only fields to their
- // corresponding entries in our status field.
- i.Status.Status = existing.GetStatus()
- i.Status.Hostname = existing.GetHostname()
- i.Status.ID = existing.GetID()
-
- // Update our "Ready" status condition to reflect the status of the external
- // resource. Most managed resources use the below well known reasons that
- // the "Ready" status may be true or false, but managed resource authors
- // are welcome to define and use their own.
- switch i.Status.Status {
- case database.StatusOnline:
- // If the resource is available we also want to mark it as bindable to
- // resource claims.
- resource.SetBindable(i)
- i.SetConditions(runtimev1alpha1.Available())
- case database.StatusCreating:
- i.SetConditions(runtimev1alpha1.Creating())
- case database.StatusDeleting:
- i.SetConditions(runtimev1alpha1.Deleting())
- }
-
- // Finally, we report what we know about the external resource. In this
- // hypothetical case FancinessLevel is the only field that can be updated
- // after creation time, so the resource does not need to be updated if
- // the actual fanciness level matches our desired fanciness level. Any
- // ConnectionDetails we return will be published to the managed resource's
- // connection secret if it specified one.
- o := managed.ExternalObservation{
- ResourceExists: true,
- ResourceUpToDate: existing.GetFancinessLevel == i.Spec.FancinessLevel,
- ConnectionDetails: managed.ConnectionDetails{
- runtimev1alpha1.ResourceCredentialsSecretUserKey: []byte(existing.GetUsername()),
- runtimev1alpha1.ResourceCredentialsSecretEndpointKey: []byte(existing.GetHostname()),
- },
- }
-
- return o, nil
-}
-
-// Create a new external resource based on the specification of our managed
-// resource. managed.Reconciler only calls Create if Observe reported
-// that the external resource did not exist.
-func (e *external) Create(ctx context.Context, mg resource.Managed) (managed.ExternalCreation, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalCreation{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
- // Indicate that we're about to create the instance. Remember ExternalClient
- // authors can use a bespoke condition reason here in cases where Creating
- // doesn't make sense.
- i.SetConditions(runtimev1alpha1.Creating())
-
- // Create must return any connection details that are set or returned only
- // at creation time. The managed.Reconciler will merge any details
- // with those returned during the Observe phase.
- password := database.GeneratePassword()
- cd := managed.ConnectionDetails{runtimev1alpha1.ResourceCredentialsSecretPasswordKey: []byte(password)}
-
- // Create a new instance.
- new := database.Instance{Name: i.Name, FancinessLevel: i.FancinessLevel, Version: i.Version}
- err := e.client.CreateInstance(ctx, new, password)
-
- // Note that we use resource.Ignore to squash any error that indicates the
- // external resource already exists. Create implementations must not return
- // an error if asked to create a resource that already exists. Real managed
- // resource controllers are advised to avoid unintentially 'adoptign' an
- // existing, unrelated external resource, per
- // https://github.com/crossplane/crossplane-runtime/issues/27
- return managed.ExternalCreation{ConnectionDetails: cd}, errors.Wrap(resource.Ignore(database.IsExists, err), "cannot create instance")
-}
-
-// Update the existing external resource to match the specifications of our
-// managed resource. managed.Reconciler only calls Update if Observe
-// reported that the external resource was not up to date.
-func (e *external) Update(ctx context.Context, mg resource.Managed) (managed.ExternalUpdate, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalUpdate{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Recall that FancinessLevel is the only field that we _can_ update.
- new := database.Instance{Name: i.Name, FancinessLevel: i.FancinessLevel}
- err := e.client.UpdateInstance(ctx, new)
- return managed.ExternalUpdate{}, errors.Wrap(err, "cannot update instance")
-}
-
-// Delete the external resource. managed.Reconciler only calls Delete
-// when a managed resource with the 'Delete' reclaim policy has been deleted.
-func (e *external) Delete(ctx context.Context, mg resource.Managed) error {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return errors.New("managed resource is not a FavouriteDBInstance")
- }
- // Indicate that we're about to delete the instance.
- i.SetConditions(runtimev1alpha1.Deleting())
-
- // Delete the instance.
- err := e.client.DeleteInstance(ctx, i.Spec.Name)
-
- // Note that we use resource.Ignore to squash any error that indicates the
- // external resource does not exist. Delete implementations must not return
- // an error when asked to delete a non-existent external resource.
- return errors.Wrap(resource.Ignore(database.IsNotFound, err), "cannot delete instance")
-}
-```
-
-### Resource Claim Scheduling Controllers
-
-Scheduling controllers should use [`claimscheduling.NewReconciler`] to specify
-the resource claim kind it schedules and the resource class kind it schedules
-them to. Note that unlike their resource claim kinds, resource claim scheduling
-controllers are always part of the infrastructure provider that defines the
-resource class they schedule claims to. The following is an example controller
-that reconciles the `FancySQLInstance` resource claim by scheduling it to a
-`FavouriteDBInstanceClass`:
-
-```go
-import (
- "fmt"
- "strings"
-
- ctrl "sigs.k8s.io/controller-runtime"
-
- runtimev1alpha1 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
- "github.com/crossplane/crossplane-runtime/pkg/resource"
- "github.com/crossplane/crossplane-runtime/pkg/reconciler/claimscheduling"
-
- // Note that the hypothetical FancySQL resource claim is part of Crossplane,
- // not provider-fcp, because it is (hypothetically) portable across multiple
- // infrastructure providers.
- databasev1alpha1 "github.com/crossplane/crossplane/apis/database/v1alpha1"
-
- "github.com/crossplane/provider-fcp/apis/database/v1alpha3"
-)
-
-type PostgreSQLInstanceClaimSchedulingController struct{}
-
-// SetupWithManager instantiates a new controller using a
-// resource.ClaimSchedulingReconciler configured to reconcile FancySQLInstances
-// by scheduling them to FavouriteDBInstanceClasses.
-func (c *FancySQLInstanceClaimSchedulingController) SetupWithManager(mgr ctrl.Manager) error {
- // It's Crossplane convention to name resource claim scheduling controllers
- // "scheduler.claimkind.resourcekind.resourceapigroup", for example in this
- // case "fancysqlinstance.favouritedbinstance.fcp.crossplane.io".
- name := strings.ToLower(fmt.Sprintf("scheduler.%s.%s.%s",
- databasev1alpha1.FancySQLInstanceKind,
- v1alpha3.FavouriteDBInstanceKind,
- v1alpha3.Group))
-
- return ctrl.NewControllerManagedBy(mgr).
- Named(name).
- For(&databasev1alpha1.FancySQLInstance{}).
- WithEventFilter(resource.NewPredicates(resource.AllOf(
- // Claims must supply a class selector to be scheduled. Claims that
- // do not supply a class selector use a default resource class, if
- // one exists.
- resource.HasClassSelector(),
-
- // Claims with a class reference have either already been scheduled
- // to a resource class, or specified one explicitly.
- resource.HasNoClassReference(),
-
- // Claims with a managed resource reference are either already bound
- // to a managed resource, or are requesting to be bound to an
- // existing managed resource.
- resource.HasNoManagedResourceReference(),
- ))).
- Complete(claimscheduling.NewReconciler(mgr,
- resource.ClaimKind(databasev1alpha1.FancySQLInstanceGroupVersionKind),
- resource.ClassKind(v1alpha3.FavouriteDBInstanceClassGroupVersionKind),
- ))
-}
-```
-
-### Resource Claim Defaulting Controllers
-
-Defaulting controllers are configured almost (but not quite) identically to
-scheduling controllers. They use a [`claimdefaulting.NewReconciler`] to specify
-the resource claim kind they configure and the resource class kind they default
-to. Unlike their resource claim kinds, defaulting controllers are always part of
-the infrastructure provider that defines the resource class they default claims
-to. The following is an example controller that reconciles the
-`FancySQLInstance` resource claim by setting its class reference to a
-`FavouriteDBInstanceClass` annotated as the default class:
-
-```go
-import (
- "fmt"
- "strings"
-
- ctrl "sigs.k8s.io/controller-runtime"
-
- runtimev1alpha1 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
- "github.com/crossplane/crossplane-runtime/pkg/resource"
- "github.com/crossplane/crossplane-runtime/pkg/reconciler/claimdefaulting"
-
- // Note that the hypothetical FancySQL resource claim is part of Crossplane,
- // not provider-fcp, because it is (hypothetically) portable across multiple
- // infrastructure providers.
- databasev1alpha1 "github.com/crossplane/crossplane/apis/database/v1alpha1"
-
- "github.com/crossplane/provider-fcp/apis/database/v1alpha3"
-)
-
-type PostgreSQLInstanceClaimDefaultingController struct{}
-
-// SetupWithManager instantiates a new controller using a
-// resource.ClaimDefaultingReconciler configured to reconcile FancySQLInstances
-// by scheduling them to FavouriteDBInstanceClasses.
-func (c *FancySQLInstanceClaimDefaultingController) SetupWithManager(mgr ctrl.Manager) error {
- // It's Crossplane convention to name resource claim scheduling controllers
- // "defaulter.claimkind.resourcekind.resourceapigroup", for example in this
- // case "fancysqlinstance.favouritedbinstance.fcp.crossplane.io".
- name := strings.ToLower(fmt.Sprintf("scheduler.%s.%s.%s",
- databasev1alpha1.FancySQLInstanceKind,
- v1alpha3.FavouriteDBInstanceKind,
- v1alpha3.Group))
-
- return ctrl.NewControllerManagedBy(mgr).
- Named(name).
- For(&databasev1alpha1.FancySQLInstance{}).
- WithEventFilter(resource.NewPredicates(resource.AllOf(
- // Claims with a class selector desire scheduling to a matching
- // resource class, and are not subject to defaulting.
- resource.HasNoClassSelector(),
-
- // Claims with a class reference have either already been scheduled
- // to a resource class, or specified one explicitly.
- resource.HasNoClassReference(),
-
- // Claims with a managed resource reference are either already bound
- // to a managed resource, or are requesting to be bound to an
- // existing managed resource.
- resource.HasNoManagedResourceReference(),
- ))).
- Complete(claimdefaulting.NewReconciler(mgr,
- resource.ClaimKind(databasev1alpha1.FancySQLInstanceGroupVersionKind),
- resource.ClassKind(v1alpha3.FavouriteDBInstanceClassGroupVersionKind),
- ))
-}
-```
-
-### Resource Claim Controllers
-
-Resource claim controllers should use [`claimbinding.NewReconciler`] to wrap a
-managed-resource specific implementation of
-[`claimbinding.ManagedConfigurator`]. Parts of `claimbinding.Reconciler`'s
-behaviour is customisable; refer to the [`claimbinding.NewReconciler`] GoDoc for
-a list of options. Note that unlike their resource claim kinds, resource claim
-controllers are always part of the infrastructure provider that defines the
-managed resource they reconcile claims with. The following is an example
-controller that reconciles the `FancySQLInstance` resource claim with the
-`FavouriteDBInstance` managed resource:
-
-```go
-import (
- "context"
- "fmt"
- "strings"
-
- "github.com/pkg/errors"
- corev1 "k8s.io/api/core/v1"
- ctrl "sigs.k8s.io/controller-runtime"
- "sigs.k8s.io/controller-runtime/pkg/source"
-
- runtimev1alpha1 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
- "github.com/crossplane/crossplane-runtime/pkg/resource"
- "github.com/crossplane/crossplane-runtime/pkg/reconciler/claimbinding"
-
- // Note that the hypothetical FancySQL resource claim is part of Crossplane,
- // not provider-fcp, because it is (hypothetically) portable across multiple
- // infrastructure providers.
- databasev1alpha1 "github.com/crossplane/crossplane/apis/database/v1alpha1"
-
- "github.com/crossplane/provider-fcp/apis/database/v1alpha3"
-)
-
-type FavouriteDBInstanceClaimController struct{}
-
-// SetupWithManager instantiates a new controller using a resource.ClaimReconciler
-// configured to reconcile FancySQLInstances by binding them to FavouriteDBInstances.
-func (c *FavouriteDBInstanceClaimController) SetupWithManager(mgr ctrl.Manager) error {
- // It's Crossplane convention to name resource claim controllers
- // "claimkind.resourcekind.resourceapigroup", for example in this case
- // "fancysqlinstance.favouritedbinstance.fcp.crossplane.io".
- name := strings.ToLower(fmt.Sprintf("%s.%s.%s",
- databasev1alpha1.FancySQLInstanceKind,
- v1alpha3.FavouriteDBInstanceKind,
- v1alpha3.Group))
-
- // The controller below watches for changes to both FancySQLInstance and
- // FavouriteDBInstance kind resources. We use watch predicates to filter
- // out any requests to reconcile resources that we're not interested in.
- p := resource.NewPredicates(resource.AnyOf(
- // We want to reconcile FancySQLInstance kind resource claims that
- // reference a FavouriteDBInstanceClass.
- resource.HasClassReferenceKind(resource.ClassKind(v1alpha3.FavouriteDBInstanceClassGroupVersionKind),
-
- // We want to reconcile FancySQLInstance kind resource claims that
- // explicitly set their .spec.resourceRef to a FavouriteDBInstance kind
- // managed resource.
- resource.HasManagedResourceReferenceKind(resource.ManagedKind(v1alpha3.FavouriteDBInstanceGroupVersionKind)),
-
- // We want to reconcile FavouriteDBInstance managed resources. Resources
- // without a claim reference will be filtered by the below
- // EnqueueRequestForClaim watch event handler.
- resource.IsManagedKind(resource.ManagedKind(v1alpha3.FavouriteDBInstanceClassGroupVersionKind), mgr.GetScheme()),
- ))
-
- // Create a new resource claim reconciler...
- r := claimbinding.NewReconciler(mgr,
- // ..that uses the supplied claim, class, and managed resource kinds.
- resource.ClaimKind(databasev1alpha1.FancySQLInstanceGroupVersionKind),
- resource.ClassKind(v1alpha3.FavouriteDBInstanceClassGroupVersionKind),
- resource.ManagedKind(v1alpha3.FavouriteDBInstanceGroupVersionKind),
- // The following configurators configure how a managed resource will be
- // configured when one must be dynamically provisioned.
- claimbinding.WithManagedConfigurators(
- claimbinding.ManagedConfiguratorFn(ConfigureFavouriteDBInstance),
- claimbinding.NewObjectMetaConfigurator(mgr.GetScheme()),
- ))
-
- // Note that we watch for both FancySQLInstance and FavouriteDBInstance
- // resources. When the latter passes our predicates we look up the resource
- // claim it references and reconcile that claim.
- return ctrl.NewControllerManagedBy(mgr).
- Named(name).
- Watches(&source.Kind{Type: &v1alpha3.FavouriteDBInstance{}}, &resource.EnqueueRequestForClaim{}).
- For(&databasev1alpha1.FancySQLInstance{}).
- WithEventFilter(p).
- Complete(r)
-}
-
-// ConfigureFavouriteDBInstance is responsible for updating the supplied managed
-// resource using the supplied resource class.
-func ConfigureFavouriteDBInstance(_ context.Context, cm resource.Claim, cs resource.Class, mg resource.Managed) error {
- if _, ok := cm.(*databasev1alpha1.FancySQLInstance); !ok {
- return errors.New("resource claim is not a FancySQLInstance")
- }
-
- class, ok := cs.(*v1alpha3.FavouriteDBInstanceClass)
- if !ok {
- return errors.New("resource class is not a FavouriteDBInstanceClass")
- }
-
- instance, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- instance.Spec = v1alpha3.FavouriteDBInstanceSpec{
- ResourceSpec: runtimev1alpha1.ResourceSpec{
- // It's typical for dynamically provisioned managed resources to
- // store their connection details in a Secret named for the claim's
- // UID. Managed resource secrets are not intended for human
- // consumption; they're copied to the resource claim's secret when
- // the resource is bound.
- WriteConnectionSecretToReference: runtimev1alpha1.SecretReference{
- Namespace: class.SpecTemplate.WriteConnectionSecretsToNamespace,
- Name: string(cm.GetUID()),
- },
- ProviderReference: class.SpecTemplate.ProviderReference,
- ReclaimPolicy: class.SpecTemplate.ReclaimPolicy,
- },
- FavouriteDBInstanceParameters: class.SpecTemplate.FavouriteDBInstanceParameters,
- }
-
- return nil
-}
-```
-
-### Connection Secret Propagation Controller
-
-Managed resource kinds that may update their connection secrets after creation
-time must instantiate a connection secret propagation controller. This
-controller ensures any updates to the managed resource's connection secret are
-propagated to the connection secret of its bound resource claim. The resource
-claim reconciler ensures managed resource and resource claim secrets are
-eligible for use with by the secret propagatation controller by adding the
-appropriate annotations and controller references.
-
-The following controller propagates any changes made to a `FavouriteDBInstance`
-connection secret to the connection secret of its bound `FancySQLInstance`:
-
-```go
-import (
- "fmt"
- "strings"
-
- corev1 "k8s.io/api/core/v1"
- ctrl "sigs.k8s.io/controller-runtime"
- "sigs.k8s.io/controller-runtime/pkg/source"
-
- "github.com/crossplane/crossplane-runtime/pkg/resource"
- "github.com/crossplane/crossplane-runtime/pkg/reconciler/secret"
- databasev1alpha1 "github.com/crossplane/crossplane/apis/database/v1alpha1"
-
- "github.com/crossplane/provider-fcp/apis/database/v1alpha3"
-)
-
-type FavouriteDBInstanceSecretController struct{}
-
-func (c *FavouriteDBInstanceSecretController) SetupWithManager(mgr ctrl.Manager) error {
- p := resource.NewPredicates(resource.AnyOf(
- resource.AllOf(resource.IsControlledByKind(databasev1alpha1.FancySQLInstanceGroupVersionKind), resource.IsPropagated()),
- resource.AllOf(resource.IsControlledByKind(v1alpha3.FavouriteDBInstanceGroupVersionKind), resource.IsPropagator()),
- ))
-
- return ctrl.NewControllerManagedBy(mgr).
- Named(strings.ToLower(fmt.Sprintf("connectionsecret.%s.%s", v1alpha3.FavouriteDBInstanceKind, v1alpha3.Group))).
- Watches(&source.Kind{Type: &corev1.Secret{}}, &resource.EnqueueRequestForPropagated{}).
- For(&corev1.Secret{}).
- WithEventFilter(p).
- Complete(secret.NewReconciler(mgr))
-}
-```
-
-### Target Controller
-
-Managed resources that represent a hosted Kubernetes cluster can be referenced
-by `KubernetesTarget` resources in a namespace where `KubernetesApplication`
-resources want to be created and scheduled to the remote cluster. This
-controller evaluates if a newly created `KubernetesTarget` references its hosted
-Kubernetes cluster managed resource, and if so, propagates its connection
-information to the namespace of the `KubernetesTarget`. It will also set
-annotations on the propagated secret in case there is a connection secret
-controller that is set to continously propagate the connection information as it
-changes.
-
-The following controller propagates the connection secret of a
-`FavouriteCluster` to the namespace of a `KubernetesTarget` that references it.
-Note that `FavouriteCluster` is used instead of `FavouriteDBInstance` due to the
-fact that Target controllers are currently only utilized for managed resources
-that represent a hosted Kubernetes cluster offering.
-
-```go
-import (
- "fmt"
- "strings"
-
- ctrl "sigs.k8s.io/controller-runtime"
-
- "github.com/crossplane/crossplane-runtime/pkg/reconciler/target"
- "github.com/crossplane/crossplane-runtime/pkg/resource"
- workloadv1alpha1 "github.com/crossplane/crossplane/apis/workload/v1alpha1"
-
- "github.com/crossplane/provider-fcp/apis/compute/v1alpha3"
-)
-
-type FavoriteClusterTargetController struct{}
-
-func (c *FavouriteClusterTargetController) SetupWithManager(mgr ctrl.Manager) error {
- p := resource.NewPredicates(resource.HasManagedResourceReferenceKind(resource.ManagedKind(v1alpha3.FavouriteClusterGroupVersionKind)))
-
- r := target.NewReconciler(mgr,
- resource.TargetKind(workloadv1alpha1.KubernetesTargetGroupVersionKind),
- resource.ManagedKind(v1alpha3.FavouriteClusterGroupVersionKind))
-
- return ctrl.NewControllerManagedBy(mgr).
- Named(strings.ToLower(fmt.Sprintf("kubernetestarget.%s.%s", v1alpha3.FavouriteClusterKind, v1alpha3.Group))).
- For(&workloadv1alpha1.KubernetesTarget{}).
- WithEventFilter(p).
- Complete(r)
-}
-```
-
-### Wrapping Up
-
-Once all your controllers are in place you'll want to test them. Note that most
-projects under the [crossplane org] [favor] table driven tests that use Go's
-standard library `testing` package over kubebuilder's Gingko based tests.
-
-Finally, don't forget to plumb any newly added resource kinds and controllers up
-to your controller manager. Simple providers may do this for each type within
-within `main()`, but most more complicated providers take an approach in which
-each package exposes an `AddToScheme` (for resource kinds) or `SetupWithManager`
-(for controllers) function that invokes the same function within its child
-packages, resulting in a `main.go` like:
-
-```go
-import (
- "time"
-
- "sigs.k8s.io/controller-runtime/pkg/client/config"
- "sigs.k8s.io/controller-runtime/pkg/manager"
- "sigs.k8s.io/controller-runtime/pkg/manager/signals"
-
- crossplaneapis "github.com/crossplane/crossplane/apis"
-
- fcpapis "github.com/crossplane/provider-fcp/apis"
- "github.com/crossplane/provider-fcp/pkg/controller"
-)
-
-func main() {
- cfg, err := config.GetConfig()
- if err != nil {
- panic(err)
- }
-
- mgr, err := manager.New(cfg, manager.Options{SyncPeriod: 1 * time.Hour})
- if err != nil {
- panic(err)
- }
-
- if err := crossplaneapis.AddToScheme(mgr.GetScheme()); err != nil {
- panic(err)
- }
-
- if err := fcpapis.AddToScheme(mgr.GetScheme()); err != nil {
- panic(err)
- }
-
- if err := controller.SetupWithManager(mgr); err != nil {
- panic(err)
- }
-
- panic(mgr.Start(signals.SetupSignalHandler()))
-}
-```
-
-## In Review
-
-In this guide we walked through the process of defining all of the resource
-kinds and controllers necessary to build support for a new managed service;
-possibly even a completely new infrastructure provider. Please do not hesitate
-to [reach out] to the Crossplane maintainers and community for help designing
-and implementing support for new managed services. [#sig-services] would highly
-value any feedback you may have about the services development process!
-
-
-
-[What Makes a Crossplane Managed Service]: #what-makes-a-crossplane-managed-service
-[managed resource]: concepts.md#managed-resource
-[resource claim]: concepts.md#resource-claim
-[resource class]: concepts.md#resource-class
-[dynamic provisioning]: concepts.md#dynamic-and-static-provisioning
-[`CloudMemorystoreInstance`]: https://github.com/crossplane/provider-gcp/blob/85a6ed3c669a021f1d61be51b2cbe2714b0bc70b/apis/cache/v1beta1/cloudmemorystore_instance_types.go#L184
-[`CloudMemorystoreInstanceClass`]: https://github.com/crossplane/provider-gcp/blob/85a6ed3c669a021f1d61be51b2cbe2714b0bc70b/apis/cache/v1beta1/cloudmemorystore_instance_types.go#L217
-[`Provider`]: https://github.com/crossplane/provider-gcp/blob/85a6ed3c669a021f1d61be51b2cbe2714b0bc70b/apis/v1alpha3/types.go#L41
-[`RedisCluster`]: https://github.com/crossplane/crossplane/blob/3c6cf4e/apis/cache/v1alpha1/rediscluster_types.go#L40
-[`RedisClusterClass`]: https://github.com/crossplane/crossplane/blob/3c6cf4e/apis/cache/v1alpha1/rediscluster_types.go#L116
-[watching the API server]: https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
-[kubebuilder]: https://kubebuilder.io/
-[controller-runtime]: https://github.com/kubernetes-sigs/controller-runtime
-[crossplane-runtime]: https://github.com/crossplane/crossplane-runtime/
-[crossplane-runtime v0.4.0]: https://github.com/crossplane/crossplane-runtime/releases/tag/v0.4.0
-[golden path]: https://charity.wtf/2018/12/02/software-sprawl-the-golden-path-and-scaling-teams-with-agency/
-[API Conventions]: https://github.com/kubernetes/community/blob/c6e1e89a/contributors/devel/sig-architecture/api-conventions.md
-[kubebuilder book]: https://book.kubebuilder.io/
-[Stacks quick start]: https://github.com/crossplane/crossplane-cli/blob/357d18e7b/README.md#quick-start-stacks
-[resources]: https://kubebuilder.io/cronjob-tutorial/gvks.html#kinds-and-resources
-[kinds]: https://kubebuilder.io/cronjob-tutorial/gvks.html#kinds-and-resources
-[objects]: https://kubernetes.io/docs/concepts/#kubernetes-objects
-[comment marker]: https://kubebuilder.io/reference/markers.html
-[comment markers]: https://kubebuilder.io/reference/markers.html
-[`resource.Managed`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/resource#Managed
-[`resource.Claim`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/resource#Claim
-[`resource.Class`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/resource#Class
-[`managed.Reconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#Reconciler
-[`managed.NewReconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#NewReconciler
-[`claimbinding.Reconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/claimbinding#Reconciler
-[`claimbinding.NewReconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/claimbinding#NewReconciler
-[`claimscheduling.Reconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/claimscheduling#Reconciler
-[`claimscheduling.NewReconciler`]: https://github.com/crossplane/crossplane-runtime/blob/master/pkg/reconciler/claimscheduling/reconciler.go#L83
-[`claimdefaulting.Reconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/claimdefaulting#Reconciler
-[`claimdefaulting.NewReconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/claimdefaulting#NewReconciler
-[`secret.NewReconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/secret#NewReconciler
-[`managed.ExternalConnecter`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalConnecter
-[`managed.ExternalClient`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalClient
-[`claimbinding.ManagedConfigurator`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/claimbinding#ManagedConfigurator
-[`target.Reconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/target#Reconciler
-[`ResourceSpec`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ResourceSpec
-[`ResourceStatus`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ResourceStatus
-[`ResourceClaimSpec`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ResourceClaimSpec
-[`ResourceClaimStatus`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ResourceClaimStatus
-[`ClassSpecTemplate`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ClassSpecTemplate
-[`ProviderSpec`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ProviderSpec
-['managed.ExternalConnecter`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalConnecter
-[opening a Crossplane issue]: https://github.com/crossplane/crossplane/issues/new/choose
-[`GroupVersionKind`]: https://godoc.org/k8s.io/apimachinery/pkg/runtime/schema#GroupVersionKind
-[`reconcile.Reconciler`]: https://godoc.org/sigs.k8s.io/controller-runtime/pkg/reconcile#Reconciler
-[favor]: https://github.com/crossplane/crossplane/issues/452
-[reach out]: https://github.com/crossplane/crossplane#contact
-[#sig-services]: https://crossplane.slack.com/messages/sig-services
-[crossplane org]: https://github.com/crossplane
-[`angryjet`]: https://github.com/crossplane/crossplane-tools
-[Managed Resource API Patterns]: ../design/one-pager-managed-resource-api-design.md
-[Crossplane CLI]: https://github.com/crossplane/crossplane-cli#quick-start-stacks
-[`angryjet` documentation]: https://github.com/crossplane/crossplane-tools/blob/master/README.md
diff --git a/docs/v0.10/getting-started/app.md b/docs/v0.10/getting-started/app.md
deleted file mode 100644
index d7d745ba..00000000
--- a/docs/v0.10/getting-started/app.md
+++ /dev/null
@@ -1,201 +0,0 @@
----
-title: Applications
-toc: true
-weight: 7
-indent: true
----
-
-# From Workloads to Apps
-
-Crossplane *Applications* allow you to define your application and its managed
-service dependencies as a single installable unit. They serve as an abstraction
-above the claims, classes, and managed resources we explored in previous
-sections. They are portable in that they create claims for infrastructure that
-are satisfied by different managed service implementations depending on how your
-Crossplane control cluster is configured.
-
-## Deploying the Wordpress Application on GCP
-
-[Wordpress] is a relatively simple monolithic application that only requires
-compute to run its containerized binary and a connection to a MySQL database.
-Wordpress is typically installed in a Kubernetes cluster using its official
-[Helm chart]. Crossplane applications let you define your application using
-common configuration tools such as [Helm] and [Kustomize], but represent them as
-a [CustomResourceDefinition] in your cluster.
-
-The steps for using a Crossplane application involve defining your
-infrastructure, installing the application, then creating an instance of that
-application. In the [previous section], we completed the first step by creating
-our `GCPSample` instance. In contrast to the GCP provider and GCP sample stack,
-the Wordpress application will be installed with a `StackInstall` instead of a
-`ClusterStackInstall`. This means that the installation will only be available
-in the namespace that we specify.
-
-Create a file named `wordpress-install.yaml` with the following content:
-
-```yaml
-apiVersion: stacks.crossplane.io/v1alpha1
-kind: StackInstall
-metadata:
- name: app-wordpress
- namespace: cp-quickstart
-spec:
- package: crossplane/app-wordpress:master
-```
-
-Then create it in your cluster:
-
-```
-kubectl apply -f wordpress-install.yaml
-```
-
-We can now create Wordpress instances in the `crossplane-quickstart` namespace
-using a single `CustomResourceDefinition`. When we do, a `KubernetesCluster`
-claim and a `MySQLInstance` claim will be created in the namespace, as well as a
-`KubernetesApplication` that contains the Wordpress application components. The
-claims will be satisfied by the `GKEClusterClass` and `CloudSQLInstanceClass` we
-created in the [previous section]. Let's create a `WordpressInstance` and see
-what happens.
-
-Create a file named `my-wordpress.yaml` with the following content:
-
-```yaml
-apiVersion: wordpress.apps.crossplane.io/v1alpha1
-kind: WordpressInstance
-metadata:
- name: my-wordpress
- namespace: cp-quickstart
-spec:
- provisionPolicy: ProvisionNewCluster
-```
-
-Then create it in your cluster:
-
-```
-kubectl apply -f my-wordpress.yaml
-```
-
-You can use the following commands to look at the resources being provisioned:
-
-```
-kubectl -n cp-quickstart get kubernetesclusters
-```
-
-```
-NAME STATUS CLASS-KIND CLASS-NAME RESOURCE-KIND RESOURCE-NAME AGE
-my-wordpress-cluster GKEClusterClass my-gcp-gkeclusterclass GKECluster cp-quickstart-my-wordpress-cluster-jxftn 19s
-```
-
-```
-kubectl -n cp-quickstart get mysqlinstances
-```
-
-```
-NAME STATUS CLASS-KIND CLASS-NAME RESOURCE-KIND RESOURCE-NAME AGE
-my-wordpress-sql CloudSQLInstanceClass my-gcp-cloudsqlinstanceclass-mysql CloudSQLInstance cp-quickstart-my-wordpress-sql-vz9r7 30s
-```
-
-```
-kubectl -n cp-quickstart get kubernetesapplications
-```
-
-```
-NAME CLUSTER STATUS DESIRED SUBMITTED
-my-wordpress-app Pending
-```
-
-It will take some time for the `GKECluster` and `CloudSQLInstance` to be
-provisioned and ready, but when they are, Crossplane will schedule the Wordpress
-`KubernetesApplication` to the remote `GKECluster`, as well as send the
-`CloudSQLInstance` connection information to the remote cluster in the form of a
-`Secret`. Because Wordpress is running in the `GKECluster` that we created in
-the same network as the `CloudSQLInstance`, it will be able to communicate with
-it freely.
-
-When the `KubernetesApplication` has submitted all of its resources to the
-cluster, you should be able to view the IP address of the Wordpress `Service`:
-
-```
-kubectl -n cp-quickstart describe kubernetesapplicationresources my-wordpress-service
-```
-
-```
-Name: my-wordpress-service
-Namespace: cp-quickstart
-Labels: app=my-wordpress
-Annotations:
-API Version: workload.crossplane.io/v1alpha1
-Kind: KubernetesApplicationResource
-Metadata:
- Creation Timestamp: 2020-03-23T23:07:07Z
- Finalizers:
- finalizer.kubernetesapplicationresource.workload.crossplane.io
- Generation: 1
- Owner References:
- API Version: workload.crossplane.io/v1alpha1
- Block Owner Deletion: true
- Controller: true
- Kind: KubernetesApplication
- Name: my-wordpress-app
- UID: c4baec14-c8ac-4c75-94f9-0a1cd3638ea6
- Resource Version: 3509
- Self Link: /apis/workload.crossplane.io/v1alpha1/namespaces/cp-quickstart/kubernetesapplicationresources/my-wordpress-service
- UID: 80f5513a-704c-41f9-b5e9-d681dda85feb
-Spec:
- Target Ref:
- Name: c568d44c-c882-42ca-ab4b-217cd101b269
- Template:
- API Version: v1
- Kind: Service
- Metadata:
- Labels:
- App: wordpress
- Name: wordpress
- Namespace: my-wordpress
- Spec:
- Ports:
- Port: 80
- Selector:
- App: wordpress
- Type: LoadBalancer
-Status:
- Conditioned Status:
- Conditions:
- Last Transition Time: 2020-03-23T23:07:11Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
- Remote:
- Load Balancer:
- Ingress:
- Ip: 34.94.54.204 # the application is running at this IP address
- State: Submitted
-Events:
-```
-
-Navigating to the address in your browser should take you to the Wordpress
-welcome page.
-
-Now you are familiar with **Providers**, **Stacks**, and **Applications**. The
-next step is to build and deploy your own. Take a look at some of our [guides]
-to learn more.
-
-## Clean Up
-
-If you would like to clean up the resources created in this section, run the
-following commands:
-
-```
-kubectl delete -f my-wordpress.yaml
-kubectl delete -f my-gcp.yaml
-```
-
-
-
-[Wordpress]: https://wordpress.org/
-[Helm chart]: https://github.com/bitnami/charts/tree/master/bitnami/wordpress
-[Helm]: https://helm.sh/
-[Kustomize]: https://kustomize.io/
-[CustomResourceDefinition]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[previous section]: stack.md
-[guides]: ../guides/guides.md
diff --git a/docs/v0.10/getting-started/configure.md b/docs/v0.10/getting-started/configure.md
deleted file mode 100644
index e0b6414a..00000000
--- a/docs/v0.10/getting-started/configure.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Configure
-toc: true
-weight: 2
-indent: true
----
-
-# Configure Your Cloud Provider Account
-
-In order for Crossplane to be able to manage resources in a specific cloud
-provider, you will need to create an account for Crossplane to use. Use the
-links below for cloud-specific instructions to create an account that can be
-used throughout the guides:
-
-* [Google Cloud Platform (GCP) Service Account]
-* [Microsoft Azure Service Principal]
-* [Amazon Web Services (AWS) IAM User]
-
-Once you have configured your cloud provider account, you can get started
-provisioning resources!
-
-
-
-[Google Cloud Platform (GCP) Service Account]: ../cloud-providers/gcp/gcp-provider.md
-[Microsoft Azure Service Principal]: ../cloud-providers/azure/azure-provider.md
-[Amazon Web Services (AWS) IAM User]: ../cloud-providers/aws/aws-provider.md
diff --git a/docs/v0.10/getting-started/dynamic.md b/docs/v0.10/getting-started/dynamic.md
deleted file mode 100644
index b45f94c3..00000000
--- a/docs/v0.10/getting-started/dynamic.md
+++ /dev/null
@@ -1,190 +0,0 @@
----
-title: Dynamic Provisioning
-toc: true
-weight: 4
-indent: true
----
-
-# Dynamic Provisioning
-
-While someone in your organization needs to be familiar with the lowest level of
-infrastructure, many people just want a simple workflow for acquiring and using
-infrastructure. Crossplane provides the ability for organizations to define a
-catalog of infrastructure and applications, then for teams and individuals to
-consume from the catalog with application-focused requests. This is made
-possible by *dynamic provisioning*.
-
-## Dynamically Provision a Redis Cluster on GCP
-
-In the [previous example], we created a `CloudMemorystoreInstance`
-then claimed it directly with a `RedisCluster` claim. With dynamic provisioning,
-we can instead create a *resource class* then request request creation of a
-managed resource (and subsequent creation of its external implementation) using
-a claim.
-
-> **Resource Class**: an instance of a cluster-scoped CRD that represents
-> configuration for an external unit of infrastructure. The fields of a resource
-> class CRD map 1-to-1 with the fields exposed by the provider's API, but
-> creating a resource class instance *does not* result in immediate creation of
-> the external unit. The CRDs that represent resource classes on a provider are
-> installed with it.
-
-Create a file named `cloud-memorystore-class.yaml` with the following content:
-
-```yaml
-apiVersion: cache.gcp.crossplane.io/v1beta1
-kind: CloudMemorystoreInstanceClass
-metadata:
- name: cms-class
- labels:
- guide: quickstart
-specTemplate:
- providerRef:
- name: gcp-provider
- writeConnectionSecretsToNamespace: crossplane-system
- reclaimPolicy: Delete
- forProvider:
- tier: STANDARD_HA
- region: us-west2
- memorySizeGb: 1
-```
-
-> *Note: similar to a managed resource, there is no namespace defined on our
-> configuration for the `CloudMemorystoreInstanceClass` above because resource
-> classes are
-> [cluster-scoped].*
-
-You will notice that this looks very similar to the
-`CloudMemorystoreInstanceClass` we created in the previous example. It has the
-same configuration for the external Cloud Memorystore instance, but you will
-notice that it contains a `specTemplate` instead of a `spec`. The `specTemplate`
-will be used later to create a `CloudMemorystoreInstance` that has the same
-configuration as the one in the static provisioning example.
-
-Create the `CloudMemorystoreInstanceClass`:
-
-```
-kubectl apply -f cloud-memorystore-class.yaml
-```
-
-There is nothing to observe yet, we have published this configuration for a
-Cloud Memorystore instance for later use. To actually create our
-`CloudMemorystoreInstance`, we must create a `RedisCluster` claim that
-references the `CloudMemorystoreInstanceClass`. A claim can reference a class in
-two ways:
-
-1. **Class Reference**: this is most similar to the way we referenced the
- managed resource in the previous example. Instead of a `resourceRef` we can
- provide a `classRef`:
-
-```yaml
-apiVersion: cache.crossplane.io/v1alpha1
-kind: RedisCluster
-metadata:
- name: redis-claim-dynamic
- namespace: cp-quickstart
-spec:
- classRef:
- apiVersion: cache.gcp.crossplane.io/v1beta1
- kind: CloudMemorystoreInstanceClass
- name: cms-class
- writeConnectionSecretToRef:
- name: redis-connection-details-dynamic
-```
-
-2. **Class Selector**: this is a more general way to reference a class, and also
- requires less knowledge of the underlying implementation by the claim
- creator. You will notice that the `CloudMemorystoreInstanceClass` we created
- above includes the `guide: quickstart` label. If we include that label in a
- selector on the `RedisCluster` claim, the claim will be scheduled to a class
- that has that label.
-
-> *Note: if multiple classes have a label that is included in the claim's
-> selector, one will be chosen at random.*
-
-```yaml
-apiVersion: cache.crossplane.io/v1alpha1
-kind: RedisCluster
-metadata:
- name: redis-claim-dynamic
- namespace: cp-quickstart
-spec:
- classSelector:
- matchLabels:
- guide: quickstart
- writeConnectionSecretToRef:
- name: redis-connection-details-dynamic
-```
-
-Using a label selector means that the `RedisCluster` claim creator is not
-concerned whether the claim is satisfied by a GCP
-`CloudMemorystoreInstanceClass`, an AWS `ReplicationGroupClass`, an Azure
-`RedisClass`, or other. It allows them to select an implementation based on its
-traits, rather than its provider. Selecting by label is frequently used to
-choose between a set of classes from the same provider, each with with different
-configuration. For instance, we could create three different
-`CloudMemorystoreInstanceClass` with `memorySizeGb: 1`, `memorySizeGb: 5`,
-`memorySizeGb: 10`, and label them `storage: small`, `storage: medium`, and
-`storage: large`. Depending on our application requirements, we can then provide
-a label selector that will find an appropriate implementation. Each of these
-implementations will result in a Redis cluster being created and sufficient
-connection details being propagated to the namespace of the claim.
-
-Create a file name `redis-cluster-dynamic.yaml` and add the content the label
-selector example above. Then, create the claim:
-
-```
-kubectl apply -f redis-cluster-dynamic.yaml
-```
-
-Because the `CloudMemorystoreInstanceClass` is the only Redis-compatible class
-with the `guide: quickstart` label in our cluster, it is guaranteed to be used.
-If you take a look at the `RedisCluster` claim, you should see that the
-`example-cloudmemorystore-class` is being used and a `CloudMemorystoreInstance`
-has been created with the same configuration:
-
-```
-kubectl get -f redis-cluster-dynamic.yaml
-```
-
-```
-NAME STATUS CLASS-KIND CLASS-NAME RESOURCE-KIND RESOURCE-NAME AGE
-redis-claim-dynamic CloudMemorystoreInstanceClass cms-class CloudMemorystoreInstance cp-quickstart-redis-claim-dynamic-vp4dv 4s
-```
-
-You can also view the status of the `CloudMemorystoreInstance` as its external
-resource is being created:
-
-```
-kubectl get cloudmemorystoreinstances
-```
-
-```
-NAME STATUS STATE CLASS VERSION AGE
-cp-quickstart-redis-claim-dynamic-vp4dv CREATING cms-class REDIS_4_0 25s
-```
-
-Once the `CloudMemorystoreInstance` becomes ready and bound, we have found
-ourselves in the same situation as the conclusion of our static provisioning.
-However, we got here with separating the responsibilities of defining and
-consuming infrastructure, and we can create as many `RedisCluster` claims as we
-want with the reusable configuration defined in our
-`CloudMemorystoreInstanceClass`.
-
-Continue to the [next section] to learn how Crossplane can
-schedule workloads to remote Kubernetes clusters!
-
-## Clean Up
-
-If you would like to clean up the resources created in this section, run the
-following command:
-
-```
-kubectl delete -f redis-cluster-dynamic.yaml
-```
-
-
-
-[previous example]: static.md
-[cluster-scoped]: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#create-a-customresourcedefinition
-[next section]: workload.md
diff --git a/docs/v0.10/getting-started/install.md b/docs/v0.10/getting-started/install.md
deleted file mode 100644
index 0a6f7fb9..00000000
--- a/docs/v0.10/getting-started/install.md
+++ /dev/null
@@ -1,365 +0,0 @@
----
-title: Install
-toc: true
-weight: 1
-indent: true
----
-
-# Install Crossplane
-
-Crossplane can be easily installed into any existing Kubernetes cluster using
-the regularly published Helm chart. The Helm chart contains all the custom
-resources and controllers needed to deploy and configure Crossplane.
-
-## Pre-requisites
-
-* [Kubernetes cluster]
- * For example [Minikube], minimum version `v0.28+`
-* [Helm], minimum version `v2.12.0+`.
- * For Helm 2, make sure Tiller is initialized with sufficient permissions to
- work on `crossplane-system` namespace.
-
-## Installation
-
-Helm charts for Crossplane are currently published to the `alpha` and `master`
-channels. In the future, `beta` and `stable` will also be available.
-
-### Alpha
-
-The alpha channel is the most recent release of Crossplane that is considered
-ready for testing by the community.
-
-Install with Helm 2:
-
-```console
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-Install with Helm 3:
-
-If your Kubernetes version is lower than 1.15 and you'd like to install
-Crossplane via Helm 3, you'll need Helm v3.1.0+ that has the flag
-`--disable-openapi-validation`.
-
-```console
-kubectl create namespace crossplane-system
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-
-# Kubernetes 1.15 and newer versions
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane
-
-# Kubernetes 1.14 and older versions
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane --disable-openapi-validation
-```
-
-### Master
-
-The `master` channel contains the latest commits, with all automated tests
-passing. `master` is subject to instability, incompatibility, and features may
-be added or removed without much prior notice. It is recommended to use one of
-the more stable channels, but if you want the absolute newest Crossplane
-installed, then you can use the `master` channel.
-
-To install the Helm chart from master, you will need to pass the specific
-version returned by the `search` command:
-
-Install with Helm 2:
-
-```console
-helm repo add crossplane-master https://charts.crossplane.io/master/
-helm search crossplane --devel
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version
-```
-
-For example:
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version 0.0.0-249.637ccf9
-```
-
-Install with Helm 3:
-
-If your Kubernetes version is lower than 1.15 and you'd like to install
-Crossplane via Helm 3, you'll need Helm v3.1.0+.
-
-```console
-kubectl create namespace crossplane-system
-helm repo add crossplane-master https://charts.crossplane.io/master/
-helm search repo crossplane --devel
-
-# Kubernetes 1.15 and newer versions
-helm install crossplane --namespace crossplane-system crossplane-master/crossplane --version --devel
-
-# Kubernetes 1.14 and older versions
-helm install crossplane --namespace crossplane-system crossplane-master/crossplane --version --devel --disable-openapi-validation
-```
-
-## Installing Infrastructure Providers
-
-You can add additional functionality to Crossplane's control plane by installing
-`providers`. For example, each supported cloud provider has its own
-corresponding Crossplane `provider` that contains all the functionality for that
-particular cloud. After a cloud provider's infrastructure `provider` is
-installed, you will be able to provision and manage resources within that cloud
-from Crossplane.
-
-### Installation with Helm
-
-You can include deployment of additional infrastructure providers into your helm
-installation by setting `clusterStacks..deploy` to `true`.
-
-For example, the following will install `master` version of the GCP stack.
-
-Using Helm 2:
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version --set clusterStacks.gcp.deploy=true --set clusterStacks.gcp.version=master
-```
-
-Using Helm 3:
-
-```console
-kubectl create namespace crossplane-system
-helm install crossplane --namespace crossplane-system crossplane-master/crossplane --version --set clusterStacks.gcp.deploy=true --set clusterStacks.gcp.version=master --devel
-```
-
-See [helm configuration parameters](#configuration) for supported stacks and
-parameters.
-
-### Manual Installation
-
-After Crossplane has been installed, it is possible to extend Crossplane's
-functionality by installing Crossplane providers.
-
-#### GCP Provider
-
-To get started with Google Cloud Platform (GCP), create a file named
-`provider-gcp.yaml` with the following content:
-
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
- name: gcp
----
-apiVersion: stacks.crossplane.io/v1alpha1
-kind: ClusterStackInstall
-metadata:
- name: provider-gcp
- namespace: gcp
-spec:
- package: "crossplane/provider-gcp:v0.9.0"
-```
-
-Then you can install the GCP provider into Crossplane in the `gcp` namespace
-with the following command:
-
-```console
-kubectl apply -f provider-gcp.yaml
-```
-
-#### AWS Provider
-
-To get started with Amazon Web Services (AWS), create a file named
-`provider-aws.yaml` with the following content:
-
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
- name: aws
----
-apiVersion: stacks.crossplane.io/v1alpha1
-kind: ClusterStackInstall
-metadata:
- name: provider-aws
- namespace: aws
-spec:
- package: "crossplane/provider-aws:v0.9.0"
-```
-
-Then you can install the AWS provider into Crossplane in the `aws` namespace
-with the following command:
-
-```console
-kubectl apply -f provider-aws.yaml
-```
-
-#### Azure Provider
-
-To get started with Microsoft Azure, create a file named `provider-azure.yaml`
-with the following content:
-
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
- name: azure
----
-apiVersion: stacks.crossplane.io/v1alpha1
-kind: ClusterStackInstall
-metadata:
- name: provider-azure
- namespace: azure
-spec:
- package: "crossplane/provider-azure:v0.9.0"
-```
-
-Then you can install the Azure provider into Crossplane in the `azure` namespace
-with the following command:
-
-```console
-kubectl apply -f provider-azure.yaml
-```
-
-#### Rook Provider
-
-To get started with Rook, create a file named `provider-rook.yaml` with the
-following content:
-
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
- name: rook
----
-apiVersion: stacks.crossplane.io/v1alpha1
-kind: ClusterStackInstall
-metadata:
- name: provider-rook
- namespace: rook
-spec:
- package: "crossplane/provider-rook:v0.6.0"
-```
-
-Then you can install the Rook provider into Crossplane in the `rook` namespace
-with the following command:
-
-```console
-kubectl apply -f provider-rook.yaml
-```
-
-### Uninstalling Infrastructure Providers
-
-The infrastructure can be uninstalled simply by deleting the provider resources
-from the cluster with a command similar to what's shown below. **Note** that
-this will also **delete** any resources that Crossplane has provisioned in the
-cloud provider if their `ReclaimPolicy` is set to `Delete`.
-
-After you have ensured that you are completely done with all your cloud provider
-resources, you can then run one of the commands below, depending on which cloud
-provider you are removing, to remove its provider from Crossplane:
-
-#### Uninstalling GCP
-
-```console
-kubectl delete -f provider-gcp.yaml
-```
-
-#### Uninstalling AWS
-
-```console
-kubectl delete -f provider-aws.yaml
-```
-
-#### Uninstalling Azure
-
-```console
-kubectl delete -f provider-azure.yaml
-```
-
-#### Uninstalling Rook
-
-```console
-kubectl delete -f provider-rook.yaml
-```
-
-## Uninstalling the Chart
-
-To uninstall/delete the `crossplane` deployment:
-
-```console
-helm delete --purge crossplane
-```
-
-That command removes all Kubernetes components associated with Crossplane,
-including all the custom resources and controllers.
-
-## Configuration
-
-The following tables lists the configurable parameters of the Crossplane chart
-and their default values.
-
-| Parameter | Description | Default |
-| -------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------ |
-| `image.repository` | Image | `crossplane/crossplane` |
-| `image.tag` | Image tag | `master` |
-| `image.pullPolicy` | Image pull policy | `Always` |
-| `imagePullSecrets` | Names of image pull secrets to use | `dockerhub` |
-| `replicas` | The number of replicas to run for the Crossplane operator | `1` |
-| `deploymentStrategy` | The deployment strategy for the Crossplane operator | `RollingUpdate` |
-| `clusterStacks.aws.deploy` | Deploy AWS stack | `false`
-| `clusterStacks.aws.version` | AWS provider version to deploy | ``
-| `clusterStacks.gcp.deploy` | Deploy GCP stack | `false`
-| `clusterStacks.gcp.version` | GCP provider version to deploy | ``
-| `clusterStacks.azure.deploy` | Deploy Azure stack | `false`
-| `clusterStacks.azure.version` | Azure provider version to deploy | ``
-| `clusterStacks.rook.deploy` | Deploy Rook stack | `false`
-| `clusterStacks.rook.version` | Rook provider version to deploy | ``
-| `personas.deploy` | Install roles and bindings for Crossplane user personas | `true`
-| `templateStacks.enabled` | Enable experimental template stacks support | `true`
-| `templateStacks.controllerImage` | Template Stack controller image | `crossplane/templating-controller:v0.2.1`
-| `resourcesCrossplane.limits.cpu` | CPU resource limits for Crossplane | `100m`
-| `resourcesCrossplane.limits.memory` | Memory resource limits for Crossplane | `512Mi`
-| `resourcesCrossplane.requests.cpu` | CPU resource requests for Crossplane | `100m`
-| `resourcesCrossplane.requests.memory` | Memory resource requests for Crossplane | `256Mi`
-| `resourcesStackManager.limits.cpu` | CPU resource limits for StackManager | `100m`
-| `resourcesStackManager.limits.memory` | Memory resource limits for StackManager | `512Mi`
-| `resourcesStackManager.requests.cpu` | CPU resource requests for StackManager | `100m`
-| `resourcesStackManager.requests.memory` | Memory resource requests for StackManager | `256Mi`
-| `forceImagePullPolicy` | Force the named ImagePullPolicy on Stack install and containers | ``
-| `insecureAllowAllApigroups` | Enable core Kubernetes API group permissions for Stacks. When enabled, Stacks may declare dependency on core Kubernetes API types.) | `false` |
-| `insecurePassFullDeployment` | Enable stacks to pass their full deployment, including security context. When omitted, Stacks deployments will have security context removed and all containers will have `allowPrivilegeEscalation` set to false. | `false` |
-
-### Command Line
-
-You can pass the settings with helm command line parameters. Specify each
-parameter using the `--set key=value[,key=value]` argument to `helm install`.
-For example, the following command will install Crossplane with an image pull
-policy of `IfNotPresent`.
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane --set image.pullPolicy=IfNotPresent
-```
-
-### Settings File
-
-Alternatively, a yaml file that specifies the values for the above parameters
-(`values.yaml`) can be provided while installing the chart.
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane -f values.yaml
-```
-
-Here are the sample settings to get you started.
-
-```yaml
-replicas: 1
-
-deploymentStrategy: RollingUpdate
-
-image:
- repository: crossplane/crossplane
- tag: master
- pullPolicy: Always
-
-imagePullSecrets:
-- dockerhub
-```
-
-
-
-[Kubernetes cluster]: https://kubernetes.io/docs/setup/
-[Minikube]: https://kubernetes.io/docs/tasks/tools/install-minikube/
-[Helm]: https://docs.helm.sh/using_helm/
diff --git a/docs/v0.10/getting-started/stack.md b/docs/v0.10/getting-started/stack.md
deleted file mode 100644
index feaef4ad..00000000
--- a/docs/v0.10/getting-started/stack.md
+++ /dev/null
@@ -1,126 +0,0 @@
----
-title: Stacks
-toc: true
-weight: 6
-indent: true
----
-
-# Defining Infrastructure Environments with Stacks
-
-Though defining your infrastructure as reusable classes and being able to
-dynamically provision resources with the same configuration makes for a much
-better workflow, it is still a fair amount of work to set up a service catalog,
-especially when secure connectivity is required between numerous infrastructure
-components. For example, a workload in a remote Kubernetes cluster may want to
-communicate with a database that is not exposed over the public internet.
-Depending on the provider being used, this can involve VPCs, subnetworks,
-security groups and more. Frequently, setting up these networking components is
-a repeated task that may take place in multiple regions and accounts.
-
-Crossplane *Stacks* allow you to group a collection of managed resources and
-classes into a single unit that can be installed into your cluster as a
-[CustomResourceDefinition]. Let's take a look at installing a minimal stack for
-commonly used GCP resources.
-
-
-## Installing and Using the GCP Sample Stack
-
-[GCP Sample Stack] is a Crossplane stack that includes the following managed
-resources:
-
-* `Network`
-* `Subnetwork`
-* `GlobalAddress`
-* `Connection`
-
-Because these are managed resources, they will be created immediately (i.e.
-static provisioning. The following resource classes will also be created. They
-are configured with references to the networking resources above so when we
-dynamically provision resources using these classes they will be created in the
-provisioned `Network`, `Subnetwork`, etc.
-
-* `GKEClusterClass`
-* `CloudSQLInstanceClass`
-* `CloudMemorystoreInstanceClass`
-
-The GCP sample stack will also create a `Provider` resource for us, so we can go
-ahead and delete the one we have been using:
-
-```
-kubectl delete provider.gcp.crossplane.io gcp-provider
-```
-
-Now, similar to how we installed the GCP provider at the beginning, we can
-install a Crossplane stack with a `ClusterStackInstall`. Create the a file named
-`stack-gcp-sample.yaml` with the following content:
-
-```yaml
-apiVersion: stacks.crossplane.io/v1alpha1
-kind: ClusterStackInstall
-metadata:
- name: stack-gcp-sample
- namespace: crossplane-system
-spec:
- package: crossplane/stack-gcp-sample:master
-```
-
-Then create it in your cluster:
-
-```
-kubectl apply -f stack-gcp-sample.yaml
-```
-
-Creating this resource does not actually cause any of the resources listed above
-to be created. Instead it creates a `CustomResourceDefinition` in your cluster
-that allows you to repeatedly create instance of the environment defined by the
-stack. To create an instance of the GCP sample stack, create a file named
-`my-gcp.yaml` with the following content:
-
-```yaml
-apiVersion: gcp.stacks.crossplane.io/v1alpha1
-kind: GCPSample
-metadata:
- name: my-gcp
-spec:
- region: us-west2
- projectID: # replace with the project ID you created your Provider with earlier
- credentialsSecretRef:
- name: gcp-account-creds
- namespace: crossplane-system
- key: credentials
-```
-
-Then create the instance:
-
-```
-kubectl apply -f my-gcp.yaml
-```
-
-Crossplane will immediately create the managed resources and classes that are
-part of the GCP sample stack.
-
-Now that we have general set of infrastructure and classes defined in our
-cluster, it is time to deploy some applications. In the [previous section], we
-bundled resources into a `KubernetesApplication` and created it in the control
-cluster. This is useful for applications that are deployed infrequently and are
-not widely distributed, but can be a burden for someone who is not familiar with
-the architecture to manage. In the [next section] we will explore how Crossplane
-*Applications* make it possible to package and distribute your configuration,
-including managed services that an application consumes.
-
-## Clean Up
-
-The resources created in this section will be used in the next one as well, but
-if you do not intend to go through the next section and would like to clean up
-the resources created in this section, run the following command:
-
-```
-kubectl delete -f my-gcp.yaml
-```
-
-
-
-[CustomResourceDefinition]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[GCP Sample Stack]: https://github.com/crossplane/stack-gcp-sample
-[previous section]: workload.md
-[next section]: app.md
diff --git a/docs/v0.10/getting-started/static.md b/docs/v0.10/getting-started/static.md
deleted file mode 100644
index f6a53283..00000000
--- a/docs/v0.10/getting-started/static.md
+++ /dev/null
@@ -1,274 +0,0 @@
----
-title: Static Provisioning
-toc: true
-weight: 3
-indent: true
----
-
-# Static Provisioning
-
-Crossplane supports provisioning resources *statically* and *dynamically*.
-Static provisioning is the traditional manner of creating new infrastructure
-using an infrastructure as code tool. To statically provision a resource, you
-provide all necessary configuration and Crossplane simply takes your
-configuration and submits it to the cloud provider.
-
-Where Crossplane differs from an infrastructure as code tool is that it
-continues to manage your resources after they are created. Let's take a look at
-a simple example. We will use GCP for this quick start, but you can achieve the
-same functionality of any of the providers mentioned in the [installation] and
-[configuration] sections. You should have your provider of choice installed and
-should have created a `Provider` resource with the necessary credentials. We
-will use a [GCP `Provider`] resource with name `gcp-provider` below.
-
-## Statically Provision a Redis Cluster on GCP
-
-GCP provides Redis clusters using [Cloud Memorystore]. The GCP Crossplane
-provider installs a `CloudMemorystoreInstance` [CustomResourceDefinition] (CRD)
-which makes the API type available in your Kubernetes cluster. Creating an
-instance of this CRD will result in the creation of a corresponding Cloud
-Memorystore instance on GCP. CRDs like `CloudMemorystoreInstance` are referred
-to as **Managed Resources** in Crossplane.
-
-> **Managed Resource**: a cluster-scoped custom resource that represents an
-> external unit of infrastructure. The fields of a managed resource CRD map
-> 1-to-1 with the fields exposed by the provider's API, and creation of a
-> managed resource result in immediate creation of external unit. The CRDs that
-> represent managed resources on a provider are installed with it.
-
-The fields available on the `CloudMemorystoreInstance` CRD match the ones
-exposed by GCP, so you can configure it however you see fit.
-
-Create a file named `cloud-memorystore.yaml` with the following content:
-
-```yaml
-apiVersion: cache.gcp.crossplane.io/v1beta1
-kind: CloudMemorystoreInstance
-metadata:
- name: example-cloudmemorystore-instance
-spec:
- providerRef:
- name: gcp-provider
- writeConnectionSecretToRef:
- name: example-cloudmemorystore-connection-details
- namespace: crossplane-system
- reclaimPolicy: Delete
- forProvider:
- tier: STANDARD_HA
- region: us-west2
- memorySizeGb: 1
-```
-
-> *Note: there is no namespace defined on our configuration for the
-> `CloudMemorystoreInstance` above because it is [cluster-scoped].*
-
-Now, create a `CloudMemorystoreInstance` in your cluster with the following
-command:
-
-```
-kubectl apply -f cloud-memorystore.yaml
-```
-
-The GCP provider controllers will see the creation of this
-`CloudMemorystoreInstance` and subsequently create it on GCP. You can log in to
-the GCP console to view the the status of the resource, but Crossplane will also
-propagate the status back to the `CloudMemorystore` object itself. This allows
-you to manage your infrastructure without ever leaving `kubectl`.
-
-```
-kubectl describe -f cloud-memorystore.yaml
-```
-
-```
-Name: example-cloudmemorystore-instance
-Namespace:
-Labels:
-Annotations: crossplane.io/external-name: example-cloudmemorystore-instance
- kubectl.kubernetes.io/last-applied-configuration:
- {"apiVersion":"cache.gcp.crossplane.io/v1beta1","kind":"CloudMemorystoreInstance","metadata":{"annotations":{},"name":"example-cloudmemory...
-API Version: cache.gcp.crossplane.io/v1beta1
-Kind: CloudMemorystoreInstance
-Metadata:
- Creation Timestamp: 2020-03-23T19:28:14Z
- Finalizers:
- finalizer.managedresource.crossplane.io
- Generation: 2
- Resource Version: 1476
- Self Link: /apis/cache.gcp.crossplane.io/v1beta1/cloudmemorystoreinstances/example-cloudmemorystore-instance
- UID: 68be2036-4716-4c82-be5c-7923f1f8d6b1
-Spec:
- For Provider:
- Alternative Location Id: us-west2-a
- Authorized Network: projects/crossplane-playground/global/networks/default
- Location Id: us-west2-b
- Memory Size Gb: 1
- Redis Version: REDIS_4_0
- Region: us-west2
- Tier: STANDARD_HA
- Provider Ref:
- Name: gcp-provider
- Reclaim Policy: Delete
- Write Connection Secret To Ref:
- Name: example-cloudmemorystore-connection-details
- Namespace: crossplane-system
-Status:
- At Provider:
- Create Time: 2020-03-23T19:28:16Z
- Name: projects/crossplane-playground/locations/us-west2/instances/example-cloudmemorystore-instance
- Persistence Iam Identity: serviceAccount:651413264395-compute@developer.gserviceaccount.com
- Port: 6379
- State: CREATING
- Conditions:
- Last Transition Time: 2020-03-23T19:28:14Z
- Reason: Successfully resolved resource references to other resources
- Status: True
- Type: ReferencesResolved
- Last Transition Time: 2020-03-23T19:28:14Z
- Reason: Resource is being created
- Status: False
- Type: Ready
- Last Transition Time: 2020-03-23T19:28:17Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal CreatedExternalResource 14s managed/cloudmemorystoreinstance.cache.gcp.crossplane.io Successfully requested creation of external resource
-```
-
-When the resource is done provisioning on GCP, you should see the `State` turn
-from `CREATING` to `READY`, and a corresponding event will be emitted. At this
-point, Crossplane will create a `Secret` that contains any connection
-information for the external resource. The `Secret` is created in the location
-we specified in our configuration:
-
-```yaml
-writeConnectionSecretToRef:
- name: example-cloudmemorystore-connection-details
- namespace: crossplane-system
-```
-
-It will take some time to provision, but once the `CloudMemorystoreInstance` is
-ready, take a look at the contents of the `Secret`:
-
-```
-kubectl -n crossplane-system describe secret example-cloudmemorystore-connection-details
-```
-
-```
-Name: example-cloudmemorystore-connection-details
-Namespace: crossplane-system
-Labels:
-Annotations:
-
-Type: Opaque
-
-Data
-====
-endpoint: 14 bytes
-port: 4 bytes
-```
-
-You will also see that the `CloudMemorystoreInstance` resource is still
-reporting `Status: Unbound`. This is because we have not *claimed* it for usage
-yet.
-
-Crossplane follows a similar pattern to [Kubernetes persistent volumes]. When
-you statically provision a resource in Crossplane, the external resource is also
-created. However, when you want to use a resource, you create an
-application-focused **claim** for it. In this case, we will create a
-`RedisCluster` claim for the `CloudMemorystoreInstance`. Because we know exactly
-which `CloudMemorystoreInstance` we want to use, we reference it directly from
-the claim.
-
-> **Claim**: a namespace-scoped custom resources that represents a claim for
-> usage of a managed resource. Claims are abstract types, like `RedisCluster`,
-> that have support across multiple providers. A claim may be satisfied by many
-> different managed resource types. For instance, a `RedisCluster` can be
-> satisfied by an instance of a GCP `CloudMemorystoreInstance`, an AWS
-> `ReplicationGroup`, or an Azure `Redis`. It could also be satisfied by
-> different configurations of a single resource type. For instance, you may have
-> a large, medium, and small storage `CloudMemorystoreInstance`. When a claim
-> becomes *bound* to a managed resource, any connection information from the
-> managed resource (i.e. usernames, password, IP addresses, etc.) is propagated
-> to the namespace of the claim.
-
-First, let's create a `Namespace` for our claim:
-
-```
-kubectl create namespace cp-quickstart
-```
-
-Next, create a file named `redis-cluster-static.yaml` with the following
-content:
-
-```yaml
-apiVersion: cache.crossplane.io/v1alpha1
-kind: RedisCluster
-metadata:
- name: redis-claim-static
- namespace: cp-quickstart
-spec:
- resourceRef:
- apiVersion: cache.gcp.crossplane.io/v1beta1
- kind: CloudMemorystoreInstance
- name: example-cloudmemorystore-instance
- writeConnectionSecretToRef:
- name: redis-connection-details-static
-```
-
-Now, create `RedisCluster` claim in your cluster with the following command:
-
-```
-kubectl apply -f redis-cluster-static.yaml
-```
-
-You should see the the claim was created, and is now bound:
-
-```
-kubectl get -f redis-cluster-static.yaml
-```
-
-```
-NAME STATUS CLASS-KIND CLASS-NAME RESOURCE-KIND RESOURCE-NAME AGE
-redis-claim-static Bound CloudMemorystoreInstance example-cloudmemorystore-instance 12s
-```
-
-You should also notice that the connection `Secret` we looked at earlier has now
-been propagated to the namespace of our claim:
-
-```
-kubectl -n cp-quickstart get secrets
-```
-
-```
-NAME TYPE DATA AGE
-default-token-cnhfn kubernetes.io/service-account-token 3 74s
-redis-connection-details-static Opaque 2 36s
-```
-
-We have now created and prepared an external managed service for usage using
-only `kubectl`, but it was a fairly manual process that required familiarity
-with the underlying Redis implementation (Cloud Memorystore). This can be made
-easier with *[dynamic provisioning]*.
-
-## Clean Up
-
-If you would like to clean up the resources created in this section, run the
-following command:
-
-```
-kubectl delete -f redis-cluster-static.yaml
-```
-
-
-
-[installation]: install.md
-[configuration]: configure.md
-[GCP `Provider`]: cloud-providers/gcp/gcp-provider.md
-[Cloud Memorystore]: https://cloud.google.com/memorystore
-[CustomResourceDefinition]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[cluster-scoped]: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#create-a-customresourcedefinition
-[Kubernetes persistent volumes]: https://kubernetes.io/docs/concepts/storage/persistent-volumes/
-[dynamic provisioning]: dynamic.md
diff --git a/docs/v0.10/getting-started/workload.md b/docs/v0.10/getting-started/workload.md
deleted file mode 100644
index 5f691749..00000000
--- a/docs/v0.10/getting-started/workload.md
+++ /dev/null
@@ -1,345 +0,0 @@
----
-title: Scheduling Workloads
-toc: true
-weight: 5
-indent: true
----
-
-# Scheduling Workloads to Remote Clusters
-
-In the previous two examples, we provisioned infrastructure that is consumed by
-some form of application. However, many providers expose services that you run
-your application on. The most obvious example of this type of service would be a
-managed Kubernetes service, such as [GKE], [EKS], or [AKS]. Crossplane not only
-provisions and manages these types of infrastructure, but also allows you to
-schedule workloads to them.
-
-In the case of a Kubernetes cluster, Crossplane lets you schedule to remote
-Kubernetes clusters from a single *control cluster*. The remote cluster may have
-been, but does not have to been *provisioned* by Crossplane. Importantly, each
-remote cluster maintains its own *control plane*. Crossplane is only responsible
-for sending configuration data to the remote cluster.
-
-> **Control Cluster**: the Kubernetes cluster where Crossplane is installed. It
-> may also be used to run workloads besides Crossplane controllers, but it is
-> not required to do so.
-
-> **Remote Cluster**: a Kubernetes cluster that Crossplane has access to and may
-> schedule workloads to. A remote cluster may have been created from the
-> Crossplane control cluster using a provider's managed Kubernetes service, or
-> it may be an existing cluster whose connection information was imported into
-> the control cluster.
-
-## Provisioning a GKE Cluster and Scheduling a Workload to it
-
-By this point, you are familiar with both dynamic and static provisioning. In
-this example, we will dynamically provision a `GKECluster`, but will focus on
-what happens after it is ready and bound.
-
-Create a file named `gke-cluster-class.yaml` with the following content:
-
-```yaml
-apiVersion: compute.gcp.crossplane.io/v1alpha3
-kind: GKEClusterClass
-metadata:
- name: gkecluster-standard
- labels:
- guide: quickstart
-specTemplate:
- writeConnectionSecretsToNamespace: crossplane-system
- machineType: n1-standard-1
- numNodes: 1
- zone: us-central1-b
- providerRef:
- name: gcp-provider
- reclaimPolicy: Delete
-```
-
-Create the `GKEClusterClass` resource in your cluster:
-
-```
-kubectl apply -f gke-cluster-class.yaml
-```
-
-Now create a file named `k8s-cluster.yaml` with the following content:
-
-```yaml
-apiVersion: compute.crossplane.io/v1alpha1
-kind: KubernetesCluster
-metadata:
- name: k8scluster
- namespace: cp-quickstart
- labels:
- cluster: hello-world
-spec:
- classSelector:
- matchLabels:
- example: "true"
- writeConnectionSecretToRef:
- name: k8scluster
-```
-
-Then create the `KubernetesCluster` claim in your cluster:
-
-```
-kubectl apply -f k8s-cluster.yaml
-```
-
-As before, a `GKECluster` managed resource should be created and its connection
-information will be propagated to the `cp-quickstart` namespace when it is ready
-and bound:
-
-```
-kubectl get -f k8scluster.yaml
-```
-
-```
-NAME STATUS CLASS-KIND CLASS-NAME RESOURCE-KIND RESOURCE-NAME AGE
-k8scluster GKEClusterClass gkecluster-standard GKECluster cp-quickstart-k8scluster-88426 36s
-```
-
-As you may have guessed, the connection information for a `KubernetesCluster`
-claim contains [kubeconfig] information. Once the `KubernetesCluster` claim is
-bound, you can view the contents of the `Secret` in the `cp-quickstart`
-namespace:
-
-```
-kubectl -n cp-quickstart describe secret k8scluster
-```
-
-The `KubernetesCluster` claim is also unique from other claim types in that when
-it becomes bound, Crossplane automatically creates a `KubernetesTarget` that
-references the connection secret in the same namespace. You can see the
-`KubernetesTarget` that Crossplane created for this `KubernetesCluster` claim:
-
-```
-kubectl -n cp-quickstart get kubernetestargets
-```
-
-> *Note: a `KubernetesTarget` that is automatically created by Crossplane for a
-> bound `KubernetesCluster` claim will have the same labels as the
-> `KubernetesCluster` claim.*
-
-To schedule workloads to remote clusters, Crossplane requires those resource to
-be wrapped in a `KubernetesApplication`.
-
-> **Kubernetes Application**: a custom resource that bundles other resources
-> that are intended to be run on a remote Kubernetes cluster. Creating a
-> `KubernetesApplication` will cause Crossplane to find a suitable
-> `KubernetesTarget` and attempt to create the bundled resources on the
-> referenced `KubernetesCluster` using its connection `Secret`.
-
-We can start by bundling a simple hello world app with a `Namespace`,
-`Deployment`, and `Service` for scheduling to our GKE cluster.
-
-Create a file named `helloworld.yaml` with the following content:
-
-```yaml
-apiVersion: workload.crossplane.io/v1alpha1
-kind: KubernetesApplication
-metadata:
- name: helloworld
- namespace: cp-quickstart
- labels:
- app: helloworld
-spec:
- resourceSelector:
- matchLabels:
- app: helloworld
- targetSelector:
- matchLabels:
- cluster: hello-world
- resourceTemplates:
- - metadata:
- name: helloworld-namespace
- labels:
- app: helloworld
- spec:
- template:
- apiVersion: v1
- kind: Namespace
- metadata:
- name: helloworld
- labels:
- app: helloworld
- - metadata:
- name: helloworld-deployment
- labels:
- app: helloworld
- spec:
- template:
- apiVersion: apps/v1
- kind: Deployment
- metadata:
- name: helloworld-deployment
- namespace: helloworld
- spec:
- selector:
- matchLabels:
- app: helloworld
- replicas: 1
- template:
- metadata:
- labels:
- app: helloworld
- spec:
- containers:
- - name: hello-world
- image: gcr.io/google-samples/node-hello:1.0
- ports:
- - containerPort: 8080
- protocol: TCP
- - metadata:
- name: helloworld-service
- labels:
- app: helloworld
- spec:
- template:
- kind: Service
- metadata:
- name: helloworld-service
- namespace: helloworld
- spec:
- selector:
- app: helloworld
- ports:
- - port: 80
- targetPort: 8080
- type: LoadBalancer
-```
-
-Create the `KubernetesApplication`:
-
-```
-kubectl apply -f helloworld.yaml
-```
-
-Crossplane will immediately attempt to find a compatible `KubernetesTarget` with
-matching labels to the stanza we included on our `KubernetesApplication`:
-
-```
-targetSelector:
- matchLabels:
- cluster: hello-world
-```
-
-Because we only have one `KubernetesTarget` with these labels in the
-`cp-quickstart` namespace, the `KubernetesApplication` will be scheduled to the
-GKE cluster we created earlier. You can view the progress of creating the
-resources on the remote cluster by looking at the `KubernetesApplication` and
-the resulting `KubernetesApplicationResources`:
-
-```
-kubectl -n cp-quickstart get kubernetesapplications
-```
-
-```
-NAME CLUSTER STATUS DESIRED SUBMITTED
-helloworld 92184b85-4db3-48d2-99a2-36b3cf81226e Scheduled 3
-```
-
-```
-kubectl -n cp-quickstart get kubernetesapplicationresources
-```
-
-```
-NAME TEMPLATE-KIND TEMPLATE-NAME CLUSTER STATUS
-helloworld-deployment Deployment helloworld-deployment c1c435a3-8673-46d5-95bb-55cc5040a6fd Submitted
-helloworld-namespace Namespace helloworld c1c435a3-8673-46d5-95bb-55cc5040a6fd Submitted
-helloworld-service Service helloworld-service c1c435a3-8673-46d5-95bb-55cc5040a6fd Submitted
-```
-
-> *Note: each in-line template in a `KubernetesApplication` results in the
-> creation of a corresponding `KubernetesApplicationResource`. Crossplane keeps
-> the resources on the remote cluster in sync with their
-> `KubernetesApplicationResource`, and keeps each respective
-> `KubernetesApplicationResource` in sync with its template on the
-> `KubernetesApplication`.*
-
-When all three resources have been provisioned, the `KubernetesApplication` will
-show a `3` in the `SUBMITTED` column. If you inspect the
-`KubernetesApplication`, you should see the IP address of the `LoadBalancer`
-`Service` in the remote cluster. If you navigate your browser to that address,
-you should be greeted by the hello world application.
-
-```
-kubectl -n cp-quickstart describe kubernetesapplicationresource helloworld-service
-```
-
-```
-Name: helloworld-service
-Namespace: cp-quickstart
-Labels: app=helloworld
-Annotations:
-API Version: workload.crossplane.io/v1alpha1
-Kind: KubernetesApplicationResource
-Metadata:
- Creation Timestamp: 2020-03-23T22:29:16Z
- Finalizers:
- finalizer.kubernetesapplicationresource.workload.crossplane.io
- Generation: 2
- Owner References:
- API Version: workload.crossplane.io/v1alpha1
- Block Owner Deletion: true
- Controller: true
- Kind: KubernetesApplication
- Name: helloworld
- UID: 1f1808ad-2b82-47df-8e8f-40255511c20a
- Resource Version: 31969
- Self Link: /apis/workload.crossplane.io/v1alpha1/namespaces/cp-quickstart/kubernetesapplicationresources/helloworld-service
- UID: 508c07d5-e3c8-4df2-9927-c320448db437
-Spec:
- Target Ref:
- Name: c1c435a3-8673-46d5-95bb-55cc5040a6fd
- Template:
- Kind: Service
- Metadata:
- Name: helloworld-service
- Namespace: helloworld
- Spec:
- Ports:
- Port: 80
- Target Port: 8080
- Selector:
- App: helloworld
- Type: LoadBalancer
-Status:
- Conditioned Status:
- Conditions:
- Last Transition Time: 2020-03-23T22:29:54Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
- Remote:
- Load Balancer:
- Ingress:
- Ip: 34.67.121.186 # the application is running at this IP address
- State: Submitted
-Events:
-```
-
-> *Note: Creating a cluster and scheduling resources to it is a nice workflow,
-> but it is likely that you may want to schedule resources to an existing
-> cluster or one that is not a managed service that Crossplane supports. This is
-> made possible by storing the base64 encoded `kubeconfig` data in a `Secret`,
-> then manually creating a `KubernetesTarget` to point at it. This is an
-> advanced workflow, and additional information can be found in the
-> [guide on manually adding clusters].*
-
-## Clean Up
-
-If you would like to clean up the resources created in this section, run the
-following commands:
-
-```
-kubectl delete -f helloworld.yaml
-kubectl delete -f k8s-cluster.yaml
-```
-
-
-
-[GKE]: https://cloud.google.com/kubernetes-engine
-[EKS]: https://aws.amazon.com/eks/
-[AKS]: https://azure.microsoft.com/en-us/services/kubernetes-service/
-[kubeconfig]: https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/
-[guide on manually adding clusters]: ../guides/manually_adding_clusters.md
diff --git a/docs/v0.10/guides/guides.md b/docs/v0.10/guides/guides.md
deleted file mode 100644
index 5b49903e..00000000
--- a/docs/v0.10/guides/guides.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Guides
-toc: true
-weight: 200
----
-
-# Guides
-
-Because of Crossplane's standardization on the Kubernetes API, it integrates
-well with many other project. Below is a collection of guides and tutorials that
-demonstrate how to use Crossplane with a variety of tools in the GitOps, service
-mesh, and infrastructure provisioning spaces.
-
-- [Connecting AWS managed services to your Argo CD pipeline with open source
- Crossplane]
-- [Using Crossplane to schedule workloads to Kubernetes clusters provisioned by
- Cluster API]
-- [Using managed services in your development workflow with Crossplane and
- Okteto]
-- [Installing Linkerd into remote clusters using Crossplane]
-
-
-
-[Connecting AWS managed services to your Argo CD pipeline with open source Crossplane]: https://aws.amazon.com/blogs/opensource/connecting-aws-managed-services-to-your-argo-cd-pipeline-with-open-source-crossplane/
-[Using Crossplane to schedule workloads to Kubernetes clusters provisioned by Cluster API]: https://github.com/crossplane/tbs/tree/master/episodes/11/assets
-[Using managed services in your development workflow with Crossplane and Okteto]: https://github.com/crossplane/tbs/tree/master/episodes/10/assets
-[Installing Linkerd into remote clusters using Crossplane]: https://github.com/crossplane/tbs/tree/master/episodes/12/assets
diff --git a/docs/v0.10/guides/manually_adding_clusters.md b/docs/v0.10/guides/manually_adding_clusters.md
deleted file mode 100644
index b9c898b8..00000000
--- a/docs/v0.10/guides/manually_adding_clusters.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: Manually Adding Existing Kubernetes Clusters
-toc: true
-weight: 201
-indent: true
----
-
-# Manually Adding Existing Kubernetes Clusters
-
-As discussed in the section on [scheduling applications to remote clusters],
-Crossplane allows you to import existing Kubernetes clusters for scheduling.
-This can be done for any cluster for which you have a `kubeconfig`. Crossplane
-will be given the same permissions to the remote cluster that are provided to
-the user in your `kubeconfig`.
-
-The first step is creating a `Secret` with the base64 encoded data of your
-`kubeconfig`. This can be done with the following command (assumes data is in
-`kubeconfig.yaml` and desired namespace is `cp-infra-ops`):
-
-```
-kubectl -n cp-infra-ops create secret generic myk8scluster --from-literal=kubeconfig=$(base64 kubeconfig.yaml -w 0)
-```
-
-In order to use this cluster as a scheduling target, you must also create a
-`KubernetesTarget` resource that references the `Secret`. Make sure to include
-any labels that you want to schedule your `KubernetesApplication` to:
-
-`myk8starget.yaml`
-
-```
-apiVersion: workload.crossplane.io/v1alpha1
-kind: KubernetesTarget
-metadata:
- name: myk8starget
- namespace: cp-infra-ops
- labels:
- guide: infra-ops
-spec:
- connectionSecretRef:
- name: myk8scluster
-```
-
-```
-kubectl apply -f myk8starget.yaml
-```
-
-*Note: the `Secret` and `KubernetesTarget` must be in the same namespace.*
-
-You can now create a `KubernetesApplication` in the `cp-infra-ops` namespace and
-your remote cluster will be a scheduling option.
-
-
-[scheduling applications to remote clusters]: ../workload.md
diff --git a/docs/v0.10/guides/packaging_an_app.md b/docs/v0.10/guides/packaging_an_app.md
deleted file mode 100644
index 3ae32dd1..00000000
--- a/docs/v0.10/guides/packaging_an_app.md
+++ /dev/null
@@ -1,198 +0,0 @@
----
-title: Packaging an Application
-toc: true
-weight: 202
-indent: true
----
-
-# Packaging an Application
-
-In the quick start guide, we demonstrated how Wordpress can be installed as a
-Crossplane `Application`. Now we want to learn more about how to package any
-application in a similar fashion. The good news is that we can use common
-Kubernetes configuration tools, such as [Helm] and [Kustomize], which you may
-already be familiar with.
-
-## Setting up a Repository
-
-The required components of an application repository are minimal. For example,
-the required components of the [Wordpress application] we deployed in the quick
-start are the following:
-
-```
-├── Dockerfile
-├── .registry
-│ ├── app.yaml
-│ ├── behavior.yaml
-│ ├── icon.svg
-│ └── resources
-│ ├── wordpress.apps.crossplane.io_wordpressinstances.crd.yaml
-│ ├── wordpressinstance.icon.svg
-│ ├── wordpressinstance.resource.yaml
-│ └── wordpressinstance.ui-schema.yaml
-├── helm-chart
-│ ├── Chart.yaml
-│ ├── templates
-│ │ ├── app.yaml
-│ │ ├── cluster.yaml
-│ │ └── database.yaml
-│ └── values.yaml
-```
-
-Let's take a look at each component in-depth.
-
-### Dockerfile
-
-The Dockerfile is only responsible for copying the configuration directory
-(`helm-chart/` in this case) and the `.registry` directory. You can likely use a
-very similar Dockerfile across all of your applications:
-
-```Dockerfile
-FROM alpine:3.7
-WORKDIR /
-COPY helm-chart /helm-chart
-COPY .registry /.registry
-```
-
-### .registry
-
-The `.registry` directory informs Crossplane how to install your application. It
-consists of the following:
-
-**app.yaml** `[required]`
-
-The `app.yaml` file is responsible for defining the metadata for an application,
-such as name, version, and required permissions. The Wordpress `app.yaml` is a
-good reference for available fields:
-
-```yaml
-# Human readable title of application.
-title: Wordpress
-
-overviewShort: Cloud portable Wordpress deployments behind managed Kubernetes and SQL services are demonstrated in this Crossplane Stack.
-
-overview: |-
- This Wordpress application uses a simple controller that uses Crossplane to orchestrate managed SQL services and managed Kubernetes clusters which are then used to run a Wordpress deployment.
- A simple Custom Resource Definition (CRD) is provided allowing for instances of this Crossplane managed Wordpress Application to be provisioned with a few lines of yaml.
- The Sample Wordpress Application is intended for demonstration purposes and should not be used to deploy production instances of Wordpress.
-
-# Markdown description of this entry
-readme: |-
- ### Create wordpresses
- Before wordpresses will provision, the Crossplane control cluster must
- be configured to connect to a provider (e.g. GCP, Azure, AWS).
- Once a provider is configured, starting the process of creating a
- Wordpress Application instance is easy.
-
- cat <.icon.svg`: an image to be displayed for your application CRD
-- `.resource.yaml`: a description of your application CRD
-- `.ui-schema.yaml`: the configurable fields on your CRD that you
- wish to be displayed in a UI
-
-Crossplane will take these files and apply them as [annotations] on the
-installed application. They can then be parsed by a user interface.
-
-### Configuration Directory
-
-The configuration directory contains the actual manifests for deploying your
-application. In the case of Wordpress, this includes a `KubernetesApplication`
-(`helm-chart/templates/app.yaml`), a `KubernetesCluster` claim
-(`helm-chart/templates/cluster.yaml`), and a `MySQLInstance` claim
-(`helm-chart/templates/database.yaml`). The configuration tool for the manifests
-in the directory should match the `engine` field in your
-`.registry/behavior.yaml`. The options for engines at this time are `helm3` and
-`kustomize`. Crossplane will pass values from the `spec` of the application's
-CRD as variables in the manifests. For instance, the `provisionPolicy` field in
-the `spec` of the `WordpressInstance` CRD will be passed to the Helm chart
-defined in the `helm-chart/` directory.
-
-
-
-[Helm]: https://helm.sh/
-[Kustomize]: https://kustomize.io/
-[Wordpress application]: https://github.com/crossplane/app-wordpress
-[CustomResourceDefinition]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[controller-tools]: https://github.com/kubernetes-sigs/controller-tools
-[annotations]: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
diff --git a/docs/v0.10/media/arch.png b/docs/v0.10/media/arch.png
deleted file mode 100644
index 8205e62e..00000000
Binary files a/docs/v0.10/media/arch.png and /dev/null differ
diff --git a/docs/v0.10/media/banner.png b/docs/v0.10/media/banner.png
deleted file mode 100644
index 0a495e1d..00000000
Binary files a/docs/v0.10/media/banner.png and /dev/null differ
diff --git a/docs/v0.10/media/crossplane-overview.png b/docs/v0.10/media/crossplane-overview.png
deleted file mode 100644
index 87c25a89..00000000
Binary files a/docs/v0.10/media/crossplane-overview.png and /dev/null differ
diff --git a/docs/v0.10/media/logo.svg b/docs/v0.10/media/logo.svg
deleted file mode 100644
index 3af90369..00000000
--- a/docs/v0.10/media/logo.svg
+++ /dev/null
@@ -1,310 +0,0 @@
-
-
-
diff --git a/docs/v0.10/reference/faqs.md b/docs/v0.10/reference/faqs.md
deleted file mode 100644
index 3bf38640..00000000
--- a/docs/v0.10/reference/faqs.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: FAQs
-toc: true
-weight: 301
-indent: true
----
-
-# Frequently Asked Questions (FAQs)
-
-### Where did the name Crossplane come from?
-
-Crossplane is the fusing of cross-cloud control plane. We wanted to use a noun
-that refers to the entity responsible for connecting different cloud providers
-and acts as control plane across them. Cross implies “cross-cloud” and “plane”
-brings in “control plane”.
-
-### What's up with popsicle?
-
-We believe in a multi-flavor cloud.
-
-### Why is Upbound open sourcing this project? What are Upbound’s monetization plans?
-
-Upbound’s mission is to create a more open cloud-computing platform, with more
-choice and less lock-in. We believe the Crossplane as an important step towards
-this vision and that it’s going to take a village to solve this problem. We
-believe that multicloud control plane is a new category of open source software,
-and it will ultimately disrupt closed source and proprietary models. Upbound
-aspires to be a commercial provider of a more open cloud-computing platform.
-
-### What kind of governance model will be used for Crossplane?
-
-Crossplane will be an independent project and we plan on making a community
-driven project and not a vendor driven project. It will have an independent
-brand, github organization, and an open governance model. It will not be tied to
-single organization or individual.
-
-### Will Crossplane be donated to an open source foundation?
-
-We don’t know yet. We are open to doing so but we’d like to revisit this after
-the project has gotten some end-user community traction.
-
-### Does using multicloud mean you will use the lowest common denominator across clouds?
-
-Not necessarily. There are numerous best of breed cloud offerings that run on
-multiple clouds. For example, CockroachDB and ElasticSearch are world class
-implementations of platform software and run well on cloud providers. They
-compete with managed services offered by a cloud provider. We believe that by
-having an open control plane for them to integrate with, and providing a common
-API, CLI and UI for all of these services, that more of these offerings will
-exist and get first-class experience in the cloud.
-
-### How are resources and claims related to PersistentVolumes in Kubernetes?
-
-We modeled resource claims and classes after PersistentVolumes and
-PersistentVolumeClaims in Kubernetes. We believe many of the lessons learned
-from managing volumes in Kubernetes apply to managing resources within cloud
-providers. One notable exception is that we avoided creating a plugin model
-within Crossplane.
-
-### How is workload scheduling related to pod scheduling in Kubernetes?
-
-We modeled workload scheduling after the Pod scheduler in Kubernetes. We believe
-many of the lessons learned from Pod scheduling apply to scheduling workloads
-across cloud providers.
-
-### Can I use Crossplane to consistently provision and manage multiple Kubernetes clusters?
-
-Crossplane includes a portable API for Kubernetes clusters that will include
-common configuration including node pools, auto-scalers, taints, admission
-controllers, etc. These will be applied to the specific implementations within
-the cloud providers like EKS, GKE and AKS. We see the Kubernetes Cluster API to
-be something that will be used by administrators and not developers.
-
-### Other attempts at building a higher level API on-top of a multitude of inconsistent lower level APIs have not been successful, will Crossplane not have the same issues?
-
-We agree that building a consistent higher level API on top of multitudes of
-inconsistent lower level API's is well known to be fraught with peril (e.g.
-dumbing down to lowest common denominator, or resulting in so loosely defined an
-API as to be impossible to practically develop real portable applications on top
-of it).
-
-Crossplane follows a different approach here. The portable API extracts the
-pieces that are common across all implementations, and from the perspective of
-the workload. The rest of the implementation details are captured in full
-fidelity by the admin in resource classes. The combination of the two is what
-results in full configuration that can be deployed. We believe this to be a
-reasonable tradeoff that avoids the dumbing down to lowest common denominator
-problem, while still enabling portability.
diff --git a/docs/v0.10/reference/learn_more.md b/docs/v0.10/reference/learn_more.md
deleted file mode 100644
index 831e5740..00000000
--- a/docs/v0.10/reference/learn_more.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: Learn More
-toc: true
-weight: 302
-indent: true
----
-
-# Learn More
-
-If you have any questions, please drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us]!
-
-***Learn more about using Crossplane***
- - [GitLab deploys into multiple clouds from kubectl using Crossplane](https://about.gitlab.com/2019/05/20/gitlab-first-deployed-kubernetes-api-to-multiple-clouds/)
- - [CNCF Talks & Community Presentations](https://www.youtube.com/playlist?list=PL510POnNVaaZJj9OG6PbgsZvgYbhwJRyE)
- - [Software Engineering Daily - Intro Podcast](https://softwareengineeringdaily.com/2019/01/02/crossplane-multicloud-control-plane-with-bassam-tabbara/)
- - [Crossplane Architecture](https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit?usp=sharing)
- - [Latest Design Docs](https://github.com/crossplane/crossplane/tree/master/design)
- - [Roadmap](https://github.com/crossplane/crossplane/blob/master/ROADMAP.md)
-
-***Writing Kubernetes controllers to extend Crossplane***
- - [Keep the Space Shuttle Flying: Writing Robust Operators](https://www.youtube.com/watch?v=uf97lOApOv8)
- - [Best practices for building Kubernetes Operators](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)
- - [Programming Kubernetes Book](https://www.oreilly.com/library/view/programming-kubernetes/9781492047094/)
- - [Crossplane Reconciler Patterns](https://github.com/crossplane/crossplane/blob/master/design/design-doc-reconciler-patterns.md)
- - [Contributor Guide](https://github.com/crossplane/crossplane/blob/master/CONTRIBUTING.md)
-
-***Join the growing Crossplane community and get involved!***
-- Join our [Community Slack](https://slack.crossplane.io/)!
-- Submit an issue on [GitHub](https://github.com/crossplane/crossplane)
-- Attend our bi-weekly [Community Meeting](https://github.com/crossplane/crossplane#community-meeting)
-- Join our bi-weekly live stream: [The Binding Status](https://github.com/crossplane/tbs)
-- Subscribe to our [YouTube Channel](https://www.youtube.com/channel/UC19FgzMBMqBro361HbE46Fw)
-- Drop us a note on Twitter: [@crossplane_io](https://twitter.com/crossplane_io)
-- Email us: [info@crossplane.io](mailto:info@crossplane.io)
-
-
-
-[join-crossplane-slack]: https://slack.crossplane.io
-[contact-us]: https://github.com/crossplane/crossplane#contact
diff --git a/docs/v0.10/reference/overview.md b/docs/v0.10/reference/overview.md
deleted file mode 100644
index fd88b62f..00000000
--- a/docs/v0.10/reference/overview.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Reference
-toc: true
-weight: 300
----
-
-# Overview
-
-The reference documentation includes answers to frequently asked questions, information about similar projects, and links to resources that can help you learn more about Crossplane and Kubernetes. If you have additional information that you think would be valuable for the community, please feel free to [open a pull request]() and add it.
-
-1. [Troubleshoot]
-2. [Frequently Asked Questions]
-3. [Learn More]
-4. [Related Projects]
-
-
-
-[Troubleshoot]: troubleshoot.md
-[Frequently Asked Questions]: faqs.md
-[Learn More]: learn_more.md
-[Related Projects]: related_projects.md
diff --git a/docs/v0.10/reference/related_projects.md b/docs/v0.10/reference/related_projects.md
deleted file mode 100644
index 57dacf44..00000000
--- a/docs/v0.10/reference/related_projects.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: Related Projects
-toc: true
-weight: 304
-indent: true
----
-
-# Related Projects
-
-While there are many projects that address similar issues, none of them
-encapsulate the full use case that Crossplane addresses. This list is not
-exhaustive and is not meant to provide a deep analysis of the following
-projects, but instead to motivate why Crossplane was created.
-
-## Open Service Broker and Service Catalog
-
-The [Open Service Broker] and the [Kubernetes Service Catalog] are able to
-dynamically provision managed services in multiple cloud providers from
-Kubernetes. As a result it shares similar goals with Crossplane. However,
-service broker is not designed for workload portability, does not have a good
-separation of concern, and does not offer any integration with workload and
-resource scheduling. Service brokers can not span multiple cloud providers at
-once.
-
-## Kubernetes Federation
-
-The [federation-v2] project offers a single control plane that can span multiple
-Kubernetes clusters. It’s being incubated in SIG-multicluster. Crossplane shares
-some of the goals of managing multiple Kubernetes clusters and also the core
-principles of creating a higher level control plane, scheduler and controllers
-that span clusters. While the federation-v2 project is scoped to just Kubernetes
-clusters, Crossplane supports non-container workloads, and orchestrating
-resources that run as managed services including databases, message queues,
-buckets, and others. The federation effort focuses on defining Kubernetes
-objects that can be templatized, and propagated to other Kubernetes clusters.
-Crossplane focuses on defining portable workload abstractions across cloud
-providers and offerings. We have considered taking a dependency on the
-federation-v2 work within Crossplane, although it’s not clear at this point if
-this would accelerate the Crossplane effort.
-
-## AWS Service Operator
-
-The [AWS Service Operator] is a recent project that implements a set of
-Kubernetes controllers that are able to provision managed services in AWS. It
-defines a set of CRDs for managed services like DynamoDB, and controllers that
-can provision them via AWS CloudFormation. It is similar to Crossplane in that
-it can provision managed services in AWS. Crossplane goes a lot further by
-offering workload portability across cloud multiple cloud providers, separation
-of concern, and a scheduler for workload and resources.
-
-## AWS CloudFormation, GCP Deployment Manager, and Others
-
-These products offer a declarative model for deploying and provisioning
-infrastructure in each of the respective cloud providers. They only work for one
-cloud provider and do not solve the problem of workload portability. These
-products are generally closed source, and offer little or no extensibility
-points. We have considered using some of these products as a way to implement
-resource controllers in Crossplane.
-
-## Terraform
-
-[Terraform] is a popular tool for provisioning infrastructure across cloud
-providers. It offers a declarative configuration language with support for
-templating, composability, referential integrity and dependency management.
-Terraform can dynamically provision infrastructure and perform changes when the
-tool is run by a human. Unlike Crossplane, Terraform does not support workload
-portability across cloud providers, and does not have any active controllers
-that can react to failures, or make changes to running infrastructure without
-human intervention. Terraform attempts to solve multicloud at the tool level,
-while Crossplane is at the API and control plane level. Terraform is open source
-under a MPL license, and follows an open core business model, with a number of
-its features closed source. We are evaluating whether we can use Terraform to
-accelerate the development of resource controllers in Crossplane.
-
-## Pulumi
-
-[Pulumi] is a product that is based on terraform and uses most of its providers.
-Instead of using a configuration language, Pulumi uses popular programming
-languages like Typescript to capture the configuration. At runtime, Pulumi
-generates a DAG of resources just like terraform and applies it to cloud
-providers. Pulumi has an early model for workload portability that is
-implemented using language abstractions. Unlike Crossplane, it does not have any
-active controllers that can react to failures, or make changes to running
-infrastructure without human intervention, nor does it support workload
-scheduling. Pulumi attempts to solve multicloud scenarios at the language level,
-while Crossplane is at the API and control plane level. Pulumi is open source
-under a APL2 license but a number of features require using their SaaS offering.
-
-
-
-[Open Service Broker]: https://www.openservicebrokerapi.org/
-[Kubernetes Service Catalog]: https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/
-[federation-v2]: https://github.com/kubernetes-sigs/federation-v2
-[AWS Service Operator]: https://github.com/awslabs/aws-service-operator
-[Terraform]: https://www.terraform.io/
-[Pulumi]: https://www.pulumi.com/
diff --git a/docs/v0.10/reference/troubleshoot.md b/docs/v0.10/reference/troubleshoot.md
deleted file mode 100644
index 44857359..00000000
--- a/docs/v0.10/reference/troubleshoot.md
+++ /dev/null
@@ -1,262 +0,0 @@
----
-title: Troubleshoot
-toc: true
-weight: 303
-indent: true
----
-
-# Troubleshooting
-
-* [Using the trace command]
-* [Resource Status and Conditions]
-* [Crossplane Logs]
-* [Pausing Crossplane]
-* [Deleting a Resource Hangs]
-* [Host-Aware Resource Debugging]
-
-## Using the trace command
-
-The [Crossplane CLI] trace command provides a holistic view for a particular
-object and related ones to ease debugging and troubleshooting process. It finds
-the relevant Crossplane resources for a given one and provides detailed
-information as well as an overview indicating what could be wrong.
-
-Usage:
-```
-kubectl crossplane trace TYPE[.GROUP] NAME [-n| --namespace NAMESPACE] [--kubeconfig KUBECONFIG] [-o| --outputFormat dot]
-```
-
-Examples:
-```
-# Trace a KubernetesApplication
-kubectl crossplane trace KubernetesApplication wordpress-app-83f04457-0b1b-4532-9691-f55cf6c0da6e -n app-project1-dev
-
-# Trace a MySQLInstance
-kubectl crossplane trace MySQLInstance wordpress-mysql-83f04457-0b1b-4532-9691-f55cf6c0da6e -n app-project1-dev
-```
-
-For more information, see [the trace command documentation].
-
-## Resource Status and Conditions
-
-Most Crossplane resources have a `status` section that can represent the current
-state of that particular resource. Running `kubectl describe` against a
-Crossplane resource will frequently give insightful information about its
-condition. For example, to determine the status of a MySQLInstance resource
-claim, run:
-
-```shell
-kubectl -n app-project1-dev describe mysqlinstance mysql-claim
-```
-
-This should produce output that includes:
-
-```console
-Status:
- Conditions:
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Managed claim is waiting for managed resource to become bindable
- Status: False
- Type: Ready
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Successfully reconciled managed resource
- Status: True
- Type: Synced
-```
-
-Most Crossplane resources set exactly two condition types; `Ready` and `Synced`.
-`Ready` represents the availability of the resource itself - whether it is
-creating, deleting, available, unavailable, binding, etc. `Synced` represents
-the success of the most recent attempt to 'reconcile' the _desired_ state of the
-resource with its _actual_ state. The `Synced` condition is the first place you
-should look when a Crossplane resource is not behaving as expected.
-
-## Crossplane Logs
-
-The next place to look to get more information or investigate a failure would be
-in the Crossplane pod logs, which should be running in the `crossplane-system`
-namespace. To get the current Crossplane logs, run the following:
-
-```shell
-kubectl -n crossplane-system logs -lapp=crossplane
-```
-
-Remember that much of Crossplane's functionality is provided by Stacks. You can
-use `kubectl logs` to view Stack logs too, though Stacks may not run in the
-`crossplane-system` namespace.
-
-## Pausing Crossplane
-
-Sometimes, for example when you encounter a bug. it can be useful to pause
-Crossplane if you want to stop it from actively attempting to manage your
-resources. To pause Crossplane without deleting all of its resources, run the
-following command to simply scale down its deployment:
-
-```bash
-kubectl -n crossplane-system scale --replicas=0 deployment/crossplane
-```
-
-Once you have been able to rectify the problem or smooth things out, you can
-unpause Crossplane simply by scaling its deployment back up:
-
-```bash
-kubectl -n crossplane-system scale --replicas=1 deployment/crossplane
-```
-
-Remember that much of Crossplane's functionality is provided by Stacks. You can
-use `kubectl scale` to pause Stack pods too, though Stacks may not run in the
-`crossplane-system` namespace.
-
-## Deleting a Resource Hangs
-
-The resources that Crossplane manages will automatically be cleaned up so as not
-to leave anything running behind. This is accomplished by using finalizers, but
-in certain scenarios the finalizer can prevent the Kubernetes object from
-getting deleted.
-
-To deal with this, we essentially want to patch the object to remove its
-finalizer, which will then allow it to be deleted completely. Note that this
-won't necessarily delete the external resource that Crossplane was managing, so
-you will want to go to your cloud provider's console and look there for any
-lingering resources to clean up.
-
-In general, a finalizer can be removed from an object with this command:
-
-```console
-kubectl patch -p '{"metadata":{"finalizers": []}}' --type=merge
-```
-
-For example, for a Workload object (`workloads.compute.crossplane.io`) named
-`test-workload`, you can remove its finalizer with:
-
-```console
-kubectl patch workloads.compute.crossplane.io test-workload -p '{"metadata":{"finalizers": []}}' --type=merge
-```
-
-## Host-Aware Resource Debugging
-
-Stack resources (including the Stack, service accounts, deployments, and jobs)
-are usually easy to identify by name. These resource names are based on the name
-used in the StackInstall or Stack resource.
-
-### Resource Location
-
-In a host-aware configuration, these resources may be divided between the host
-and the tenant.
-
-The host, which runs the Stack controller, does not need (or get) the CRDs used
-by the Stack controller. The Stack controller connects to the tenant Kubernetes
-API to watch the owned types of the Stack (which is why the CRDs are only
-installed on the Tenant).
-
-Kind | Name | Place
----- | ----- | ------
-pod | crossplane | Host (ns: tenantFoo-system)
-pod | stack-manager | Host (ns: tenantFoo-system)
-job | (stack installjob) | Host (ns: tenantFoo-controllers)
-pod | (stack controller) | Host (ns: tenantFoo-controllers)
-
-Kind | Name | Place
----- | ----- | ------
-crd | Stack, SI, CSI | Tenant
-Stack | wordpress | Tenant
-StackInstall | wordpress | Tenant
-crd | KubernetesEngine, MysqlInstance, ... | Tenant
-crd | GKEInstance, CloudSQLInstance, ... | Tenant
-(rbac) | (stack controller) | Tenant
-(rbac) | (workspace owner, crossplane-admin) | Tenant
-(rbac) | (stack:namespace:1.2.3:admin) | Tenant
-crd | WordpressInstance | Tenant
-WordpressInstance | wp-instance | Tenant
-KubernetesApplication | wp-instance | Tenant
-
-Kind | Name | Place
----- | ----- | ------
-pod | wp-instance (from KubernetesAplication) | New Cluster
-
-### Name Truncation
-
-In some cases, the full name of a Stack resource, which could be up to 253
-characters long, can not be represented in the created resources. For example,
-jobs and deployment names may not exceed 63 characters because these names are
-turned into resource label values which impose a 63 character limit. Stack
-created resources whose names would otherwise not be permitted in the Kubernetes
-API will be truncated with a unique suffix.
-
-When running the Stack Manager in host-aware mode, tenant stack resources
-created in the host controller namespace generally reuse the Stack names:
-"{tenant namespace}.{tenant name}". In order to avoid the name length
-restrictions, these resources may be truncated at either or both of the
-namespace segment or over the entire name. In these cases resource labels,
-owner references, and annotations should be consulted to identify the
-responsible Stack.
-
-* [Relationship Labels]
-* [Owner References]
-* Annotations: `tenant.crossplane.io/{singular}-name` and
- `tenant.crossplane.io/{singular}-namespace` (_singular_ may be `stackinstall`,
- `clusterstackinstall` or `stack`)
-
-#### Example
-
-Long resource names may be present on the tenant.
-
-```console
-$ name=stack-with-a-really-long-resource-name-so-long-that-it-will-be-truncated
-$ ns=this-is-just-a-really-long-namespace-name-at-the-character-max
-$ kubectl create ns $ns
-$ kubectl crossplane stack install --namespace $ns crossplane/sample-stack-wordpress:0.1.1 $name
-```
-
-When used as host resource names, the stack namespace and stack are concatenated
- to form host names, as well as labels. These resource names and label values
- must be truncated to fit the 63 character limit on label values.
-
-```console
-$ kubectl --context=crossplane-host -n tenant-controllers get job -o yaml
-apiVersion: v1
-items:
-- apiVersion: batch/v1
- kind: Job
- metadata:
- annotations:
- tenant.crossplane.io/stackinstall-name: stack-with-a-really-long-resource-name-so-long-that-it-will-be-truncated
- tenant.crossplane.io/stackinstall-namespace: this-is-just-a-really-long-namespace-name-at-the-character-max
- creationTimestamp: "2020-03-20T17:06:25Z"
- labels:
- core.crossplane.io/parent-group: stacks.crossplane.io
- core.crossplane.io/parent-kind: StackInstall
- core.crossplane.io/parent-name: stack-with-a-really-long-resource-name-so-long-that-it-wi-alqdw
- core.crossplane.io/parent-namespace: this-is-just-a-really-long-namespace-name-at-the-character-max
- core.crossplane.io/parent-uid: 596705e4-a28e-47c9-a907-d2732f07a85e
- core.crossplane.io/parent-version: v1alpha1
- name: this-is-just-a-really-long-namespace-name-at-the-characte-egoav
- namespace: tenant-controllers
- spec:
- backoffLimit: 0
- completions: 1
- parallelism: 1
- selector:
- matchLabels:
- controller-uid: 8f290bf2-8c91-494a-a76b-27c2ccb9e0a8
- template:
- metadata:
- creationTimestamp: null
- labels:
- controller-uid: 8f290bf2-8c91-494a-a76b-27c2ccb9e0a8
- job-name: this-is-just-a-really-long-namespace-name-at-the-characte-egoav
- ...
-```
-
-
-
-[Using the trace command]: #using-the-trace-command
-[Resource Status and Conditions]: #resource-status-and-conditions
-[Crossplane Logs]: #crossplane-logs
-[Pausing Crossplane]: #pausing-crossplane
-[Deleting a Resource Hangs]: #deleting-a-resource-hangs
-[Host-Aware Resource Debugging]: #host-aware-resource-debugging
-[Crossplane CLI]: https://github.com/crossplane/crossplane-cli
-[the trace command documentation]: https://github.com/crossplane/crossplane-cli/tree/master/docs/trace-command.md
-[Relationship Labels]: https://github.com/crossplane/crossplane/blob/master/design/one-pager-stack-relationship-labels.md
-[Owner References]: https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents
diff --git a/docs/v0.10/release/release-process.md b/docs/v0.10/release/release-process.md
deleted file mode 100644
index 215a59ea..00000000
--- a/docs/v0.10/release/release-process.md
+++ /dev/null
@@ -1,485 +0,0 @@
-# Release Process
-
-This document is meant to be a complete end-to-end guide for how to release new
-versions of software for Crossplane and its related projects.
-
-## tl;dr Process Overview
-
-All the details are available in the sections below, but we'll start this guide
-with a very high level sequential overview for how to run the release process.
-
-1. **feature freeze**: Merge all completed features into master branches of all
- repos to begin "feature freeze" period
-1. **API docs/user guides**: Regenerate API docs and update all user guides with
- current content for scenarios included in the release
-1. **release crossplane-runtime**: Tag and release a new version of
- crossplane-runtime using the GitHub UI.
-1. **pin crossplane dependencies**: Update the go modules of core crossplane in
- master to depend on the newly released version of crossplane-runtime.
-1. **pre-release tag crossplane**: Run tag pipeline to tag the start of
- pre-releases in master in the crossplane repo
-1. **branch crossplane**: Create a new release branch using the GitHub UI for
- the crossplane repo
-1. **crossplane release branch prep**: In Crossplane's release branch, update
- all examples, docs, and integration tests to update references and versions,
- including the yet to be released versions of providers and stacks.
-1. **tag**: Run the tag pipeline to tag Crossplane's release branch with an
- official semver
-1. **release providers**: Run the release process for each **provider** that we
- maintain
- 1. **pin dependencies**: Update the go modules of each provider repo to
- depend on the new version of crossplane and crossplane-runtime.
- 1. **pre-release tag**: Run tag pipeline to tag the start of pre-releases in
- **master** of each provider repo
- 1. **branch**: Create a new release branch using the GitHub UI for the
- provider repo
- 1. **release branch prep**: In the release branch, update all examples,
- docs, and integration tests to update references and versions
- 1. **test** Test builds from the release branch, fix any critical bugs that
- are found
- 1. **tag**: Run the tag pipeline to tag the release branch with an official
- semver
- 1. **build/publish**: Run build pipeline to publish build with official
- semver
-1. **release template stacks**: Run the release process for each **template
- stack** that we maintain. Note that the process for template stacks is
- slightly different from the stack release process.
- 1. **test** Test builds from the release branch (typically `master`), fix
- any critical bugs that are found
- 1. **version**: Update all version information in the docs, as appropriate
- 1. **tag**: Run the tag pipeline to tag the release branch with an official
- semver
- 1. **build/publish**: Run the publish pipeline to publish build with
- official semver
-1. **build/publish**: Run build pipeline to publish Crossplane build from
- release branch with official semver
-1. **verify**: Verify all artifacts have been published successfully, perform
- sanity testing
-1. **promote**: Run promote pipelines on all repos to promote releases to
- desired channel(s)
-1. **release notes**: Publish well authored and complete release notes on GitHub
-1. **announce**: Announce the release on Twitter, Slack, etc.
-
-## Detailed Process
-
-This section will walk through the release process in more fine grained and
-prescriptive detail.
-
-### Scope
-
-This document will cover the release process for all of the repositories that
-the Crossplane team maintains and publishes regular versioned artifacts from.
-This set of repositories covers both core Crossplane and the set of Providers,
-Stacks, and Apps that Crossplane currently maintains:
-
-* [`crossplane`](https://github.com/crossplane/crossplane)
-* [`provider-gcp`](https://github.com/crossplane/provider-gcp)
-* [`provider-aws`](https://github.com/crossplane/provider-aws)
-* [`provider-azure`](https://github.com/crossplane/provider-azure)
-* [`provider-rook`](https://github.com/crossplane/provider-rook)
-* [`stack-minimal-gcp`](https://github.com/crossplane/stack-minimal-gcp)
-* [`stack-minimal-aws`](https://github.com/crossplane/stack-minimal-aws)
-* [`stack-minimal-azure`](https://github.com/crossplane/stack-minimal-azure)
-* [`app-wordpress`](https://github.com/crossplane/app-wordpress)
-
-The release process for Providers is almost identical to that of core Crossplane
-because they use the same [shared build
-logic](https://github.com/upbound/build/). The steps in this guide will apply
-to all repositories listed above unless otherwise mentioned.
-
-### Feature Freeze
-
-Feature freeze should be performed on all repos. In order to start the feature
-freeze period, the following conditions should be met:
-
-* All expected features should be
- ["complete"](https://github.com/crossplane/crossplane/blob/master/design/one-pager-definition-of-done.md)
- and merged into master. This includes user guides, examples, API documentation
- via [crossdocs](https://github.com/negz/crossdocs/), and test updates.
-* All issues in the
- [milestone](https://github.com/crossplane/crossplane/milestones) should be
- closed
-* Sanity testing has been performed on `master`
-
-After these conditions are met, the feature freeze begins by creating the RC tag
-and the release branch.
-
-### Pin Dependencies
-
-It is a best practice to release Crossplane projects with "pinned" dependencies
-to specific versions of other upstream Crossplane projects. For example, after
-crossplane-runtime has been released, we want to update the main Crossplane repo
-to use that specific released version.
-
-To update a dependency to a specific version, simply edit the `go.mod` file to
-point to the desired version, then run `go mod tidy`.
-
-### Pre-release Tag
-
-The next step is to create the pre-release tag for the `HEAD` commit in
-`master`. This tag serves as an indication of when the release was branched
-from master and is also important for generating future versions of `master`
-builds since that [versioning
-process](https://github.com/upbound/build/blob/master/makelib/common.mk#L182-L196)
-is based on `git describe --tags`.
-
-> **NOTE:** The `tag` pipeline does not yet support additional (pre-release)
-tags in the version number, such as `v0.5.0-rc`.
-[#330](https://github.com/crossplane/crossplane/issues/330) will be resolved
-when this functionality is available. In the meantime, **manually tagging and
-pushing to the repo is required**. Ignore the steps below about running the
-pipeline because the pipeline won't work.
-
-To accomplish this, run the `tag` pipeline for each repo on the `master` branch.
-You will be prompted to enter the `version` for the tag and the `commit` hash to
-tag. It's possible to leave the `commit` field blank to default to tagging
-`HEAD`.
-
-Since this tag will essentially be the start of pre-releases working towards the
-**next** version, the `version` should be the **next** release number, plus a
-trailing tag to indicate it is a pre-release. The current convention is to use
-`*-rc`. For example, when we are releasing the `v0.9.0` release and we are
-ready for master to start working towards the **next** release of `v0.10.0`, we
-would make the tag `v0.10.0-rc`
-
-After the tag pipeline has succeeded, verify in the [GitHub
-UI](https://github.com/crossplane/crossplane/tags) that the tag was successfully
-applied to the correct commit.
-
-### Create Release Branch
-
-Creating the release branch can be done within the [GitHub
-UI](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-and-deleting-branches-within-your-repository).
-Basically, you just use the branch selector drop down and type in the name of
-the new release branch, e.g. `release-0.5`. Release branch names always follow
-the convention of `release-[minor-semver]`.
-
-If this is the first ever release branch being created in a repo (uncommon), you
-should also set up branch protection rules for the `release-*` pattern. You can
-find existing examples in the [Crossplane repo
-settings](https://github.com/crossplane/crossplane/settings/branches).
-
-At this point, the `HEAD` commit in the release branch will be our release
-candidate. The build pipeline will automatically be started due to the create
-branch event, so we can start to perform testing on this build. Note that it
-should be the exact same as what is currently in `master` since they are using
-the same commit and have the same tag. Also note that this is not the official
-release build since we have not made the official release tag yet (e.g.
-`v0.5.0`).
-
-The `master` branch can now be opened for new features since we have a safe
-release branch to continue bug fixes and improvements for the release itself.
-Essentially, `master` is free to now diverge from the release branch.
-
-### Release Branch Prep
-
-In the core Crossplane repository, we need to update the release branch docs and
-examples to point to the new versions that we will be releasing soon.
-
-* Documentation, such as [Installation
- instructions](https://github.com/crossplane/crossplane/blob/release-0.9/docs/install.md#installing-infrastructure-providers),
- and
- [Stack](https://github.com/crossplane/crossplane/blob/release-0.9/docs/stack.md)
- and
- [App](https://github.com/crossplane/crossplane/blob/release-0.9/docs/app.md)
- guides.
- * searching for `:master` will help a lot here
-* Examples, such as [`StackInstall` yaml
- files](https://github.com/crossplane/crossplane/tree/release-0.9/cluster/examples/provider)
-* [Helm chart
- defaults](https://github.com/crossplane/crossplane/blob/release-0.9/cluster/charts/crossplane/values.yaml.tmpl),
- ensure all `values.yaml.tmpl` files are updated.
- * provider versions
- * `templating-controller` version (if a new version is available and ready)
-
-#### Bug Fixes in Release Branch
-
-During our testing of the release candidate, we may find issues or bugs that we
-triage and decide we want to fix before the release goes out. In order to fix a
-bug in the release branch, the following process is recommended:
-
-1. Make the bug fix into `master` first through the normal PR process
- 1. If the applicable code has already been removed from `master` then simply
- fix the bug directly in the release branch by opening a PR directly
- against the release branch
-1. Backport the fix by performing a cherry-pick of the fix's commit hash
- (**not** the merge commit) from `master` into the release branch. For
- example, to backport a fix from master to `v0.5.0`, something like the
- following should be used:
-
- ```console
- git fetch --all
- git checkout -b release-0.5 upstream/release-0.5
- git cherry-pick -x
- ```
-
-1. Open a PR with the cherry-pick commit targeting the release-branch
-
-After all bugs have been fixed and backported to the release branch, we can move
-on to tagging the final release commit.
-
-### Tag Core Crossplane
-
-Similar to running the `tag` pipelines for each stack, now it's time to run the
-[`tag`
-pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fcrossplane%2Fcrossplane-tag/branches)
-for core Crossplane. In fact, the [instructions](#stack-tag-pipeline) are
-exactly the same:
-
-Run the tag pipeline by clicking the Run button in the Jenkins UI in the correct
-release branch's row. You will be prompted for the version you are tagging,
-e.g., `v0.5.0` as well as the commit hash. The hash is optional and if you leave
-it blank it will default to `HEAD` of the branch, which is what you want.
-
-> **Note:** The first time you run a pipeline on a new branch, you won't get
-> prompted for the values to input. The build will quickly fail and then you can
-> run (not replay) it a second time to be prompted. This is a Jenkins bug that
-> is tracked by [#41929](https://issues.jenkins-ci.org/browse/JENKINS-41929) and
-> has been open for almost 3 years, so don't hold your breath.
-
-### Draft Release Notes
-
-We're getting close to starting the official release, so you should take this
-opportunity to draft up the release notes. You can create a [new release draft
-here](https://github.com/crossplane/crossplane/releases/new). Make sure you
-select "This is a pre-release" and hit "Save draft" when you are ready to share
-and collect feedback. Do **not** hit "Publish release" yet.
-
-You can see and follow the template and structure from [previous
-releases](https://github.com/crossplane/crossplane/releases).
-
-### Provider Release Process
-
-This section will walk through how to release the Providers and does not
-directly apply to core Crossplane.
-
-#### Pin Provider Dependencies
-
-Similar to core crossplane, each provider should have its crossplane related
-dependencies pinned to the versions that we are releasing. In the **master**
-branch of each provider repo, update the `crossplane` and `crossplane-runtime`
-dependencies to the versions we are releasing.
-
-Simply edit `go.mod` with the new versions, then run `go mod tidy`.
-
-The providers also depend on `crossplane-tools`, but that currently does not
-have official releases, so in practice should be using the latest from master.
-
-#### Provider Pre-release tag
-
-Follow the same steps that we did for core crossplane to tag the **master**
-branch of each provider repo with a pre-release tag for the **next** version.
-
-These steps can be found in the [pre-release tag section](#pre-release-tag).
-
-#### Create Provider Release Branches
-
-Now create a release branch for each of the provider repos using the GitHub UI.
-The steps are the same as what we did to [create the release
-branch](#create-release-branch) for core crossplane.
-
-#### Provider Release Branch Prep
-
-In the **release branch** for each provider, you should update the version tags
-and metadata in:
-
-* `integration_tests.sh` - `STACK_IMAGE`
-* `ClusterStackInstall` sample and example yaml files
-* `*.resource.yaml` - docs links in markdown
- * Not all of these `*.resource.yaml` files have links that need to be updated,
- they are infrequent and inconsistent
-
-Searching for `:master` will be a big help here.
-
-#### Provider Tag, Build, and Publish
-
-Now that the Providers are all tested and their version metadata has been
-updated, it's time to tag the release branch with the official version tag. You
-can do this by running the `tag` pipeline on the release branch of each
-Provider:
-
-* [`provider-gcp` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-gcp-pipelines%2Fprovider-gcp-tag/branches)
-* [`provider-aws` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-aws-pipelines%2Fprovider-aws-tag/branches/)
-* [`provider-azure` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-azure-pipelines%2Fprovider-azure-tag/branches/)
-* [`provider-rook` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-rook-pipelines%2Fprovider-rook-tag/branches/)
-
-* Run the `tag` pipeline on the release branch
-* Enter the version and commit hash (leave blank for `HEAD`)
-* The first time you run on a new release branch, you won't be prompted and the
- build will fail, just run (not replay) a second time
-
-After the tag pipeline has been run and the release branch has been tagged, you
-can run the normal build pipeline on the release branch. This will kick off the
-official release build and upon success, all release artifacts will be
-officially published.
-
-After the release build succeeds, verify that the correctly versioned Provider
-images have been pushed to Docker Hub.
-
-### Template Stack Release Process
-
-The Template Stacks we maintain are slightly different from the controller-based
-stacks that we maintain. Their processes are similar but a little simpler. This
-section will walk through how to release the Template Stacks themselves, and
-does not directly apply to core Crossplane.
-
-For Template Stacks, we do not use release branches unless we need to make a
-patch release. In the future we may need a more robust branching strategy, but
-for now we are not using branches because it is simpler.
-
-Note that Template Stacks **do not** require any code changes to update their
-version. A slight exception to this is for their `behavior.yaml` files, which
-should have the `controllerImage` field updated if a new version of the
-`templating-controller` is available and ready.
-
-### Template Stack Tag And Publish Pipeline
-
-Here is the list of all template stacks:
-
-* [`stack-minimal-gcp`](https://github.com/crossplane/stack-minimal-gcp)
-* [`stack-minimal-aws`](https://github.com/crossplane/stack-minimal-aws)
-* [`stack-minimal-azure`](https://github.com/crossplane/stack-minimal-azure)
-* [`app-wordpress`](https://github.com/crossplane/app-wordpress)
-
-Each one should be released as part of a complete release, using the
-instructions below. To read even more about the template stack release process,
-see [the release section of this
-document](https://github.com/crossplane/cicd/blob/master/docs/pipelines.md#how-do-i-cut-a-release)
-
-Note that there's also the
-[`templating-controller`](https://github.com/crossplane/templating-controller),
-which supports template stacks. It is possible that it **may** need to be
-released as well, but typically is released independently from Crossplane.
-
-#### Tag the Template Stack
-
-Once a template stack is tested and ready for cutting a semver release, we will
-want to tag the repository with the new release version. In most cases, to get
-the version, take a look at the most recent tag in the repo, and increment the
-minor version. For example, if the most recent tag was `v0.2.0`, the new tag
-should be `v0.3.0`.
-
-Run the template stack's tag job on Jenkins, against the `master` branch. Enter
-in the new tag to use. If the current release candidate is not the head of
-`master`, enter in the commit to tag.
-
-You can find the tag pipeline for the individual stack by going to the
-[crossplane org in Jenkins](https://jenkinsci.upbound.io/job/crossplane/),
-finding the folder with the same name as the template stack, and then going to
-the `tag` job group. Then going to the `master` branch job under the group. For
-example, here is [a link to the stack-minimal-gcp tag job for
-master](https://jenkinsci.upbound.io/job/crossplane/job/stack-minimal-gcp/job/tag/job/master/).
-
-> **Note:** The first time you run a pipeline on a new branch, you won't get
-> prompted for the values to input and the build will fail. See details in the
-> [tagging core crossplane section](#tag-core-crossplane).
-
-#### Publish the Template Stack
-
-After the tag pipeline has been run and the repository has been tagged, you can
-run the `publish` job for the template stack. For example, here's a [link to the
-stack-minimal-gcp publish
-job](https://jenkinsci.upbound.io/job/crossplane/job/stack-minimal-gcp/job/publish/job/master/).
-This will kick off the official release build and upon success, all release
-artifacts will be officially published. This should also be run from the
-`master` branch in most cases. Or, if a release branch was used, from the
-release branch. The tag parameter should be used, and the tag for the current
-release should be used. For example, if the new tag we created was `v0.3.0`, we
-would want to provide `v0.3.0` for the `publish` job.
-
-#### Verify the Template Stack was Published
-
-After the publish build succeeds, verify that the correctly versioned template
-stack images have been pushed to Docker Hub.
-
-### Template Stack Patch Releases
-
-To do a patch release with a template stack, create a release branch from the
-minor version tag on the `master` branch, if a release branch doesn't already
-exist. Then, the regular tagging and publishing process for template stacks can
-be followed, incrementing the patch version to get the new release tag.
-
-### Build and Release Core Crossplane
-
-After the providers, stacks, and apps have all been released, ensure the [normal
-build
-pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fcrossplane%2Fbuild/branches)
-is run on the release branch for core crossplane. This will be the official
-release build with an official version number and all of its release artifacts
-will be published.
-
-After the pipeline runs successfully, you should verify that all artifacts have
-been published to:
-
-* [Docker Hub](https://hub.docker.com/repository/docker/crossplane/crossplane)
-* [S3 releases bucket](https://releases.crossplane.io/)
-* [Helm chart repository](https://charts.crossplane.io/)
-* [Docs website](https://crossplane.io/docs/latest)
-
-### Promotion
-
-If everything looks good with the official versioned release that we just
-published, we can go ahead and run the `promote` pipeline for the core
-crossplane and provider repos. This is a very quick pipeline that doesn't
-rebuild anything, it simply makes metadata changes to the published release to
-also include the release in the channel of your choice.
-
-Currently, we only support the `master` and `alpha` channels.
-
-For the core crossplane and each provider repo, run the `promote` pipeline on
-the release branch and input the version you would like to promote (e.g.
-`v0.5.0`) and the channel you'd like to promote it to. The first time you run
-this pipeline on a new release branch, you will not be prompted for values, so
-the pipeline will fail. Just run (not replay) it a second time to be prompted.
-
-* Run `promote` pipeline for `master` channel
-* Run `promote` pipeline for `alpha` channel
-
-After the `promote` pipelines have succeeded, verify on DockerHub and the Helm
-chart repository that the release has been promoted to the right channels.
-
-### Publish Release Notes
-
-Now that the release has been published and verified, you can publish the
-[release notes](https://github.com/crossplane/crossplane/releases) that you
-drafted earlier. After incorporating all feedback, you can now click on the
-"Publish release" button.
-
-This will send an email notification with the release notes to all watchers of
-the repo.
-
-### Announce Release
-
-We have completed the entire release, so it's now time to announce it to the
-world. Using the [@crossplane_io](https://twitter.com/crossplane_io) Twitter
-account, tweet about the new release and blog. You'll see examples from the
-previous releases, such as this tweet for
-[v0.4](https://twitter.com/crossplane_io/status/1189307636350705664).
-
-Post a link to this tweet on the Slack #announcements channel, then copy a link
-to that and post it in the #general channel.
-
-### Patch Releases
-
-We also have the ability to run patch releases to update previous releases that
-have already been published. These patch releases are always run from the last
-release branch, we do **not** create a new release branch for a patch release.
-
-The basic flow is **very** similar to a normal release, but with a few less
-steps. Please refer to details for each step in the sections above.
-
-* Fix any bugs in `master` first and then `cherry-pick -x` to the release branch
- * If `master` has already removed the relevant code then make your fix
- directly in the release branch
-* After all testing on the release branch look good and any docs/examples/tests
- have been updated with the new version number, run the `tag` pipeline on the
- release branch with the new patch version (e.g. `v0.5.1`)
-* Run the normal build pipeline on the release branch to build and publish the
- release
-* Publish release notes
-* Run promote pipeline to promote the patch release to the `master` and `alpha`
- channels
diff --git a/docs/v0.11/README.md b/docs/v0.11/README.md
deleted file mode 100644
index adf74605..00000000
--- a/docs/v0.11/README.md
+++ /dev/null
@@ -1,66 +0,0 @@
-# Overview
-
-
-
-Crossplane is an open source Kubernetes add-on that extends any cluster with
-the ability to provision and manage cloud infrastructure, services, and
-applications using kubectl, GitOps, or any tool that works with the Kubernetes
-API.
-
-With Crossplane you can:
-
-* **Provision & manage cloud infrastructure with kubectl**
- * [Install Crossplane] to provision and manage cloud infrastructure and
- services from any Kubernetes cluster.
- * Provision infrastructure primitives from any provider ([GCP], [AWS],
- [Azure], [Alibaba], on-prem) and use them alongside existing application
- configurations.
- * Version, manage, and deploy with your favorite tools and workflows that
- you’re using with your clusters today.
-
-* **Publish custom infrastructure resources for your applications to use**
- * Define, compose, and publish your own [infrastructure resources] with
- declarative YAML, resulting in your own infrastructure CRDs being added to
- the Kubernetes API for applications to use.
- * Hide infrastructure complexity and include policy guardrails, so
- applications can easily and safely consume the infrastructure they need,
- using any tool that works with the Kubernetes API.
- * Consume infrastructure resources alongside any Kubernetes application to
- provision and manage the cloud services they need with Crossplane as an
- add-on to any Kubernetes cluster.
-
-* **Deploy applications using a team-centric approach with OAM**
- * Define cloud native applications and the infrastructure they require with
- the Open Application Model ([OAM]).
- * Collaborate with a team-centric approach with a strong separation of
- concerns.
- * Deploy application configurations from app delivery pipelines or GitOps
- workflows, using the proven Kubernetes declarative model.
-
-Separation of concerns is core to Crossplane’s approach to infrastructure and
-application management, so team members can deliver value by focusing on what
-they know best. Crossplane's team-centric approach reflects individuals often
-specializing in the following roles:
-
-* **Infrastructure Operators** - provide infrastructure and services for apps
- to consume
-* **Application Developers** - build application components independent of
- infrastructure
-* **Application Operators** - compose, deploy, and run application
- configurations
-
-## Getting Started
-
-[Install Crossplane] into any Kubernetes cluster to get started.
-
-
-
-[Install Crossplane]: getting-started/install-configure.md
-[Custom Resource Definitions]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[reconciling]: https://kubernetes.io/docs/concepts/architecture/controller/
-[GCP]: https://github.com/crossplane/provider-gcp
-[AWS]: https://github.com/crossplane/provider-aws
-[Azure]: https://github.com/crossplane/provider-azure
-[Alibaba]: https://github.com/crossplane/provider-alibaba
-[infrastructure resources]: https://blog.crossplane.io/crossplane-v0-10-compose-and-publish-your-own-infrastructure-crds-velero-backup-restore-compatibility-and-more/
-[OAM]: https://github.com/oam-dev/spec/releases/tag/v1.0.0-alpha.2
diff --git a/docs/v0.11/api-docs/crossplane.md b/docs/v0.11/api-docs/crossplane.md
deleted file mode 100644
index afa6876d..00000000
--- a/docs/v0.11/api-docs/crossplane.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: crossplane
-toc: true
-weight: 401
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/crossplane
----
\ No newline at end of file
diff --git a/docs/v0.11/api-docs/overview.md b/docs/v0.11/api-docs/overview.md
deleted file mode 100644
index e9a92c48..00000000
--- a/docs/v0.11/api-docs/overview.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: API Documentation
-toc: true
-weight: 400
----
-
-# API Documentation
-
-The Crossplane ecosystem contains many CRDs that map to API types represented by
-external infrastructure providers. The documentation for these CRDs are
-auto-generated on [doc.crds.dev]. To find the CRDs available for providers
-maintained by the Crossplane organization, you can search for the Github URL, or
-append it in the [doc.crds.dev] URL path.
-
-For instance, to find the CRDs available for [provider-azure], you would go to:
-
-[doc.crds.dev/github.com/crossplane/provider/azure]
-
-By default, you will be served the latest CRDs on the `master` branch for the
-repository. If you prefer to see the CRDs for a specific version, you can append
-the git tag for the release:
-
-[doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0]
-
-Crossplane repositories that are not providers but do publish CRDs are also
-served on [doc.crds.dev]. For instance, the [crossplane/crossplane] repository.
-
-Bugs and feature requests for API documentation should be [opened as issues] on
-the open source [doc.crds.dev repo].
-
-
-
-[doc.crds.dev]: https://doc.crds.dev/
-[provider-azure]: https://github.com/crossplane/provider-azure
-[doc.crds.dev/github.com/crossplane/provider/azure]: https://doc.crds.dev/github.com/crossplane/provider-azure
-[doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0]: https://doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0
-[crossplane/crossplane]: https://doc.crds.dev/github.com/crossplane/crossplane
-[opened as issues]: https://github.com/crdsdev/doc/issues/new
-[doc.crds.dev repo]: https://github.com/crdsdev/doc
diff --git a/docs/v0.11/api-docs/provider-alibaba.md b/docs/v0.11/api-docs/provider-alibaba.md
deleted file mode 100644
index 471122ef..00000000
--- a/docs/v0.11/api-docs/provider-alibaba.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-alibaba
-toc: true
-weight: 402
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-alibaba
----
\ No newline at end of file
diff --git a/docs/v0.11/api-docs/provider-aws.md b/docs/v0.11/api-docs/provider-aws.md
deleted file mode 100644
index c826c3f0..00000000
--- a/docs/v0.11/api-docs/provider-aws.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-aws
-toc: true
-weight: 403
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-aws
----
\ No newline at end of file
diff --git a/docs/v0.11/api-docs/provider-azure.md b/docs/v0.11/api-docs/provider-azure.md
deleted file mode 100644
index 444d84c2..00000000
--- a/docs/v0.11/api-docs/provider-azure.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-azure
-toc: true
-weight: 404
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-azure
----
\ No newline at end of file
diff --git a/docs/v0.11/api-docs/provider-gcp.md b/docs/v0.11/api-docs/provider-gcp.md
deleted file mode 100644
index 160fe053..00000000
--- a/docs/v0.11/api-docs/provider-gcp.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-gcp
-toc: true
-weight: 405
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-gcp
----
\ No newline at end of file
diff --git a/docs/v0.11/api-docs/provider-rook.md b/docs/v0.11/api-docs/provider-rook.md
deleted file mode 100644
index c365e387..00000000
--- a/docs/v0.11/api-docs/provider-rook.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-rook
-toc: true
-weight: 406
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-rook
----
\ No newline at end of file
diff --git a/docs/v0.11/cloud-providers/aws/aws-provider.md b/docs/v0.11/cloud-providers/aws/aws-provider.md
deleted file mode 100644
index 5f27eef0..00000000
--- a/docs/v0.11/cloud-providers/aws/aws-provider.md
+++ /dev/null
@@ -1,143 +0,0 @@
-# Adding Amazon Web Services (AWS) to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your AWS
-account to be ready for integration with Crossplane. This will be done by adding
-an AWS `Provider` resource type, which enables Crossplane to communicate with an
-AWS account.
-
-## Requirements
-
-Prior to adding AWS to Crossplane, following steps need to be taken
-
-- Crossplane is installed in a k8s cluster
-- AWS Stack is installed in the same cluster
-- `kubectl` is configured to communicate with the same cluster
-
-## Step 1: Configure `aws` CLI
-
-Crossplane uses [AWS security credentials], and stores them as a [secret] which
-is managed by an AWS `Provider` instance. In addition, the AWS default region is
-also used for targeting a specific region. Crossplane requires to have [`aws`
-command line tool] [installed] and [configured]. Once installed, the credentials
-and configuration will reside in `~/.aws/credentials` and `~/.aws/config`
-respectively.
-
-## Step 2: Setup `aws` Provider
-
-Run [setup.sh] script to read `aws` credentials and region, and create an `aws
-provider` instance in Crossplane:
-
-```bash
-./cluster/examples/aws-setup-provider/setup.sh [--profile aws_profile]
-```
-
-The `--profile` switch is optional and specifies the [aws named profile] that
-was set in Step 1. If not provided, the `default` profile will be selected.
-
-Once the script is successfully executed, Crossplane will use the specified aws
-account and region in the given named profile to create subsequent AWS managed
-resources.
-
-You can confirm the existense of the AWS `Provider` by running:
-
-```bash
-kubectl -n crossplane-system get provider/aws-provider
-```
-
-## Optional: Setup AWS Provider Manually
-
-An AWS [user][aws user] with `Administrative` privileges is needed to enable
-Crossplane to create the required resources. Once the user is provisioned, an
-[Access Key][] needs to be created so the user can have API access.
-
-Using the set of [access key credentials][AWS security credentials] for the user
-with the right access, we need to [install][install-aws] [`aws cli`][aws command
-line tool], and then [configure][aws-cli-configure] it.
-
-When the AWS cli is configured, the credentials and configuration will be in
-`~/.aws/credentials` and `~/.aws/config` respectively. These will be consumed in
-the next step.
-
-When configuring the AWS cli, the user credentials could be configured under a
-specific [AWS named profile][], or under `default`. Without loss of generality,
-in this guide let's assume that the credentials are configured under the
-`aws_profile` profile (which could also be `default`). We'll use this profile to
-setup cloud provider in the next section.
-
-Crossplane uses the AWS user credentials that were configured in the previous
-step to create resources in AWS. These credentials will be stored as a
-[secret][kubernetes secret] in Kubernetes, and will be used by an AWS `Provider`
-instance. The default AWS region is also pulled from the cli configuration, and
-added to the AWS provider.
-
-To store the credentials as a secret, run:
-
-```bash
-# retrieve profile's credentials, save it under 'default' profile, and base64 encode it
-BASE64ENCODED_AWS_ACCOUNT_CREDS=$(echo -e "[default]\naws_access_key_id = $(aws configure get aws_access_key_id --profile $aws_profile)\naws_secret_access_key = $(aws configure get aws_secret_access_key --profile $aws_profile)" | base64 | tr -d "\n")
-# retrieve the profile's region from config
-AWS_REGION=$(aws configure get region --profile ${aws_profile})
-```
-
-At this point, the region and the encoded credentials are stored in respective
-variables. Next, we'll need to create an instance of AWS provider:
-
-```bash
-cat > provider.yaml <
-
-[`aws` command line tool]: https://aws.amazon.com/cli/
-[AWS SDK for GO]: https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/setting-up.html
-[installed]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html
-[configured]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html
-[AWS security credentials]: https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html
-[secret]:https://kubernetes.io/docs/concepts/configuration/secret/
-[setup.sh]: https://github.com/crossplane/crossplane/blob/master/cluster/examples/aws-setup-provider/setup.sh
-[aws named profile]: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html
-[aws user]: https://docs.aws.amazon.com/mediapackage/latest/ug/setting-up-create-iam-user.html
-[Access Key]: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
-[AWS security credentials]: https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html
-[aws command line tool]: https://aws.amazon.com/cli/
-[install-aws]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html
-[aws-cli-configure]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html
-[kubernetes secret]: https://kubernetes.io/docs/concepts/configuration/secret/
-[AWS named profile]: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html
diff --git a/docs/v0.11/cloud-providers/azure/azure-provider.md b/docs/v0.11/cloud-providers/azure/azure-provider.md
deleted file mode 100644
index c566b61f..00000000
--- a/docs/v0.11/cloud-providers/azure/azure-provider.md
+++ /dev/null
@@ -1,125 +0,0 @@
-# Adding Microsoft Azure to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your Azure
-account to be ready for integration with Crossplane. The general steps we will
-take are summarized below:
-
-* Create a new service principal (account) that Crossplane will use to create
- and manage Azure resources
-* Add the required permissions to the account
-* Consent to the permissions using an administrator account
-
-## Preparing your Microsoft Azure Account
-
-In order to manage resources in Azure, you must provide credentials for a Azure
-service principal that Crossplane can use to authenticate. This assumes that you
-have already [set up the Azure CLI
-client](https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli?view=azure-cli-latest)
-with your credentials.
-
-Create a JSON file that contains all the information needed to connect and
-authenticate to Azure:
-
-```bash
-# create service principal with Owner role
-az ad sp create-for-rbac --sdk-auth --role Owner > crossplane-azure-provider-key.json
-```
-
-Take note of the `clientID` value from the JSON file that we just created, and
-save it to an environment variable:
-
-```bash
-export AZURE_CLIENT_ID=
-```
-
-Now add the required permissions to the service principal that will allow it to
-manage the necessary resources in Azure:
-
-```bash
-# add required Azure Active Directory permissions
-az ad app permission add --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --api-permissions 1cda74f2-2616-4834-b122-5cb1b07f8a59=Role 78c8a3c8-a07e-4b9e-af1b-b5ccab50a175=Role
-
-# grant (activate) the permissions
-az ad app permission grant --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --expires never
-```
-
-You might see an error similar to the following, but that is OK, the permissions
-should have gone through still:
-
-```console
-Operation failed with status: 'Conflict'. Details: 409 Client Error: Conflict for url: https://graph.windows.net/e7985bc4-a3b3-4f37-b9d2-fa256023b1ae/oauth2PermissionGrants?api-version=1.6
-```
-
-Finally, you need to grant admin permissions on the Azure Active Directory to
-the service principal because it will need to create other service principals
-for your `AKSCluster`:
-```bash
-# grant admin consent to the service princinpal you created
-az ad app permission admin-consent --id "${AZURE_CLIENT_ID}"
-```
-
-Note: You might need `Global Administrator` role to `Grant admin consent for
-Default Directory`. Please contact the administrator of your Azure subscription.
-To check your role, go to `Azure Active Directory` -> `Roles and
-administrators`. You can find your role(s) by clicking on `Your Role (Preview)`
-
-After these steps are completed, you should have the following file on your
-local filesystem:
-
-* `crossplane-azure-provider-key.json`
-
-## Setup Azure Provider
-
-Before creating any resources, we need to create and configure an Azure cloud
-provider resource in Crossplane, which stores the cloud account information in
-it. All the requests from Crossplane to Azure Cloud will use the credentials
-attached to this provider resource. The following command assumes that you have
-a `crossplane-azure-provider-key.json` file that belongs to the account you’d
-like Crossplane to use.
-
-```bash
-BASE64ENCODED_AZURE_ACCOUNT_CREDS=$(base64 crossplane-azure-provider-key.json | tr -d "\n")
-```
-
-Now we’ll create our `Secret` that contains the credential and `Provider`
-resource that refers to that secret:
-
-```bash
-cat > provider.yaml < provider.yaml <
-[templating-controller]: https://github.com/crossplane/templating-controller
-[stack-gcp-sample]: https://github.com/crossplane/stack-gcp-sample
-[stack-aws-sample]: https://github.com/crossplane/stack-aws-sample
-[stack-azure-sample]: https://github.com/crossplane/stack-azure-sample
-[app-wordpress]: https://github.com/crossplane/app-wordpress
-[Wordpress Quickstart Guide]: https://github.com/crossplane/app-wordpress/blob/master/docs/quickstart.md
-[packaging an app]: experimental/packaging_an_app.md
\ No newline at end of file
diff --git a/docs/v0.11/contributing/experimental/packaging_an_app.md b/docs/v0.11/contributing/experimental/packaging_an_app.md
deleted file mode 100644
index 38cdbc71..00000000
--- a/docs/v0.11/contributing/experimental/packaging_an_app.md
+++ /dev/null
@@ -1,198 +0,0 @@
----
-title: Packaging an Application
-toc: false
-weight: 2000
-indent: true
----
-
-# Packaging an Application
-
-In the quick start guide, we demonstrated how Wordpress can be installed as a
-Crossplane `Application`. Now we want to learn more about how to package any
-application in a similar fashion. The good news is that we can use common
-Kubernetes configuration tools, such as [Helm] and [Kustomize], which you may
-already be familiar with.
-
-## Setting up a Repository
-
-The required components of an application repository are minimal. For example,
-the required components of the [Wordpress application] we deployed in the quick
-start are the following:
-
-```
-├── Dockerfile
-├── .registry
-│ ├── app.yaml
-│ ├── behavior.yaml
-│ ├── icon.svg
-│ └── resources
-│ ├── wordpress.apps.crossplane.io_wordpressinstances.crd.yaml
-│ ├── wordpressinstance.icon.svg
-│ ├── wordpressinstance.resource.yaml
-│ └── wordpressinstance.ui-schema.yaml
-├── helm-chart
-│ ├── Chart.yaml
-│ ├── templates
-│ │ ├── app.yaml
-│ │ ├── cluster.yaml
-│ │ └── database.yaml
-│ └── values.yaml
-```
-
-Let's take a look at each component in-depth.
-
-### Dockerfile
-
-The Dockerfile is only responsible for copying the configuration directory
-(`helm-chart/` in this case) and the `.registry` directory. You can likely use a
-very similar Dockerfile across all of your applications:
-
-```Dockerfile
-FROM alpine:3.7
-WORKDIR /
-COPY helm-chart /helm-chart
-COPY .registry /.registry
-```
-
-### .registry
-
-The `.registry` directory informs Crossplane how to install your application. It
-consists of the following:
-
-**app.yaml** `[required]`
-
-The `app.yaml` file is responsible for defining the metadata for an application,
-such as name, version, and required permissions. The Wordpress `app.yaml` is a
-good reference for available fields:
-
-```yaml
-# Human readable title of application.
-title: Wordpress
-
-overviewShort: Cloud portable Wordpress deployments behind managed Kubernetes and SQL services are demonstrated in this Crossplane Stack.
-
-overview: |-
- This Wordpress application uses a simple controller that uses Crossplane to orchestrate managed SQL services and managed Kubernetes clusters which are then used to run a Wordpress deployment.
- A simple Custom Resource Definition (CRD) is provided allowing for instances of this Crossplane managed Wordpress Application to be provisioned with a few lines of yaml.
- The Sample Wordpress Application is intended for demonstration purposes and should not be used to deploy production instances of Wordpress.
-
-# Markdown description of this entry
-readme: |-
- ### Create wordpresses
- Before wordpresses will provision, the Crossplane control cluster must
- be configured to connect to a provider (e.g. GCP, Azure, AWS).
- Once a provider is configured, starting the process of creating a
- Wordpress Application instance is easy.
-
- cat <.icon.svg`: an image to be displayed for your application CRD
-- `.resource.yaml`: a description of your application CRD
-- `.ui-schema.yaml`: the configurable fields on your CRD that you
- wish to be displayed in a UI
-
-Crossplane will take these files and apply them as [annotations] on the
-installed application. They can then be parsed by a user interface.
-
-### Configuration Directory
-
-The configuration directory contains the actual manifests for deploying your
-application. In the case of Wordpress, this includes a `KubernetesApplication`
-(`helm-chart/templates/app.yaml`), a `KubernetesCluster` claim
-(`helm-chart/templates/cluster.yaml`), and a `MySQLInstance` claim
-(`helm-chart/templates/database.yaml`). The configuration tool for the manifests
-in the directory should match the `engine` field in your
-`.registry/behavior.yaml`. The options for engines at this time are `helm3` and
-`kustomize`. Crossplane will pass values from the `spec` of the application's
-CRD as variables in the manifests. For instance, the `provisionPolicy` field in
-the `spec` of the `WordpressInstance` CRD will be passed to the Helm chart
-defined in the `helm-chart/` directory.
-
-
-
-[Helm]: https://helm.sh/
-[Kustomize]: https://kustomize.io/
-[Wordpress application]: https://github.com/crossplane/app-wordpress
-[CustomResourceDefinition]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[controller-tools]: https://github.com/kubernetes-sigs/controller-tools
-[annotations]: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
diff --git a/docs/v0.11/contributing/observability_developer_guide.md b/docs/v0.11/contributing/observability_developer_guide.md
deleted file mode 100644
index 9741512f..00000000
--- a/docs/v0.11/contributing/observability_developer_guide.md
+++ /dev/null
@@ -1,200 +0,0 @@
----
-title: Observability Developer Guide
-toc: true
-weight: 1002
-indent: true
----
-
-# Observability Developer Guide
-
-## Introduction
-
-Observability is crucial to Crossplane users; both those operating Crossplane
-and those using Crossplane to operate their infrastructure. Crossplane currently
-approaches observability via Kubernetes events and structured logs. Timeseries
-metrics are desired but [not yet implemented].
-
-## Goals
-
-In short, a non-admin user and an admin user should both be able to debug any
-issues only by inspecting logs and events. There should be no need to rebuild
-the Crossplane binary or to reach out to a Crossplane developer.
-
-A user should be able to:
-
-* Debug an issue without rebuilding the Crossplane binary
-* Understand an issue without contacting a cluster admin
-* Ask a cluster admin to check the logs for more details about the reason the
- issue happened, if the details are not part of the error message
-
-A cluster admin should be able to:
-
-* Debug an issue without rebuilding the Crossplane binary
-* Debug an issue only by looking at the logs
-* Debug an issue without needing to contact a Crossplane developer
-
-## Error reporting in the logs
-
-Error reporting in the logs is mostly intended for consumption by Crossplane
-cluster admins. A cluster admin should be able to debug any issue by inspecting
-the logs, without needing to add more logs themselves or contact a Crossplane
-developer. This means that logs should contain:
-
-* Error messages, at either the info or debug level as contextually appropriate
-* Any context leading up to an error, typically at debug level, so that the
- errors can be debugged
-
-## Error reporting as events
-
-Error reporting as Kubernetes events is primarily aimed toward end-users of
-Crossplane who are not cluster admins. Crossplane typically runs as a Kubernetes
-pod, and thus it is unlikely that most users of Crossplane will have access to
-its logs. [Events], on the other hand, are available as top-level Kubernetes
-objects, and show up the objects they relate to when running `kubectl describe`.
-
-Events should be recorded in the following cases:
-
-* A significant operation is taken on a resource
-* The state of a resource is changed
-* An error occurs
-
-The events recorded in these cases can be thought of as forming an event log of
-things that happen for the resources that Crossplane manages. Each event should
-refer back to the relevant controller and resource, and use other fields of the
-Event kind as appropriate.
-
-More details about examples of how to interact with events can be found in the
-guide to [debugging an application cluster].
-
-## Choosing between methods of error reporting
-
-There are many ways to report errors, such as:
-
-* Metrics
-* Events
-* Logging
-* Tracing
-
-It can be confusing to figure out which one is appropriate in a given situation.
-This section will try to offer advice and a mindset that can be used to help
-make this decision.
-
-Let's set the context by listing the different user scenarios where error
-reporting may be consumed. Here are the typical scenarios as we imagine them:
-
-1. A person **using** a system needs to figure out why things aren't working as
- expected, and whether they made a mistake that they can correct.
-2. A person **operating** a service needs to monitor the service's **health**,
- both now and historically.
-3. A person **debugging** a problem which happened in a **live environment**
- (often an **operator** of the system) needs information to figure out what
- happened.
-4. A person **developing** the software wants to **observe** what is happening.
-5. A person **debugging** the software in a **development environment**
- (typically a **developer** of the system) wants to debug a problem (there is
- a lot of overlap between this and the live environment debugging scenario).
-
-The goal is to satisfy the users in all of the scenarios. We'll refer to the
-scenarios by number.
-
-The short version is: we should do whatever satisfies all of the scenarios.
-Logging and events are the recommendations for satisfying the scenarios,
-although they don't cover scenario 2.
-
-The longer version is:
-
-* Scenario 1 is best served by events in the context of Crossplane, since the
- users may not have access to read logs or metrics, and even if they did, it
- would be hard to relate them back to the event the user is trying to
- understand.
-* Scenario 2 is best served by metrics, because they can be aggregated and
- understood as a whole. And because they can be used to track things over time.
-* Scenario 3 is best served by either logging that contains all the information
- about and leading up to the event. Request-tracing systems are also useful for
- this scenario.
-* Scenario 4 is usually logs, maybe at a more verbose level than normal. But it
- could be an attached debugger or some other type of tool. It could also be a
- test suite.
-* Scenario 5 is usually either logs, up to the highest imaginable verbosity, or
- an attached debugging session. If there's a gap in reporting, it could involve
- adding some print statements to get more logging.
-
-As for the question of how to decide whether to log or not, we believe it helps
-to try to visualize which of the scenarios the error or information in question
-will be used for. We recommend starting with reporting as much information as
-possible, but with configurable runtime behavior so that, for example, debugging
-logs don't show up in production normally.
-
-For the question of what constitutes an error, errors should be actionable by a
-human. See the [Dave Cheney article] on this topic for some more discussion.
-
-## In Practice
-
-Crossplane provides two observability libraries as part of crossplane-runtime:
-
-* [`event`] emits Kubernetes events.
-* [`logging`] produces structured logs. Refer to its package documentation for
- additional context on its API choices.
-
-Keep the following in mind when using the above libraries:
-
-* [Do] [not] use package level loggers or event recorders. Instantiate them in
- `main()` and plumb them down to where they're needed.
-* Each [`Reconciler`] implementation should use its own `logging.Logger` and
- `event.Recorder`. Implementations are strongly encouraged to default to using
- `logging.NewNopLogger()` and `event.NewNopRecorder()`, and accept a functional
- loggers and recorder via variadic options. See for example the [managed
- resource reconciler].
-* Each controller should use its name as its event recorder's name, and include
- its name under the `controller` structured logging key. The controllers name
- should be of the form `controllertype/resourcekind`, for example
- `managed/cloudsqlinstance` or `stacks/stackdefinition`. Controller names
- should always be lowercase.
-* Logs and events should typically be emitted by the `Reconcile` method of the
- `Reconciler` implementation; not by functions called by `Reconcile`. Author
- the methods orchestrated by `Reconcile` as if they were a library; prefer
- surfacing useful information for the `Reconciler` to log (for example by
- [wrapping errors]) over plumbing loggers and event recorders down to
- increasingly deeper layers of code.
-* Almost nothing is worth logging at info level. When deciding which logging
- level to use, consider a production deployment of Crossplane reconciling tens
- or hundreds of managed resources. If in doubt, pick debug. You can easily
- increase the log level later if it proves warranted.
-* The above is true even for errors; consider the audience. Is this an error
- only the Crossplane cluster operator can fix? Does it indicate a significant
- degradation of Crossplane's functionality? If so, log it at info. If the error
- pertains to a single Crossplane resource emit an event instead.
-* Always log errors under the structured logging key `error` (e.g.
- `log.Debug("boom!, "error", err)`). Many logging implementations (including
- Crossplane's) add context like stack traces for this key.
-* Emit events liberally; they're rate limited and deduplicated.
-* Follow [API conventions] when emitting events; ensure event reasons are unique
- and `CamelCase`.
-* Consider emitting events and logs when a terminal condition is encountered
- (e.g. `Reconcile` returns) over logging logic flow. i.e. Prefer one log line
- that reads "encountered an error fooing the bar" over two log lines that read
- "about to foo the bar" and "encountered an error". Recall that if the audience
- is a developer debugging Crossplane they will be provided a stack trace with
- file and line context when an error is logged.
-* Consider including the `reconcile.Request`, and the resource's UID and
- resource version (not API version) under the keys `request`, `uid`, and
- `version`. Doing so allows log readers to determine what specific version of a
- resource the log pertains to.
-
-Finally, when in doubt, aim for consistency with existing Crossplane controller
-implementations.
-
-
-
-[not yet implemented]: https://github.com/crossplane/crossplane/issues/314
-[Events]: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#event-v1-core
-[debugging an application cluster]: https://kubernetes.io/docs/tasks/debug-application-cluster/
-[Dave Cheney article]: https://dave.cheney.net/2015/11/05/lets-talk-about-logging
-[`event`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/event
-[`logging`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/logging
-[Do]: https://peter.bourgon.org/go-best-practices-2016/#logging-and-instrumentation
-[not]: https://dave.cheney.net/2017/01/23/the-package-level-logger-anti-pattern
-[`Reconciler`]: https://godoc.org/sigs.k8s.io/controller-runtime/pkg/reconcile#Reconciler
-[managed resource reconciler]: https://github.com/crossplane/crossplane-runtime/blob/a6bb0/pkg/reconciler/managed/reconciler.go#L436
-[wrapping errors]: https://godoc.org/github.com/pkg/errors#Wrap
-[API conventions]: https://github.com/kubernetes/community/blob/09f55c6/contributors/devel/sig-architecture/api-conventions.md#events
diff --git a/docs/v0.11/contributing/overview.md b/docs/v0.11/contributing/overview.md
deleted file mode 100644
index bbf258a5..00000000
--- a/docs/v0.11/contributing/overview.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Contributing
-toc: true
-weight: 1000
----
-
-# Contributing
-
-The following documentation is for developers who wish to contribute to or
-extend Crossplane. Please [open an
-issue](https://github.com/crossplane/crossplane/issues/new) for any additional
-documentation you would like to see in this section.
-
-1. [Services Developer Guide]
-2. [Observability Developer Guide]
-
-# Experimental Projects
-See [experimental] projects.
-
-
-[Services Developer Guide]: services_developer_guide.md
-[Observability Developer Guide]: observability_developer_guide.md
-[experimental]: experimental.md
diff --git a/docs/v0.11/contributing/services_developer_guide.md b/docs/v0.11/contributing/services_developer_guide.md
deleted file mode 100644
index 4fbee07f..00000000
--- a/docs/v0.11/contributing/services_developer_guide.md
+++ /dev/null
@@ -1,646 +0,0 @@
----
-title: Managed Resource Developer Guide
-toc: true
-weight: 1001
-indent: true
----
-
-# Managed Resource Developer Guide
-
-Crossplane allows you to manage infrastructure directly from Kubernetes. Each
-infrastructure API resource that Crossplane orchestrates is known as a "managed
-resource". This guide will walk through the process of adding support for a new
-kind of managed resource to Crossplane.
-
-## What Makes a Crossplane Infrastructure Resource
-
-Crossplane builds atop Kubernetes's powerful architecture in which declarative
-configuration, known as resources, are continually 'reconciled' with reality by
-one or more controllers. A controller is an endless loop that:
-
-1. Observes the desired state (the declarative configuration resource).
-1. Observes the actual state (the thing said configuration resource represents).
-1. Tries to make the actual state match the desired state.
-
-Typical Crossplane managed infrastructure consists of two configuration
-resources and one controller. The GCP Provider's support for Google Cloud
-Memorystore illustrates this. First, the configuration resources:
-
-1. A [managed resource]. Managed resources are cluster scoped, high-fidelity
- representations of a resource in an external system such as a cloud
- provider's API. Managed resources are _non-portable_ across external systems
- (i.e. cloud providers); they're tightly coupled to the implementation details
- of the external resource they represent. Managed resources are defined by a
- Provider. The GCP Provider's [`CloudMemorystoreInstance`] resource is an
- example of a managed resource.
-1. A provider. Providers enable access to an external system, typically by
- indicating a Kubernetes Secret containing any credentials required to
- authenticate to the system, as well as any other metadata required to
- connect. Providers are cluster scoped, like managed resources and classes.
- The GCP [`Provider`] is an example of a provider. Note that provider is a
- somewhat overloaded term in the Crossplane ecosystem - it's also used to
- refer to the controller manager for a particular cloud, for example
- `provider-gcp`.
-
-A managed resource is powered by a controller. This controller is responsible
-for taking instances of the aforementioned high-fidelity managed resource kind
-and reconciling them with an external system. The `CloudMemorystoreInstance`
-controller watches for changes to `CloudMemorystoreInstance` resources and calls
-Google's Cloud Memorystore API to create, update, or delete an instance as
-necessary.
-
-Crossplane does not require controllers to be written in any particular
-language. The Kubernetes API server is our API boundary, so any process capable
-of [watching the API server] and updating resources can be a Crossplane
-controller.
-
-## Getting Started
-
-At the time of writing all Crossplane Services controllers are written in Go,
-and built using [crossplane-runtime]. While it is possible to write a controller
-using any language and tooling with a Kubernetes client this set of tools are
-the "[golden path]". They're well supported, broadly used, and provide a shared
-language with the Crossplane community. This guide targets [crossplane-runtime
-v0.9.0]. It assumes the reader is familiar with the Kubernetes [API Conventions]
-and the [kubebuilder book].
-
-## Defining Resource Kinds
-
-Let's assume we want to add Crossplane support for your favourite cloud's
-database-as-a-service. Your favourite cloud brands these instances as "Favourite
-DB instances". Under the hood they're powered by the open source FancySQL
-engine. We'll name the new managed resource kind `FavouriteDBInstance` and the
-new resource claim `FancySQLInstance`.
-
-The first step toward implementing a new managed service is to define the code
-level schema of its configuration resources. These are referred to as
-[resources], (resource) [kinds], and [objects] interchangeably. The kubebuilder
-scaffolding is a good starting point for any new Crossplane API kind, whether
-they'll be a managed resource, resource class, or resource claim.
-
-> Note that while Crossplane was originally derived from kubebuilder scaffolds
-> its patterns have diverged somewhat. It is _possible_ to use kubebuilder to
-> scaffold a resource, but the author must be careful to adapt said resource to
-> Crossplane patterns. It may often be quicker to copy and modify a v1beta1 or
-> above resource from the same provider repository, rather than using
-> kubebuilder.
-
-```console
-# The resource claim.
-kubebuilder create api \
- --group example --version v1alpha1 --kind FancySQLInstance \
- --resource=true --controller=false --namespaced=false
-```
-
-The above command should produce a scaffold similar to the below example:
-
-```go
-type FancySQLInstanceSpec struct {
- // INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
- // Important: Run "make" to regenerate code after modifying this file
-}
-
-// FancySQLInstanceStatus defines the observed state of FancySQLInstance
-type FancySQLInstanceStatus struct {
- // INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
- // Important: Run "make" to regenerate code after modifying this file
-}
-
-// +kubebuilder:object:root=true
-
-// FancySQLInstance is the Schema for the fancysqlinstances API
-// +kubebuilder:resource:scope=Cluster
-type FancySQLInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FancySQLInstanceSpec `json:"spec,omitempty"`
- Status FancySQLInstanceStatus `json:"status,omitempty"`
-}
-```
-
-Crossplane requires that these newly generated API type scaffolds be extended
-with a set of struct fields, getters, and setters that are standard to all
-Crossplane resource kinds. The getters and setter methods required to satisfy
-crossplane-runtime interfaces are omitted from the below examples for brevity.
-They can be added by hand, but new services are encouraged to use [`angryjet`]
-to generate them automatically using a `//go:generate` comment per the
-[`angryjet` documentation].
-
-Note that in many cases a suitable provider will already exist. Frequently
-adding support for a new managed service requires only the definition of the
-managed resource itself.
-
-### Managed Resource Kinds
-
-Managed resources must:
-
-* Satisfy crossplane-runtime's [`resource.Managed`] interface.
-* Embed a [`ResourceStatus`] struct in their `Status` struct.
-* Embed a [`ResourceSpec`] struct in their `Spec` struct.
-* Embed a `Parameters` struct in their `Spec` struct.
-* Use the `+kubebuilder:subresource:status` [comment marker].
-* Use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-The `Parameters` struct should be a _high fidelity_ representation of the
-writeable fields of the external resource's API. Put otherwise, if your
-favourite cloud represents Favourite DB instances as a JSON object then
-`FavouriteDBParameters` should marshal to a something as close to that JSON
-object as possible while still complying with Kubernetes API conventions.
-
-For example, assume the external API object for Favourite DB instance was:
-
-```json
-{
- "id": 42,
- "name": "mycoolinstance",
- "fanciness_level": 100,
- "version": "2.3",
- "status": "ONLINE",
- "hostname": "cool.fcp.example.org"
-}
-```
-
-Further assume the `id`, `status`, and `hostname` fields were output only, and
-the `version` field was optional. The `FavouriteDBInstance` managed resource
-should look as follows:
-
-```go
-// FavouriteDBInstanceParameters define the desired state of an FavouriteDB
-// instance. Most fields map directly to an Instance:
-// https://favourite.example.org/api/v1/db#Instance
-type FavouriteDBInstanceParameters struct {
-
- // We're still working on a standard for naming external resources. See
- // https://github.com/crossplane/crossplane/issues/624 for context.
-
- // Name of this instance.
- Name string `json:"name"`
-
- // Note that fanciness_level becomes fancinessLevel below. Kubernetes API
- // conventions trump cloud provider fidelity.
-
- // FancinessLevel specifies exactly how fancy this instance is.
- FancinessLevel int `json:"fancinessLevel"`
-
- // Version specifies what version of FancySQL this instance will run.
- // +optional
- Version *string `json:"version,omitempty"`
-}
-
-// A FavouriteDBInstanceSpec defines the desired state of a FavouriteDBInstance.
-type FavouriteDBInstanceSpec struct {
- runtimev1alpha1.ResourceSpec `json:",inline"`
- ForProvider FavouriteDBInstanceParameters `json:"forProvider"`
-}
-
-// A FavouriteDBInstanceStatus represents the observed state of a
-// FavouriteDBInstance.
-type FavouriteDBInstanceStatus struct {
- runtimev1alpha1.ResourceStatus `json:",inline"`
-
- // Note that we add the three "output only" fields here in the status,
- // instead of the parameters. We want this representation to be high
- // fidelity just like the parameters.
-
- // ID of this instance.
- ID int `json:"id,omitempty"`
-
- // Status of this instance.
- Status string `json:"status,omitempty"`
-
- // Hostname of this instance.
- Hostname string `json:"hostname,omitempty"`
-}
-
-// A FavouriteDBInstance is a managed resource that represents a Favourite DB
-// instance.
-// +kubebuilder:subresource:status
-type FavouriteDBInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FavouriteDBInstanceSpec `json:"spec"`
- Status FavouriteDBInstanceStatus `json:"status,omitempty"`
-}
-```
-
-Note that Crossplane uses the GoDoc strings of API kinds to generate user facing
-API documentation. __Document all fields__ and prefer GoDoc that assumes the
-reader is running `kubectl explain`, or reading an API reference, not reading
-the code. Refer to the [Managed Resource API Patterns] one pager for more detail
-on authoring high fidelity managed resources.
-
-### Provider Kinds
-
-You'll typically only need to add a new Provider kind if you're creating an
-infrastructure provider that adds support for a new infrastructure provider.
-
-Providers must:
-
-* Be named exactly `Provider`.
-* Embed a [`ProviderSpec`] struct in their `Spec` struct.
-* Use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-The Favourite Cloud `Provider` would look as follows. Note that the cloud to
-which it belongs should be indicated by its API group, i.e. its API Version
-would be `favouritecloud.crossplane.io/v1alpha1` or similar.
-
-```go
-// A ProviderSpec defines the desired state of a Provider.
-type ProviderSpec struct {
- runtimev1alpha1.ProviderSpec `json:",inline"`
-
- // Information required outside of the Secret referenced in the embedded
- // runtimev1alpha1.ProviderSpec that is required to authenticate to the provider.
- // ProjectID is used as an example here.
- ProjectID string `json:"projectID"`
-}
-
-// A Provider configures a Favourite Cloud 'provider', i.e. a connection to a
-// particular Favourite Cloud project using a particular Favourite Cloud service
-// account.
-type Provider struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec ProviderSpec `json:"spec"`
-}
-```
-
-### Finishing Touches
-
-At this point we've defined the managed resource necessary to start
-building controllers. Before moving on to the controllers:
-
-* Add any kubebuilder [comment markers] that may be useful for your resource.
- Comment markers can be used to validate input, or add additional columns to
- the standard `kubectl get` output, among other things.
-* Run `make reviewable` to generate Custom Resource Definitions and additional
- helper methods for your new resource kinds.
-* Make sure any package documentation (i.e. `// Package v1alpha1...` GoDoc,
- including package level comment markers) are in a file named `doc.go`.
- kubebuilder adds them to `groupversion_info.go`, but several code generation
- tools only check `doc.go`.
-
-Finally, add convenience [`GroupVersionKind`] variables for each new resource
-kind. These are typically added to either `register.go` or
-`groupversion_info.go` depending on which version of kubebuilder scaffolded the
-API type:
-
-```go
-// FancySQLInstance type metadata.
-var (
- FancySQLInstanceKind = reflect.TypeOf(FancySQLInstance{}).Name()
- FancySQLInstanceKindAPIVersion = FancySQLInstanceKind + "." + GroupVersion.String()
- FancySQLInstanceGroupVersionKind = GroupVersion.WithKind(FancySQLInstanceKind)
-)
-```
-
-Consider opening a draft pull request and asking a Crossplane maintainer for
-review before you start work on the controller!
-
-## Adding Controllers
-
-Crossplane controllers, like those scaffolded by kubebuilder, are built around
-the [controller-runtime] library. controller-runtime flavoured controllers
-encapsulate most of their domain-specific logic in a [`reconcile.Reconciler`]
-implementation. Most Crossplane controllers are one of the three kinds mentioned
-under [What Makes a Crossplane Managed Service]. Each of these controller kinds
-are similar enough across implementations that [crossplane-runtime] provides
-'default' reconcilers. These reconcilers encode what the Crossplane community
-has learned about managing external systems and narrow the problem space from
-reconciling a Kubernetes resource kind with an arbitrary system down to
-Crossplane-specific tasks.
-
-crossplane-runtime provides the following `reconcile.Reconcilers`:
-
-* The [`managed.Reconciler`] reconciles managed resources with external systems
- by instantiating a client of the external API and using it to create, update,
- or delete the external resource as necessary.
-
-Crossplane controllers typically differ sufficiently from those scaffolded by
-kubebuilder that there is little value in using kubebuilder to generate a
-controller scaffold.
-
-### Managed Resource Controllers
-
-Managed resource controllers should use [`managed.NewReconciler`] to wrap a
-managed-resource specific implementation of [`managed.ExternalConnecter`]. Parts
-of `managed.Reconciler`'s behaviour is customisable; refer to the
-[`managed.NewReconciler`] GoDoc for a list of options. The following is an
-example controller for the `FavouriteDBInstance` managed resource we defined
-earlier:
-
-```go
-import (
- "context"
- "fmt"
- "strings"
-
- "github.com/pkg/errors"
- corev1 "k8s.io/api/core/v1"
- "k8s.io/apimachinery/pkg/types"
- ctrl "sigs.k8s.io/controller-runtime"
- "sigs.k8s.io/controller-runtime/pkg/client"
-
- // An API client of the hypothetical FavouriteDB service.
- "github.com/fcp-sdk/v1/services/database"
-
- runtimev1alpha1 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
- "github.com/crossplane/crossplane-runtime/pkg/meta"
- "github.com/crossplane/crossplane-runtime/pkg/resource"
- "github.com/crossplane/crossplane-runtime/pkg/reconciler/managed"
-
- "github.com/crossplane/provider-fcp/apis/database/v1alpha3"
- fcpv1alpha3 "github.com/crossplane/provider-fcp/apis/v1alpha3"
-)
-
-type FavouriteDBInstanceController struct{}
-
-// SetupWithManager instantiates a new controller using a managed.Reconciler
-// configured to reconcile FavouriteDBInstances using an ExternalClient produced by
-// connecter, which satisfies the ExternalConnecter interface.
-func (c *FavouriteDBInstanceController) SetupWithManager(mgr ctrl.Manager) error {
- return ctrl.NewControllerManagedBy(mgr).
- Named(strings.ToLower(fmt.Sprintf("%s.%s", v1alpha3.FavouriteDBInstanceKind, v1alpha3.Group))).
- For(&v1alpha3.FavouriteDBInstance{}).
- Complete(managed.NewReconciler(mgr,
- resource.ManagedKind(v1alpha3.FavouriteDBInstanceGroupVersionKind),
- managed.WithExternalConnecter(&connecter{client: mgr.GetClient()})))
-}
-
-// Connecter satisfies the resource.ExternalConnecter interface.
-type connecter struct{ client client.Client }
-
-// Connect to the supplied resource.Managed (presumed to be a
-// FavouriteDBInstance) by using the Provider it references to create a new
-// database client.
-func (c *connecter) Connect(ctx context.Context, mg resource.Managed) (managed.ExternalClient, error) {
- // Assert that resource.Managed we were passed in fact contains a
- // FavouriteDBInstance. We told NewControllerManagedBy that this was a
- // controller For FavouriteDBInstance, so something would have to go
- // horribly wrong for us to encounter another type.
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return nil, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Get the Provider referenced by the FavouriteDBInstance.
- p := &fcpv1alpha3.Provider{}
- if err := c.client.Get(ctx, meta.NamespacedNameOf(i.Spec.ProviderReference), p); err != nil {
- return nil, errors.Wrap(err, "cannot get Provider")
- }
-
- // Get the Secret referenced by the Provider.
- s := &corev1.Secret{}
- n := types.NamespacedName{Namespace: p.Namespace, Name: p.Spec.Secret.Name}
- if err := c.client.Get(ctx, n, s); err != nil {
- return nil, errors.Wrap(err, "cannot get Provider secret")
- }
-
- // Create and return a new database client using the credentials read from
- // our Provider's Secret.
- client, err := database.NewClient(ctx, s.Data[p.Spec.Secret.Key])
- return &external{client: client}, errors.Wrap(err, "cannot create client")
-}
-
-// External satisfies the resource.ExternalClient interface.
-type external struct{ client database.Client }
-
-// Observe the existing external resource, if any. The managed.Reconciler
-// calls Observe in order to determine whether an external resource needs to be
-// created, updated, or deleted.
-func (e *external) Observe(ctx context.Context, mg resource.Managed) (managed.ExternalObservation, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalObservation{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Use our FavouriteDB API client to get an up to date view of the external
- // resource.
- existing, err := e.client.GetInstance(ctx, i.Spec.Name)
-
- // If we encounter an error indicating the external resource does not exist
- // we want to let the managed.Reconciler know so it can create it.
- if database.IsNotFound(err) {
- return managed.ExternalObservation{ResourceExists: false}, nil
- }
-
- // Any other errors are wrapped (as is good Go practice) and returned to the
- // managed.Reconciler. It will update the "Synced" status condition
- // of the managed resource to reflect that the most recent reconcile failed
- // and ensure the reconcile is reattempted after a brief wait.
- if err != nil {
- return managed.ExternalObservation{}, errors.Wrap(err, "cannot get instance")
- }
-
- // The external resource exists. Copy any output-only fields to their
- // corresponding entries in our status field.
- i.Status.Status = existing.GetStatus()
- i.Status.Hostname = existing.GetHostname()
- i.Status.ID = existing.GetID()
-
- // Update our "Ready" status condition to reflect the status of the external
- // resource. Most managed resources use the below well known reasons that
- // the "Ready" status may be true or false, but managed resource authors
- // are welcome to define and use their own.
- switch i.Status.Status {
- case database.StatusOnline:
- // If the resource is available we also want to mark it as bindable to
- // resource claims.
- resource.SetBindable(i)
- i.SetConditions(runtimev1alpha1.Available())
- case database.StatusCreating:
- i.SetConditions(runtimev1alpha1.Creating())
- case database.StatusDeleting:
- i.SetConditions(runtimev1alpha1.Deleting())
- }
-
- // Finally, we report what we know about the external resource. In this
- // hypothetical case FancinessLevel is the only field that can be updated
- // after creation time, so the resource does not need to be updated if
- // the actual fanciness level matches our desired fanciness level. Any
- // ConnectionDetails we return will be published to the managed resource's
- // connection secret if it specified one.
- o := managed.ExternalObservation{
- ResourceExists: true,
- ResourceUpToDate: existing.GetFancinessLevel == i.Spec.FancinessLevel,
- ConnectionDetails: managed.ConnectionDetails{
- runtimev1alpha1.ResourceCredentialsSecretUserKey: []byte(existing.GetUsername()),
- runtimev1alpha1.ResourceCredentialsSecretEndpointKey: []byte(existing.GetHostname()),
- },
- }
-
- return o, nil
-}
-
-// Create a new external resource based on the specification of our managed
-// resource. managed.Reconciler only calls Create if Observe reported
-// that the external resource did not exist.
-func (e *external) Create(ctx context.Context, mg resource.Managed) (managed.ExternalCreation, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalCreation{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
- // Indicate that we're about to create the instance. Remember ExternalClient
- // authors can use a bespoke condition reason here in cases where Creating
- // doesn't make sense.
- i.SetConditions(runtimev1alpha1.Creating())
-
- // Create must return any connection details that are set or returned only
- // at creation time. The managed.Reconciler will merge any details
- // with those returned during the Observe phase.
- password := database.GeneratePassword()
- cd := managed.ConnectionDetails{runtimev1alpha1.ResourceCredentialsSecretPasswordKey: []byte(password)}
-
- // Create a new instance.
- new := database.Instance{Name: i.Name, FancinessLevel: i.FancinessLevel, Version: i.Version}
- err := e.client.CreateInstance(ctx, new, password)
-
- // Note that we use resource.Ignore to squash any error that indicates the
- // external resource already exists. Create implementations must not return
- // an error if asked to create a resource that already exists. Real managed
- // resource controllers are advised to avoid unintentially 'adoptign' an
- // existing, unrelated external resource, per
- // https://github.com/crossplane/crossplane-runtime/issues/27
- return managed.ExternalCreation{ConnectionDetails: cd}, errors.Wrap(resource.Ignore(database.IsExists, err), "cannot create instance")
-}
-
-// Update the existing external resource to match the specifications of our
-// managed resource. managed.Reconciler only calls Update if Observe
-// reported that the external resource was not up to date.
-func (e *external) Update(ctx context.Context, mg resource.Managed) (managed.ExternalUpdate, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalUpdate{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Recall that FancinessLevel is the only field that we _can_ update.
- new := database.Instance{Name: i.Name, FancinessLevel: i.FancinessLevel}
- err := e.client.UpdateInstance(ctx, new)
- return managed.ExternalUpdate{}, errors.Wrap(err, "cannot update instance")
-}
-
-// Delete the external resource. managed.Reconciler only calls Delete
-// when a managed resource with the 'Delete' reclaim policy has been deleted.
-func (e *external) Delete(ctx context.Context, mg resource.Managed) error {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return errors.New("managed resource is not a FavouriteDBInstance")
- }
- // Indicate that we're about to delete the instance.
- i.SetConditions(runtimev1alpha1.Deleting())
-
- // Delete the instance.
- err := e.client.DeleteInstance(ctx, i.Spec.Name)
-
- // Note that we use resource.Ignore to squash any error that indicates the
- // external resource does not exist. Delete implementations must not return
- // an error when asked to delete a non-existent external resource.
- return errors.Wrap(resource.Ignore(database.IsNotFound, err), "cannot delete instance")
-}
-```
-
-### Wrapping Up
-
-Once all your controllers are in place you'll want to test them. Note that most
-projects under the [crossplane org] [favor] table driven tests that use Go's
-standard library `testing` package over kubebuilder's Gingko based tests. Please
-do not add or proliferate Gingko based tests.
-
-Finally, don't forget to plumb any newly added resource kinds and controllers up
-to your controller manager. Simple providers may do this for each type within
-within `main()`, but most more complicated providers take an approach in which
-each package exposes an `AddToScheme` (for resource kinds) or `SetupWithManager`
-(for controllers) function that invokes the same function within its child
-packages, resulting in a `main.go` like:
-
-```go
-import (
- "time"
-
- "sigs.k8s.io/controller-runtime/pkg/client/config"
- "sigs.k8s.io/controller-runtime/pkg/manager"
- "sigs.k8s.io/controller-runtime/pkg/manager/signals"
-
- crossplaneapis "github.com/crossplane/crossplane/apis"
-
- fcpapis "github.com/crossplane/provider-fcp/apis"
- "github.com/crossplane/provider-fcp/pkg/controller"
-)
-
-func main() {
- cfg, err := config.GetConfig()
- if err != nil {
- panic(err)
- }
-
- mgr, err := manager.New(cfg, manager.Options{SyncPeriod: 1 * time.Hour})
- if err != nil {
- panic(err)
- }
-
- if err := crossplaneapis.AddToScheme(mgr.GetScheme()); err != nil {
- panic(err)
- }
-
- if err := fcpapis.AddToScheme(mgr.GetScheme()); err != nil {
- panic(err)
- }
-
- if err := controller.SetupWithManager(mgr); err != nil {
- panic(err)
- }
-
- panic(mgr.Start(signals.SetupSignalHandler()))
-}
-```
-
-## In Review
-
-In this guide we walked through the process of defining the resource kinds and
-controllers necessary to build support for new managed infrastructure; possibly
-even a completely new infrastructure provider. Please do not hesitate to [reach
-out] to the Crossplane maintainers and community for help designing and
-implementing support for new managed services. We would highly value any
-feedback you may have about the development process!
-
-
-
-[What Makes a Crossplane Managed Service]: #what-makes-a-crossplane-managed-service
-[managed resource]: concepts.md#managed-resource
-[dynamic provisioning]: concepts.md#dynamic-and-static-provisioning
-[`CloudMemorystoreInstance`]: https://github.com/crossplane/provider-gcp/blob/85a6ed3c669a021f1d61be51b2cbe2714b0bc70b/apis/cache/v1beta1/cloudmemorystore_instance_types.go#L184
-[`Provider`]: https://github.com/crossplane/provider-gcp/blob/85a6ed3c669a021f1d61be51b2cbe2714b0bc70b/apis/v1alpha3/types.go#L41
-[watching the API server]: https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
-[controller-runtime]: https://github.com/kubernetes-sigs/controller-runtime
-[crossplane-runtime]: https://github.com/crossplane/crossplane-runtime/
-[crossplane-runtime v0.9.0]: https://github.com/crossplane/crossplane-runtime/releases/tag/v0.9.0
-[golden path]: https://charity.wtf/2018/12/02/software-sprawl-the-golden-path-and-scaling-teams-with-agency/
-[API Conventions]: https://github.com/kubernetes/community/blob/c6e1e89a/contributors/devel/sig-architecture/api-conventions.md
-[kubebuilder book]: https://book.kubebuilder.io/
-[resources]: https://kubebuilder.io/cronjob-tutorial/gvks.html#kinds-and-resources
-[kinds]: https://kubebuilder.io/cronjob-tutorial/gvks.html#kinds-and-resources
-[objects]: https://kubernetes.io/docs/concepts/#kubernetes-objects
-[comment marker]: https://kubebuilder.io/reference/markers.html
-[comment markers]: https://kubebuilder.io/reference/markers.html
-[`resource.Managed`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/resource#Managed
-[`managed.Reconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#Reconciler
-[`managed.NewReconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#NewReconciler
-[`managed.ExternalConnecter`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalConnecter
-[`managed.ExternalClient`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalClient
-[`ResourceSpec`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ResourceSpec
-[`ResourceStatus`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ResourceStatus
-[`ProviderSpec`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ProviderSpec
-['managed.ExternalConnecter`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalConnecter
-[opening a Crossplane issue]: https://github.com/crossplane/crossplane/issues/new/choose
-[`GroupVersionKind`]: https://godoc.org/k8s.io/apimachinery/pkg/runtime/schema#GroupVersionKind
-[`reconcile.Reconciler`]: https://godoc.org/sigs.k8s.io/controller-runtime/pkg/reconcile#Reconciler
-[favor]: https://github.com/crossplane/crossplane/issues/452
-[reach out]: https://github.com/crossplane/crossplane#get-involved
-[crossplane org]: https://github.com/crossplane
-[`angryjet`]: https://github.com/crossplane/crossplane-tools
-[Managed Resource API Patterns]: ../design/one-pager-managed-resource-api-design.md
-[Crossplane CLI]: https://github.com/crossplane/crossplane-cli#quick-start-stacks
-[`angryjet` documentation]: https://github.com/crossplane/crossplane-tools/blob/master/README.md
diff --git a/docs/v0.11/faqs/faqs.md b/docs/v0.11/faqs/faqs.md
deleted file mode 100644
index 5c749815..00000000
--- a/docs/v0.11/faqs/faqs.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: FAQ
-toc: true
-weight: 1200
----
-
-# Frequently Asked Questions (FAQs)
-
-### Where did the name Crossplane come from?
-
-Crossplane is the fusing of cross-cloud control plane. We wanted to use a noun
-that refers to the entity responsible for connecting different cloud providers
-and acts as control plane across them. Cross implies “cross-cloud” and “plane”
-brings in “control plane”.
-
-### What's up with popsicle?
-
-We believe in a multi-flavor cloud.
-
-### Related Projects
-See [Related Projects].
-
-[Related Projects]: related_projects.md
\ No newline at end of file
diff --git a/docs/v0.11/faqs/related_projects.md b/docs/v0.11/faqs/related_projects.md
deleted file mode 100644
index 28a7cb40..00000000
--- a/docs/v0.11/faqs/related_projects.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: Related Projects
-toc: true
-weight: 1201
-indent: true
----
-
-# Related Projects
-
-While there are many projects that address similar issues, none of them
-encapsulate the full use case that Crossplane addresses. This list is not
-exhaustive and is not meant to provide a deep analysis of the following
-projects, but instead to motivate why Crossplane was created.
-
-## Open Service Broker and Service Catalog
-
-The [Open Service Broker] and the [Kubernetes Service Catalog] are able to
-dynamically provision cloud services from Kubernetes. As a result it shares
-similar goals with Crossplane. However, service broker does not have the
-ability to define, compose, and publish your own infrastructure resources to
-the Kubernetes API in a no-code way. Crossplane goes further by enabling
-infrastructure operators to hide infrastructure complexity and include policy
-guardrails, with a team-centric approach and a strong separation of concerns,
-so applications can easily and safely consume the infrastructure they need,
-using any tool that works with the Kubernetes API. Solutions like the [GCP
-implementation of Open Service Broker][GCP OSB] have been deprecated in favor
-of a more Kubernetes-native solution, but one that is Google-specific and
-closed source.
-
-## GCP Config Connector
-
-The [GCP Config Connector] is the GCP replacement for Open Service Broker, and
-implements a set of Kubernetes controllers that are able to provision managed
-services in GCP. It defines a set of CRDs for managed services like CloudSQL,
-and controllers that can provision them via their cloud APIs. It is similar to
-Crossplane in that it can provision managed services in GCP. Crossplane goes
-further by enabling you to provision managed services from any cloud
-provider and the ability to define, compose, and publish your own
-infrastructure resources in a no-code way. Crossplane supports a team-centric
-approach with a strong separation of concerns, that enables applications to
-easily and safely consume the infrastructure they need, using any tool that
-works with the Kubernetes API. GCP Config Connector is closed-source.
-
-## AWS Service Operator
-
-The [AWS Service Operator] is a recent project that implements a set of
-Kubernetes controllers that are able to provision managed services in AWS. It
-defines a set of CRDs for managed services like DynamoDB, and controllers that
-can provision them via AWS CloudFormation. It is similar to Crossplane in that
-it can provision managed services in AWS. Crossplane goes further by
-enabling you to provision managed services from any cloud provider and the
-ability to define, compose, and publish your own infrastructure API types in
-Kubernetes in a no-code way. Crossplane supports a team-centric approach with a
-strong separation of concerns, that enables applications to easily and safely
-consume the infrastructure they need, using any tool that works with the
-Kubernetes API.
-
-## AWS CloudFormation, GCP Deployment Manager, and Others
-
-These products offer a declarative model for deploying and provisioning
-infrastructure in each of the respective cloud providers. They only work for
-one cloud provider, are generally closed source, and offer little or no
-extensibility points, let alone being able to extend the Kubernetes API to
-provide your own infrastructure abstractions in a no-code way. We have
-considered using some of these products as a way to implement resource
-controllers in Crossplane. These projects use an Infrastructure as Code
-approach to management, while Crossplane offers an API-driven control plane.
-
-## Terraform and Pulumi
-
-[Terraform] and [Pulumi] are tools for provisioning infrastructure across cloud
-providers. It offers a declarative configuration language with support for
-templating, composability, referential integrity and dependency management.
-Terraform can declaratively manage any compatible API and perform changes when
-the tool is run by a human or in a deployment pipeline. Terraform is an
-Infrastructure as Code tool, while Crossplane offers an API-driven control plane.
-
-
-
-[Open Service Broker]: https://www.openservicebrokerapi.org/
-[Kubernetes Service Catalog]: https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/
-[GCP OSB]: https://cloud.google.com/kubernetes-engine/docs/concepts/google-cloud-platform-service-broker
-[GCP Config Connector]: https://cloud.google.com/config-connector/docs/overview
-[AWS Service Operator]: https://github.com/awslabs/aws-service-operator
-[Terraform]: https://www.terraform.io/
-[Pulumi]: https://www.pulumi.com/
diff --git a/docs/v0.11/getting-started/install-configure.md b/docs/v0.11/getting-started/install-configure.md
deleted file mode 100644
index c8794d99..00000000
--- a/docs/v0.11/getting-started/install-configure.md
+++ /dev/null
@@ -1,395 +0,0 @@
----
-title: Install & Configure
-toc: true
-weight: 2
-indent: true
----
-
-# Install & Configure Crossplane
-
-Crossplane can be easily installed into any existing Kubernetes cluster using
-the regularly published Helm chart. The Helm chart contains all the custom
-resources and controllers needed to deploy and configure Crossplane.
-
-See [Install] and [Configure] docs for installing alternate versions and more
-detailed instructions.
-
-## Get a Kubernetes Cluster
-
-
-For macOS / Linux use the following:
-
-* [Kubernetes cluster]
- * [Kind]
- * [Minikube], minimum version `v0.28+`
- * etc.
-
-* [Helm], minimum version `v2.12.0+`.
- * For Helm 2, make sure Tiller is initialized with sufficient permissions to
- work on `crossplane-system` namespace.
-
-
-
-For Windows use the following:
-
-* [Kubernetes cluster]
- * [Kind]
- * [Minikube], minimum version `v0.28+`
- * etc.
-
-* [Helm], minimum version `v2.12.0+`.
- * For Helm 2, make sure Tiller is initialized with sufficient permissions to
- work on `crossplane-system` namespace.
-
-
-Use Helm 3 to install the latest official `alpha` release of Crossplane, suitable for community use and testing:
-
-```
-kubectl create namespace crossplane-system
-
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-
-# Kubernetes 1.15 and newer versions
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane
-
-# Kubernetes 1.14 and older versions
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane --disable-openapi-validation
-```
-
-
-
-Use Helm 2 to install the latest official `alpha` release of Crossplane, suitable for community use and testing:
-
-```
-kubectl create namespace crossplane-system
-
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-
-Use Helm 2 to install the latest `master` pre-release version of Crossplane, which is suitable for testing pre-release versions:
-
-```
-kubectl create namespace crossplane-system
-
-helm repo add crossplane-master https://charts.crossplane.io/master/
-helm search crossplane-master
-
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version
-```
-
-For example:
-
-```
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version 0.11.0-rc.100.gbc5d311
-```
-
-
-
-
-## Install Crossplane CLI
-The [Crossplane CLI] adds a set of `kubectl crossplane` commands to simplify common tasks:
-```
-curl -sL https://raw.githubusercontent.com/crossplane/crossplane-cli/master/bootstrap.sh | bash
-```
-
-## Select Provider
-Install and configure a provider for Crossplane to use for infrastructure provisioning:
-
-
-## Next Steps
-Now that you have a provider configured, you can [provision infrastructure].
-
-## More Info
-See [Install] and [Configure] docs for installing alternate versions and more
-detailed instructions.
-
-## Uninstall Provider
-```
-kubectl delete -f provider.yaml
-kubectl delete secret -n crossplane-system --all
-```
-
-## Uninstall Crossplane
-```
-helm delete crossplane --namespace crossplane-system
-```
-
-
-
-[provision infrastructure]: provision-infrastructure.md
-[Install]: ../reference/install.md
-[Configure]: ../reference/configure.md
-[Kubernetes cluster]: https://kubernetes.io/docs/setup/
-[Minikube]: https://kubernetes.io/docs/tasks/tools/install-minikube/
-[Helm]: https://docs.helm.sh/using_helm/
-[Kind]: https://kind.sigs.k8s.io/docs/user/quick-start/
-[Crossplane CLI]: https://github.com/crossplane/crossplane-cli
diff --git a/docs/v0.11/getting-started/provision-infrastructure.md b/docs/v0.11/getting-started/provision-infrastructure.md
deleted file mode 100644
index c10f3706..00000000
--- a/docs/v0.11/getting-started/provision-infrastructure.md
+++ /dev/null
@@ -1,249 +0,0 @@
----
-title: Provision Infrastructure
-toc: true
-weight: 3
-indent: true
----
-
-# Provision Infrastructure
-
-Crossplane allows you to provision infrastructure anywhere using the Kubernetes
-API. Once you have [installed a provider] and [configured your credentials], you
-can create any infrastructure resource currently supported by the provider.
-Let's start by provisioning a database on your provider of choice.
-
-Each provider below offers their own flavor of a managed database. When the
-provider is installed into your Crossplane cluster, it installs a cluster-scoped
-CRD that represents the managed service offering, as well as controllers that
-know how to create, update, and delete instances of the service on the cloud
-provider.
-
-
-
-The AWS provider supports provisioning an [RDS] instance with the `RDSInstance`
-CRD it installs into your cluster.
-
-```yaml
-apiVersion: database.aws.crossplane.io/v1beta1
-kind: RDSInstance
-metadata:
- name: rdspostgresql
-spec:
- forProvider:
- dbInstanceClass: db.t2.small
- masterUsername: masteruser
- allocatedStorage: 20
- engine: postgres
- engineVersion: "9.6"
- skipFinalSnapshotBeforeDeletion: true
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: aws-rdspostgresql-conn
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.11/docs/snippets/provision/aws.yaml
-```
-
-Creating the above instance will cause Crossplane to provision an RDS instance
-on AWS. You can view the progress with the following command:
-
-```console
-kubectl get rdsinstances.database.aws.crossplane.io rdspostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can then delete the `RDSInstance`:
-
-```console
-kubectl delete rdsinstances.database.aws.crossplane.io rdspostgresql
-```
-
-
-
-
-The GCP provider supports provisioning a [CloudSQL] instance with the
-`CloudSQLInstance` CRD it installs into your cluster.
-
-```yaml
-apiVersion: database.gcp.crossplane.io/v1beta1
-kind: CloudSQLInstance
-metadata:
- name: cloudsqlpostgresql
-spec:
- forProvider:
- databaseVersion: POSTGRES_9_6
- region: us-central1
- settings:
- tier: db-custom-1-3840
- dataDiskType: PD_SSD
- dataDiskSizeGb: 10
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: cloudsqlpostgresql-conn
- providerRef:
- name: gcp-provider
- reclaimPolicy: Delete
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.11/docs/snippets/provision/gcp.yaml
-```
-
-Creating the above instance will cause Crossplane to provision a CloudSQL
-instance on GCP. You can view the progress with the following command:
-
-```console
-kubectl get cloudsqlinstances.database.gcp.crossplane.io cloudsqlpostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can then delete the `CloudSQLInstance`:
-
-```console
-kubectl delete cloudsqlinstances.database.gcp.crossplane.io cloudsqlpostgresql
-```
-
-
-
-
-The Azure provider supports provisioning an [Azure Database for PostgreSQL]
-instance with the `PostgreSQLServer` CRD it installs into your cluster.
-
-> Note: provisioning an Azure Database for PostgreSQL requires the presence of a
-> [Resource Group] in your Azure account. We go ahead and provision a new
-> `ResourceGroup` here in case you do not already have a suitable one in your
-> account.
-
-```yaml
-apiVersion: azure.crossplane.io/v1alpha3
-kind: ResourceGroup
-metadata:
- name: sqlserverpostgresql-rg
-spec:
- location: West US 2
- reclaimPolicy: Delete
- providerRef:
- name: azure-provider
----
-apiVersion: database.azure.crossplane.io/v1beta1
-kind: PostgreSQLServer
-metadata:
- name: sqlserverpostgresql
-spec:
- forProvider:
- administratorLogin: myadmin
- resourceGroupNameRef:
- name: sqlserverpostgresql-rg
- location: West US 2
- sslEnforcement: Disabled
- version: "9.6"
- sku:
- tier: GeneralPurpose
- capacity: 2
- family: Gen5
- storageProfile:
- storageMB: 20480
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: sqlserverpostgresql-conn
- providerRef:
- name: azure-provider
- reclaimPolicy: Delete
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.11/docs/snippets/provision/azure.yaml
-```
-
-Creating the above instance will cause Crossplane to provision a PostgreSQL
-database instance on Azure. You can view the progress with the following
-command:
-
-```console
-kubectl get postgresqlservers.database.azure.crossplane.io sqlserverpostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can then delete the `PostgreSQLServer`:
-
-```console
-kubectl delete postgresqlservers.database.azure.crossplane.io sqlserverpostgresql
-kubectl delete resourcegroup.azure.crossplane.io sqlserverpostgresql-rg
-```
-
-
-
-
-The Alibaba provider supports provisioning an [ApsaraDB for RDS] instance with
-the `RDSInstance` CRD it installs into your cluster.
-
-```yaml
-apiVersion: database.alibaba.crossplane.io/v1alpha1
-kind: RDSInstance
-metadata:
- name: rdspostgresql
-spec:
- forProvider:
- engine: PostgreSQL
- engineVersion: "9.4"
- dbInstanceClass: rds.pg.s1.small
- dbInstanceStorageInGB: 20
- securityIPList: "0.0.0.0/0"
- masterUsername: "test123"
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: alibaba-rdspostgresql-conn
- providerRef:
- name: alibaba-provider
- reclaimPolicy: Delete
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.11/docs/snippets/provision/alibaba.yaml
-```
-
-Creating the above instance will cause Crossplane to provision an RDS instance
-on Alibaba. You can view the progress with the following command:
-
-```console
-kubectl get rdsinstances.database.alibaba.crossplane.io rdspostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can then delete the `RDSInstance`:
-
-```console
-kubectl delete rdsinstances.database.alibaba.crossplane.io rdspostgresql
-```
-
-
-
-
-## Next Steps
-
-Now that you have seen how to provision individual infrastructure resources,
-let's take a look at how we can compose infrastructure resources together and
-publish them as a single unit to be consumed in the [next section].
-
-
-
-[installed a provider]: install-configure.md
-[configured your credentials]: install-configure.md
-[RDS]: https://aws.amazon.com/rds/
-[CloudSQL]: https://cloud.google.com/sql
-[Azure Database for PostgreSQL]: https://azure.microsoft.com/en-us/services/postgresql/
-[Resource Group]: https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal#what-is-a-resource-group
-[ApsaraDB for RDS]: https://www.alibabacloud.com/product/apsaradb-for-rds-postgresql
-[next section]: publish-infrastructure.md
diff --git a/docs/v0.11/getting-started/publish-infrastructure.md b/docs/v0.11/getting-started/publish-infrastructure.md
deleted file mode 100644
index a07931f4..00000000
--- a/docs/v0.11/getting-started/publish-infrastructure.md
+++ /dev/null
@@ -1,824 +0,0 @@
----
-title: Publish Infrastructure
-toc: true
-weight: 4
-indent: true
----
-
-# Publish Infrastructure
-
-Provisioning infrastructure using the Kubernetes API is a powerful capability,
-but combining primitive infrastructure resources into a single unit and
-publishing them to be provisioned by developers and consumed by applications
-greatly enhances this functionality.
-
-As mentioned in the [last section], CRDs that represent infrastructure resources
-on a provider are installed at the *cluster scope*. However, applications are
-typically provisioned at the *namespace scope* using Kubernetes primitives such
-as `Pod` or `Deployment`. To make infrastructure resources available to be
-provisioned at the namespace scope, they can be *published*. This consists of
-creating the following resources:
-
-- `InfrastructureDefinition`: defines a new kind of composite resource
-- `InfrastructurePublication`: makes an `InfrastructureDefinition` available at
- the namespace scope
-- `Composition`: defines one or more resources and their configuration
-
-In addition to making provisioning available at the namespace scope,
-[composition] also allows for multiple types of managed resources to satisfy the
-same namespace-scoped resource. In the examples below, we will define and
-publish a new `PostgreSQLInstance` resource that only takes a single `storageGB`
-parameter, and specifies that it will create a connection `Secret` with keys for
-`username`, `password`, and `endpoint`. We will then create a `Composition` for
-each provider that can satisfy and be parameterized by a `PostgreSQLInstance`.
-Let's get started!
-
-> Note: Crossplane must be granted RBAC permissions to managed new
-> infrastructure types that we define. This is covered in greater detail in the
-> [composition] section, but you can run the following command to grant all
-> necessary RBAC permissions for this quick start guide: `kubectl apply -f
-> https://raw.githubusercontent.com/crossplane/crossplane/release-0.11/docs/snippets/publish/clusterrole.yaml`
-
-## Create InfrastructureDefinition
-
-The next step is defining an `InfrastructureDefinition` that declares the schema
-for a `PostgreSQLInstance`. You will notice that this looks very similar to a CRD,
-and after the `InfrastructureDefinition` is created, we will in fact have a
-`PostgreSQLInstance` CRD present in our cluster.
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: InfrastructureDefinition
-metadata:
- name: postgresqlinstances.database.example.org
-spec:
- connectionSecretKeys:
- - username
- - password
- - endpoint
- - port
- crdSpecTemplate:
- group: database.example.org
- version: v1alpha1
- names:
- kind: PostgreSQLInstance
- listKind: PostgreSQLInstanceList
- plural: postgresqlinstances
- singular: postgresqlinstance
- validation:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- parameters:
- type: object
- properties:
- storageGB:
- type: integer
- required:
- - storageGB
- required:
- - parameters
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.11/docs/snippets/publish/definition.yaml
-```
-
-You are now able to create instances of kind `PostgreSQLInstance` at the cluster
-scope.
-
-## Create InfrastructurePublication
-
-The `InfrastructureDefinition` will make it possible to create
-`PostgreSQLInstance` objects in our Kubernetes cluster at the cluster scope, but
-we want to make them available at the namespace scope as well. This is done by
-defining an `InfrastructurePublication` that references the new
-`PostgreSQLInstance` type.
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: InfrastructurePublication
-metadata:
- name: postgresqlinstances.database.example.org
-spec:
- infrastructureDefinitionRef:
- name: postgresqlinstances.database.example.org
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.11/docs/snippets/publish/publication.yaml
-```
-
-This will create a new CRD named `PostgreSQLInstanceRequirement`, which is the
-namespace-scoped variant of the `PostgreSQLInstance` CRD. You are now able to
-create instances of kind `PostgreSQLInstanceRequirement` at the namespace scope.
-
-## Create Compositions
-
-Now it is time to define the resources that represent the primitive
-infrastructure units that actually get provisioned. For each provider we will
-define a `Composition` that satisfies the requirements of the
-`PostgreSQLInstance` `InfrastructureDefinition`. In this case, each will result
-in the provisioning of a public PostgreSQL instance on the provider.
-
-
-
-## Create Requirement
-
-Now that we have defined our new type of infrastructure (`PostgreSQLInstance`)
-and created at least one composition that can satisfy it, we can create a
-`PostgreSQLInstanceRequirement` in the namespace of our choosing. In each
-`Composition` we defined we added a `provider: ` label. In the
-`PostgreSQLInstanceRequirement` below we can use the `compositionSelector` to
-match our `Composition` of choice.
-
-
-
-After creating the `PostgreSQLInstanceRequirement` Crossplane will provision a
-database instance on your provider of choice. Once provisioning is complete, you
-should see `READY: True` in the output when you run:
-
-```console
-kubectl get postgresqlinstancerequirement.database.example.org my-db
-```
-
-> Note: while waiting for the `PostgreSQLInstanceRequirement` to become ready, you
-> may want to look at other resources in your cluser. The following commands
-> will allow you to view groups of Crossplane resources:
->
-> - `kubectl get managed`: get all resources that represent a unit of external
-> infrastructure
-> - `kubectl get `: get all resources related to ``
-> - `kubectl get crossplane`: get all resources related to Crossplane
-
-You should also see a `Secret` in the `default` namespace named `db-conn` that
-contains fields for `username`, `password`, and `endpoint`:
-
-```console
-kubectl get secrets db-conn
-```
-
-## Consume Infrastructure
-
-Because connection secrets are written as a Kubernetes `Secret` they can easily
-be consumed by Kubernetes primitives. The most basic building block in
-Kubernetes is the `Pod`. Let's define a `Pod` that will show that we are able to
-connect to our newly provisioned database.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: see-db
- namespace: default
-spec:
- containers:
- - name: see-db
- image: postgres:9.6
- command: ['psql']
- args: ['-c', 'SELECT current_database();']
- env:
- - name: PGDATABASE
- value: postgres
- - name: PGHOST
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: endpoint
- - name: PGUSER
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: username
- - name: PGPASSWORD
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: password
- - name: PGPORT
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: port
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.11/docs/snippets/publish/pod.yaml
-```
-
-This `Pod` simply connects to a PostgreSQL database and prints its name, so you
-should see the following output (or similar) after creating it if you run
-`kubectl logs see-db`:
-
-```SQL
- current_database
-------------------
- postgres
-(1 row)
-```
-
-## Clean Up
-
-To clean up the infrastructure that was provisioned, you can delete the
-`PostgreSQLInstanceRequirement`:
-
-```console
-kubectl delete postgresqlinstancerequirement.database.example.org my-db
-```
-
-To clean up the `Pod`, run:
-
-```console
-kubectl delete pod see-db
-```
-
-> Don't clean up your `InfrastructureDefinition`, `InfrastructurePublication`,
-> or `Composition` just yet if you plan to continue on to the next section of
-> the guide! We'll use them again when we deploy an OAM application.
-
-## Next Steps
-
-Now you have seen how to provision and publish more complex infrastructure
-setups. In the [next section] you will learn how to consume infrastructure
-alongside your [OAM] application manifests.
-
-
-
-[last section]: provision-infrastructure.yaml
-[composition]: ../introduction/composition.md
-[next section]: run-applications.md
-[OAM]: https://oam.dev/
diff --git a/docs/v0.11/getting-started/run-applications-dash.png b/docs/v0.11/getting-started/run-applications-dash.png
deleted file mode 100644
index 5390190b..00000000
Binary files a/docs/v0.11/getting-started/run-applications-dash.png and /dev/null differ
diff --git a/docs/v0.11/getting-started/run-applications-diagram.jpg b/docs/v0.11/getting-started/run-applications-diagram.jpg
deleted file mode 100644
index 16037640..00000000
Binary files a/docs/v0.11/getting-started/run-applications-diagram.jpg and /dev/null differ
diff --git a/docs/v0.11/getting-started/run-applications-flights.png b/docs/v0.11/getting-started/run-applications-flights.png
deleted file mode 100644
index c7d3b8d0..00000000
Binary files a/docs/v0.11/getting-started/run-applications-flights.png and /dev/null differ
diff --git a/docs/v0.11/getting-started/run-applications.md b/docs/v0.11/getting-started/run-applications.md
deleted file mode 100644
index eee0cba0..00000000
--- a/docs/v0.11/getting-started/run-applications.md
+++ /dev/null
@@ -1,505 +0,0 @@
----
-title: Run Applications
-toc: true
-weight: 5
-indent: true
----
-
-# Run Applications
-
-Crossplane strives to be the best Kubernetes add-on to provision and manage the
-infrastructure and services your applications need directly from kubectl. A huge
-part of this mission is arriving at an elegant, flexible way to model and manage
-cloud native applications. Crossplane allows your team to deploy and run
-applications using the [Open Application Model] (OAM).
-
-OAM is a team-centric model for cloud native apps. Like Crossplane, OAM focuses
-on the different people who might be involved in the deployment of a cloud
-native application. In this getting started guide:
-
-* _Infrastructure Operators_ provide the infrastructure applications need.
-* _Application Developers_ build and supply the components of an application.
-* _Application Operators_ compose, deploy, and run application configurations.
-
-We'll play the roles of each of these team members as we deploy an application -
-Service Tracker - that consists of several services. One of these services, the
-`data-api`, is backed by a managed PostgreSQL database that is provisioned
-on-demand by Crossplane.
-
-![Service Tracker Diagram]
-
-> This guide follows on from the previous one in which we covered defining,
-> composing, and [publishing infrastructure]. You'll need to have defined and
-> published a PostgreSQLInstance with at least one working Composition in order
-> to create the OAM application we'll use in this guide.
-
-## Infrastructure Operator
-
-### Install workloads and traits
-
-As the infrastructure operator our work is almost done - we defined, published,
-and composed the infrastructure that our application developer and operator
-teammates will use in the previous guide. One task remains, which is to define
-the [_workloads_] and [_traits_] that our platform supports.
-
-OAM applications consist of workloads, each of which may be modified by traits.
-The infrastructure operator may choose which workloads and traits by creating
-or deleting `WorkloadDefinitions` and `TraitDefinitions` like below:
-
-```yaml
----
-apiVersion: core.oam.dev/v1alpha2
-kind: WorkloadDefinition
-metadata:
- name: containerizedworkloads.core.oam.dev
-spec:
- definitionRef:
- name: containerizedworkloads.core.oam.dev
-```
-
-Run the following command to add support for all the workloads and traits required
-by this guide:
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.11/docs/snippets/run/definitions.yaml
-```
-
-Now that we've defined our workloads and traits, we must install Crossplane's
-OAM addon. This addon packages the controllers that reconcile core OAM workloads
-and traits.
-
-
-Use Helm 3 to install the latest official `alpha` release of Crossplane OAM
-Addon, suitable for community use and testing:
-
-```console
-kubectl create namespace crossplane-system
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install addon-oam-kubernetes-local --namespace crossplane-system crossplane-alpha/oam-core-resources
-```
-
-> Note that the OAM Addon requires at least Kubernetes 1.16.
-
-
-
-Use Helm 2 to install the latest official `alpha` release of the Crossplane OAM
-Addon, suitable for community use and testing:
-
-```console
-kubectl create namespace crossplane-system
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name addon-oam-kubernetes-local --namespace crossplane-system crossplane-alpha/oam-core-resources
-```
-
-> Note that the OAM Addon requires at least Kubernetes 1.16.
-
-
-
-
-## Application Developer
-
-### Publish Application Components
-
-Now we'll play the role of the application developer. Our Service Tracker
-application consists of a UI service, four API services, and a PostgreSQL
-database. Under the Open Application Model application developers define
-[_components_] that application operators may compose into applications, which
-produce workloads. Creating components allows us as application developers to
-communicate any fundamental, suggested, or optional properties of our services
-and their infrastructure requirements.
-
-```yaml
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: data-api-database
-spec:
- workload:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstanceRequirement
- metadata:
- name: app-postgresql
- spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- guide: quickstart
- parameters:
- - name: database-secret
- description: Secret to which to write PostgreSQL database connection details.
- required: true
- fieldPaths:
- - spec.writeConnectionSecretToRef.name
- - name: database-provider
- description: |
- Cloud provider that should be used to create a PostgreSQL database.
- Either alibaba, aws, azure, or gcp.
- fieldPaths:
- - spec.compositionSelector.matchLabels.provider
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: data-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: data-api
- spec:
- containers:
- - name: data-api
- image: artursouza/rudr-data-api:0.50
- env:
- - name: DATABASE_USER
- fromSecret:
- key: username
- - name: DATABASE_PASSWORD
- fromSecret:
- key: password
- - name: DATABASE_HOSTNAME
- fromSecret:
- key: endpoint
- - name: DATABASE_PORT
- fromSecret:
- key: port
- - name: DATABASE_NAME
- value: postgres
- - name: DATABASE_DRIVER
- value: postgresql
- ports:
- - name: http
- containerPort: 3009
- protocol: TCP
- livenessProbe:
- exec:
- command: [wget, -q, http://127.0.0.1:3009/status, -O, /dev/null, -S]
- parameters:
- - name: database-secret
- description: Secret from which to read PostgreSQL connection details.
- required: true
- fieldPaths:
- - spec.containers[0].env[0].fromSecret.name
- - spec.containers[0].env[1].fromSecret.name
- - spec.containers[0].env[2].fromSecret.name
- - spec.containers[0].env[3].fromSecret.name
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: flights-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: flights-api
- spec:
- containers:
- - name: flights-api
- image: sonofjorel/rudr-flights-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3003
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: quakes-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: quakes-api
- spec:
- containers:
- - name: quakes-api
- image: sonofjorel/rudr-quakes-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3012
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: service-tracker-ui
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: web-ui
- spec:
- containers:
- - name: service-tracker-ui
- image: sonofjorel/rudr-web-ui:0.49
- env:
- - name: FLIGHT_API_ROOT
- - name: WEATHER_API_ROOT
- - name: QUAKES_API_ROOT
- ports:
- - name: http
- containerPort: 8080
- protocol: TCP
- parameters:
- - name: flights-uri
- description: URI at which the flights service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
- - name: weather-uri
- description: URI at which the weather service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[1].value
- - name: quakes-uri
- description: URI at which the quakes service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[2].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: weather-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: weather-api
- spec:
- containers:
- - name: weather-api
- image: sonofjorel/rudr-weather-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3015
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.11/docs/snippets/run/components.yaml
-```
-
-Each of the above components describes a particular kind of workload. The
-Service Tracker application consists of two kinds of workload:
-
-* A [`ContainerizedWorkload`] is a long-running containerized process.
-* A `PostSQLInstanceRequirement` is a PostgreSQL instance and database.
-
-All OAM components configure a kind of workload, and any kind of Kubernetes
-resource may act as an OAM workload as long as an infrastructure operator has
-allowed it to by authoring a `WorkloadDefinition`.
-
-## Application Operator
-
-### Run The Application
-
-Finally, we'll play the role of an application operator and tie together the
-application components and infrastructure that our application developer and
-infrastructure operator team-mates have published. In OAM this is done by
-authoring an [_application configuration_]:
-
-```yaml
-apiVersion: core.oam.dev/v1alpha2
-kind: ApplicationConfiguration
-metadata:
- name: service-tracker
-spec:
- components:
- - componentName: data-api-database
- parameterValues:
- - name: database-secret
- value: tracker-database-secret
- - componentName: data-api
- parameterValues:
- - name: database-secret
- value: tracker-database-secret
- - componentName: flights-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: flights-api
- spec:
- replicaCount: 2
- - componentName: quakes-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: quakes-api
- spec:
- replicaCount: 2
- - componentName: weather-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: weather-api
- spec:
- replicaCount: 2
- - componentName: service-tracker-ui
- parameterValues:
- - name: flights-uri
- value: "http://flights-api.default.svc.cluster.local:3003/"
- - name: weather-uri
- value: "http://weather-api.default.svc.cluster.local:3015/"
- - name: quakes-uri
- value: "http://quakes-api.default.svc.cluster.local:3012/"
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.11/docs/snippets/run/appconfig.yaml
-```
-
-This application configuration names each of components the application
-developer created earlier to produce workloads. The application operator may (or
-in some cases _must_) provide parameter values for a component in order to
-override or specify certain configuration values. Component parameters represent
-configuration settings that the component author - the application developer -
-deemed to be of interest to application operators.
-
-```yaml
-- componentName: data-api-database
- parameterValues:
- - name: database-provider
- value: azure
-```
-
-> If you created Compositions for more than one provider in the previous guide
-> you can add the above parameter to the `data-api-database` component to choose
-> which cloud provider the Service Tracker's database should run on.
-
-You might notice that some components include a [`ManualScalerTrait`]. Traits
-augment the workload produced by a component with additional features, allowing
-application operators to make decisions about the configuration of a component
-without having to involve the developer. The `ManualScalerTrait` allows an
-application operator to specify how many replicas should exist of any scalable
-kind of workload.
-
-> Note that the OAM spec also includes the concept of an _application scope_.
-> Crossplane does not yet support scopes.
-
-## Use The Application
-
-Finally, we'll open and use the Service Tracker application we just deployed.
-
-
-
-If you deployed Service Tracker to a managed cluster like AKS, ACK, EKS, or GKE
-with support for load balancer Services you should be able to browse to the IP
-of the `web-ui` service on port 8080 - for example .
-
-```console
-kubectl get svc web-ui -o=jsonpath={.status.loadBalancer.ingress[0].ip}
-```
-
-
-
-
-If you're using a cluster that doesn't support load balancer Services, like Kind
-or Minikube you can use a port forward instead, and connect to
-
-
-```console
-kubectl port-forward deployment/web-ui 8080
-```
-
-
-
-
-You should see the Service Tracker dashboard in your browser. Hit 'Refresh Data'
-for each of the services to ensure the Service Tracker web UI can connect to its
-various data API services and populate its PostgreSQL database:
-
-![Service Tracker Dashboard]
-
-If everything was successful you should be able to browse to Flights,
-Earthquakes, or Weather to see what's going on in the world today:
-
-![Service Tracker Flights]
-
-## Clean Up
-
-To shut down your application, simply run:
-
-```console
-kubectl delete applicationconfiguration service-tracker
-```
-
-If you also wish to delete the components, workload definitions, and trait
-definitions we created in this guide, run:
-
-```console
-kubectl delete -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.11/docs/snippets/run/components.yaml
-kubectl delete -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.11/docs/snippets/run/definitions.yaml
-```
-
-[Open Application Model]: https://oam.dev/
-[publishing infrastructure]: publish-infrastructure.md
-[Service Tracker Diagram]: run-applications-diagram.jpg
-[_workloads_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/3.workload.md
-[_traits_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/6.traits.md
-[_components_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/4.component.md
-[_application configuration_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/7.application_configuration.md
-[`ContainerizedWorkload`]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/core/workloads/containerized_workload/containerized_workload.md
-[`ManualScalerTrait`]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/core/traits/manual_scaler_trait.md
-[_application scope_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/5.application_scopes.md
-[Service Tracker Dashboard]: run-applications-dash.png
-[Service Tracker Flights]: run-applications-flights.png
diff --git a/docs/v0.11/guides/argocd.md b/docs/v0.11/guides/argocd.md
deleted file mode 100644
index 10fa909d..00000000
--- a/docs/v0.11/guides/argocd.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Argo CD
-toc: true
-weight: 201
-indent: true
-redirect_to: https://aws.amazon.com/blogs/opensource/connecting-aws-managed-services-to-your-argo-cd-pipeline-with-open-source-crossplane/
----
\ No newline at end of file
diff --git a/docs/v0.11/guides/guides.md b/docs/v0.11/guides/guides.md
deleted file mode 100644
index e92918bb..00000000
--- a/docs/v0.11/guides/guides.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: Guides
-toc: true
-weight: 200
----
-
-# Guides
-
-Because of Crossplane's standardization on the Kubernetes API, it integrates
-well with many other projects. Below is a collection of guides and tutorials that
-demonstrate how to use Crossplane with a variety tools and projects often used
-with Kubernetes plus some deep dive content on Crossplane itself!
-
-- [Argo CD] - use GitOps to provision managed services with Crossplane and Argo CD.
-- [Knative] - use managed services provisioned by Crossplane in your Knative services.
-- [Okteto] - use managed services in your Okteto development workflow.
-- [Open Policy Agent] - set global policy on provisioning cloud resources with Crossplane and OPA.
-- [OpenFaaS] - consume managed services with for your serverless functions.
-- [Provider Internals] - translate provider APIs into managed resource CRDs and explore managed resource API patterns & best practices.
-- [Velero] - backup and restore your Crossplane infrastructure resources.
-
-
-
-[Velero]: https://www.youtube.com/watch?v=eV_2QoMRqGw&list=PL510POnNVaaYFuK-B_SIUrpIonCtLVOzT&index=18&t=183s
-[Argo CD]: https://aws.amazon.com/blogs/opensource/connecting-aws-managed-services-to-your-argo-cd-pipeline-with-open-source-crossplane/
-[Open Policy Agent]: https://github.com/crossplane/tbs/tree/master/episodes/14
-[Knative]: https://github.com/crossplane/tbs/tree/master/episodes/15
-[OpenFaaS]: https://github.com/crossplane/tbs/tree/master/episodes/13
-[Okteto]: https://github.com/crossplane/tbs/tree/master/episodes/10
-[Provider Internals]: https://github.com/crossplane/tbs/tree/master/episodes/7
\ No newline at end of file
diff --git a/docs/v0.11/guides/knative.md b/docs/v0.11/guides/knative.md
deleted file mode 100644
index 6dfd0f2b..00000000
--- a/docs/v0.11/guides/knative.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Knative
-toc: true
-weight: 202
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/15
----
\ No newline at end of file
diff --git a/docs/v0.11/guides/okteto.md b/docs/v0.11/guides/okteto.md
deleted file mode 100644
index 85c250ca..00000000
--- a/docs/v0.11/guides/okteto.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Okteto
-toc: true
-weight: 203
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/10
----
\ No newline at end of file
diff --git a/docs/v0.11/guides/opa.md b/docs/v0.11/guides/opa.md
deleted file mode 100644
index 971446cb..00000000
--- a/docs/v0.11/guides/opa.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Open Policy Agent
-toc: true
-weight: 204
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/14
----
\ No newline at end of file
diff --git a/docs/v0.11/guides/openfaas.md b/docs/v0.11/guides/openfaas.md
deleted file mode 100644
index dad6f2cb..00000000
--- a/docs/v0.11/guides/openfaas.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: OpenFaaS
-toc: true
-weight: 205
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/13
----
\ No newline at end of file
diff --git a/docs/v0.11/guides/provider-internals.md b/docs/v0.11/guides/provider-internals.md
deleted file mode 100644
index 1e201d01..00000000
--- a/docs/v0.11/guides/provider-internals.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Provider Internals
-toc: true
-weight: 206
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/7
----
\ No newline at end of file
diff --git a/docs/v0.11/guides/velero.md b/docs/v0.11/guides/velero.md
deleted file mode 100644
index 79fc1fc6..00000000
--- a/docs/v0.11/guides/velero.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Velero
-toc: true
-weight: 207
-indent: true
-redirect_to: https://www.youtube.com/watch?v=eV_2QoMRqGw&list=PL510POnNVaaYFuK-B_SIUrpIonCtLVOzT&index=18&t=183s
----
\ No newline at end of file
diff --git a/docs/v0.11/introduction/composition-concepts.png b/docs/v0.11/introduction/composition-concepts.png
deleted file mode 100644
index a2d684e4..00000000
Binary files a/docs/v0.11/introduction/composition-concepts.png and /dev/null differ
diff --git a/docs/v0.11/introduction/composition-provisioning.png b/docs/v0.11/introduction/composition-provisioning.png
deleted file mode 100644
index db664080..00000000
Binary files a/docs/v0.11/introduction/composition-provisioning.png and /dev/null differ
diff --git a/docs/v0.11/introduction/composition.md b/docs/v0.11/introduction/composition.md
deleted file mode 100644
index f821fdd4..00000000
--- a/docs/v0.11/introduction/composition.md
+++ /dev/null
@@ -1,898 +0,0 @@
----
-title: Publishing Infrastructure
-toc: true
-weight: 103
-indent: true
----
-
-# Publishing Infrastructure
-
-Crossplane allows infrastructure operators to define and compose new kinds of
-infrastructure resources then publish them for the application operators they
-support to use, all without writing any code.
-
-Infrastructure providers extend Crossplane, enabling it to manage a wide array
-of infrastructure resources like Azure SQL servers and AWS ElastiCache clusters.
-Infrastructure composition allows infrastructure operators to define, share, and
-reuse new kinds of infrastructure resources that are _composed_ of these
-infrastructure resources. Infrastructure operators may configure one or more
-compositions of any defined resource, and may publish any defined resource to
-their application operators, who may then declare that their application
-requires that kind of resource.
-
-Composition can be used to build a catalogue of kinds and configuration classes
-of infrastructure that fit the needs and opinions of your organisation. As an
-infrastructure operator you might define your own `MySQLInstance` resource. This
-resource would allow your application operators to configure only the settings
-that _your_ organisation needs - perhaps engine version and storage size. All
-other settings are deferred to a selectable composition representing a
-configuration class like "production" or "staging". Compositions can hide
-infrastructure complexity and include policy guardrails so that applications can
-easily and safely consume the infrastructure they need, while conforming to your
-organisational best-practices.
-
-> Note that composition is an **experimental** feature of Crossplane. Refer to
-> [Current Limitations] for information on functionality that is planned but not
-> yet implemented.
-
-## Concepts
-
-![Infrastructure Composition Concepts]
-
-A _Composite_ infrastructure resource is composed of other resources. Its
-configuration schema is user-defined. The `MySQLInstance` resources in the above
-diagram are composite infrastructure resources.
-
-A `Composition` specifies how Crossplane should reconcile a composite
-infrastructure resource - i.e. what infrastructure resources it should compose.
-For example the Azure `Composition` configures Crossplane to reconcile a
-`MySQLInstance` with an Azure `MySQLServer` and a `MySQLServerFirewallRule`.
-
-A _Requirement_ for an infrastructure resource declares that an application
-requires a particular kind of composite infrastructure resource, as well as
-specifying how to configure that resource. The `MySQLInstanceRequirement`
-resources in the above diagram declare that the application pods each require a
-`MySQLInstance`.
-
-An `InfrastructureDefinition` defines a new kind of composite infrastructure
-resource. The `InfrastructureDefinition` in the above diagram defines the
-existence and schema of the `MySQLInstance` composite infrastructure resource.
-
-An `InfrastructurePublication` publishes a defined composite infrastructure
-resource, allowing application operators to declare a requirement for it. The
-`InfrastructurePublication` in the above diagram allows application operators to
-author a `MySQLInstanceRequirement`.
-
-> Note that composite resources and compositions are _cluster scoped_ - they
-> exist outside of any Kubernetes namespace. A requirement is a namespaced proxy
-> for a composite resource. This enables an RBAC model under which application
-> operators may only interact with infrastructure via requirements.
-
-## Defining and Publishing Infrastructure
-
-New kinds of infrastructure resource are typically defined and published by an
-infrastructure operator. There are three steps to this process:
-
-1. Define your resource and its schema.
-1. Specify one or more possible ways your resource may be composed.
-1. Optionally, publish your resource so that applications may require it.
-
-### Define your Infrastructure Resource
-
-Infrastructure resources are defined by an `InfrastructureDefinition`:
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: InfrastructureDefinition
-metadata:
- # InfrastructureDefinitions follow the constraints of CustomResourceDefinition
- # names. They must be named ., per the plural and group names
- # configured by the crdSpecTemplate below.
- name: mysqlinstances.example.org
-spec:
- # Composite infrastructure resources may optionally expose a connection secret
- # - a Kubernetes Secret containing all of the details a pod might need to
- # connect to the infrastructure resource. Resources that wish to expose a
- # connection secret must declare what keys they support. These keys form a
- # 'contract' - any composition that intends to be compatible with this
- # infrastructure resource must compose resources that supply these connection
- # secret keys.
- connectionSecretKeys:
- - username
- - password
- - hostname
- - port
- # A template for the spec of a CustomResourceDefinition. Only the group,
- # version, names, validation, and additionalPrinterColumns fields of a CRD
- # spec are supported.
- crdSpecTemplate:
- group: example.org
- version: v1alpha1
- names:
- kind: MySQLInstance
- listKind: MySQLInstanceList
- plural: mysqlinstances
- singular: mysqlinstance
- validation:
- # This schema defines the configuration fields that the composite resource
- # supports. It uses the same structural OpenAPI schema as a Kubernetes CRD
- # - for example, this resource supports a spec.parameters.version enum.
- # The following fields are reserved for Crossplane's use, and will be
- # overwritten if included in this validation schema:
- #
- # - soec.resourceRef
- # - spec.resourceRefs
- # - spec.requirementRef
- # - spec.writeConnectionSecretToRef
- # - spec.reclaimPolicy
- # - status.conditions
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- parameters:
- type: object
- properties:
- version:
- description: MySQL engine version
- type: string
- enum: ["5.6", "5.7"]
- storageGB:
- type: integer
- location:
- description: Geographic location of this MySQL server.
- type: string
- required:
- - version
- - storageGB
- - location
- required:
- - parameters
-```
-
-Refer to the Kubernetes documentation on [structural schemas] for full details
-on how to configure the `openAPIV3Schema` for your composite resource.
-
-`kubectl describe` can be used to confirm that a new composite infrastructure
-resource was successfully defined. Note the `Established` condition and events,
-which indicate the process was successful.
-
-```console
-$ kubectl describe infrastructuredefinition mysqlinstances.example.org
-
-Name: mysqlinstances.example.org
-Namespace:
-Labels:
-Annotations: API Version: apiextensions.crossplane.io/v1alpha1
-Kind: InfrastructureDefinition
-Metadata:
- Creation Timestamp: 2020-05-15T05:30:44Z
- Finalizers:
- finalizer.apiextensions.crossplane.io
- published.apiextensions.crossplane.io
- Generation: 1
- Resource Version: 1418120
- Self Link: /apis/apiextensions.crossplane.io/v1alpha1/infrastructuredefinitions/mysqlinstances.example.org
- UID: f8fedfaf-4dfd-4b8a-8228-6af0f4abd7a0
-Spec:
- Connection Secret Keys:
- username
- password
- hostname
- port
- Crd Spec Template:
- Group: example.org
- Names:
- Kind: MySQLInstance
- List Kind: MySQLInstanceList
- Plural: mysqlinstances
- Singular: mysqlinstance
- Validation:
- openAPIV3Schema:
- Properties:
- Spec:
- Parameters:
- Properties:
- Location:
- Description: Geographic location of this MySQL server.
- Type: string
- Storage GB:
- Type: integer
- Version:
- Description: MySQL engine version
- Enum:
- 5.6
- 5.7
- Type: string
- Required:
- version
- storageGB
- location
- Type: object
- Required:
- parameters
- Type: object
- Type: object
- Version: v1alpha1
-Status:
- Conditions:
- Last Transition Time: 2020-05-15T05:30:45Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
- Last Transition Time: 2020-05-15T05:30:45Z
- Reason: Created CRD and started controller
- Status: True
- Type: Established
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal ApplyInfrastructureDefinition 4m10s apiextensions/infrastructuredefinition.apiextensions.crossplane.io waiting for CustomResourceDefinition to be established
- Normal RenderCustomResourceDefinition 55s (x8 over 4m10s) apiextensions/infrastructuredefinition.apiextensions.crossplane.io Rendered CustomResourceDefinition
- Normal ApplyInfrastructureDefinition 55s (x7 over 4m9s) apiextensions/infrastructuredefinition.apiextensions.crossplane.io Applied CustomResourceDefinition and (re)started composite controller
-```
-
-### Specify How Your Resource May Be Composed
-
-Once a new kind of infrastructure resource is defined Crossplane must be
-instructed how to reconcile that kind of infrastructure resource. This is done
-by authoring a `Composition`.
-
-A `Composition`:
-
-* Declares one kind of composite infrastructure resource that it satisfies.
-* Specifies a "base" configuration for one or more infrastructure resources.
-* Specifies "patches" that overlay configuration values from an instance of the
- composite infrastructure resource onto each "base".
-
-Multiple compositions may satisfy a particular kind of composite infrastructure
-resource, and the author of a composite resource (or resource requirement) may
-select which composition will be used. This allows an infrastructure operator to
-offer their application operators a choice between multiple opinionated classes
-of infrastructure, allowing them to explicitly specify only some configuration.
-An infrastructure operator may offer their application operators the choice
-between an "Azure" and a "GCP" composition when creating a `MySQLInstance` for
-example, Or they may offer a choice between a "production" and a "staging"
-`MySQLInstance` composition. In either case the application operator may
-configure any value supported by the composite infrastructure resource's schema,
-with all other values being deferred to the composition.
-
-> Note that per [Current Limitations] it is not currently possible to specify a
-> default or an enforced composition for a particular kind of infrastructure
-> resource, but these options will be added in a future release of Crossplane.
-> In the meantime composite resource and/or resource requirement authors must
-> specify a composition for their resource to use.
-
-The below `Composition` satisfies the `MySQLInstance` defined in the previous
-section by composing an Azure SQL server, firewall rule, and resource group:
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: Composition
-metadata:
- name: example-azure
- labels:
- purpose: example
- provider: azure
-spec:
- # This Composition declares that it satisfies the MySQLInstance composite
- # resource defined above - i.e. it patches "from" a MySQLInstance.
- from:
- apiVersion: example.org/v1alpha1
- kind: MySQLInstance
- # This Composition reconciles an instance of a MySQLInstance by patching from
- # the MySQLInstance "to" new instances of the infrastructure resources below.
- # These resources may be the managed resources of an infrastructure provider
- # such as provider-azure, or other composite infrastructure resources.
- to:
- # A MySQLInstance that uses this Composition will be composed of an Azure
- # ResourceGroup. The "base" for this ResourceGroup specifies the base
- # configuration that may be extended or mutated by the patches below.
- - base:
- apiVersion: azure.crossplane.io/v1alpha3
- kind: ResourceGroup
- spec:
- reclaimPolicy: Delete
- providerRef:
- name: example
- # Patches copy or "overlay" the value of a field path within the composite
- # resource (the MySQLInstance) to a field path within the composed resource
- # (the ResourceGroup). In the below example any labels and annotations will
- # be propagated from the MySQLInstance to the ResourceGroup, as will the
- # location.
- patches:
- - fromFieldPath: "metadata.labels"
- toFieldPath: "metadata.labels"
- - fromFieldPath: "metadata.annotations"
- toFieldPath: "metadata.annotations"
- - fromFieldPath: "spec.parameters.location"
- toFieldPath: "spec.location"
- # Sometimes it is necessary to "transform" the value from the composite
- # resource into a value suitable for the composed resource, for example an
- # Azure based composition may represent geographical locations differently
- # from a GCP based composition that satisfies the same composite resource.
- # This can be done by providing an optional array of transforms, such as
- # the below that will transform the MySQLInstance spec.parameters.location
- # value "us-west" into the ResourceGroup spec.location value "West US".
- transforms:
- - type: map
- map:
- us-west: West US
- us-east: East US
- au-east: Australia East
- # A MySQLInstance that uses this Composition will also be composed of an
- # Azure MySQLServer.
- - base:
- apiVersion: database.azure.crossplane.io/v1beta1
- kind: MySQLServer
- spec:
- forProvider:
- # When this MySQLServer is created it must specify a ResourceGroup in
- # which it will exist. The below resourceGroupNameSelector corresponds
- # to the spec.forProvider.resourceGroupName field of the MySQLServer.
- # It selects a ResourceGroup with a matching controller reference.
- # Two resources that are part of the same composite resource will have
- # matching controller references, so this MySQLServer will always
- # select the ResourceGroup above. If this Composition included more
- # than one ResourceGroup they could be differentiated by matchLabels.
- resourceGroupNameSelector:
- matchControllerRef: true
- administratorLogin: notadmin
- sslEnforcement: Disabled
- sku:
- tier: GeneralPurpose
- capacity: 8
- family: Gen5
- storageProfile:
- backupRetentionDays: 7
- geoRedundantBackup: Disabled
- providerRef:
- name: example
- writeConnectionSecretToRef:
- namespace: crossplane-system
- reclaimPolicy: Delete
- patches:
- - fromFieldPath: "metadata.labels"
- toFieldPath: "metadata.labels"
- - fromFieldPath: "metadata.annotations"
- toFieldPath: "metadata.annotations"
- - fromFieldPath: "metadata.uid"
- toFieldPath: "spec.writeConnectionSecretToRef.name"
- transforms:
- # Transform the value from the MySQLInstance using Go string formatting.
- # This can be used to prefix or suffix a string, or to convert a number
- # to a string. See https://golang.org/pkg/fmt/ for more detail.
- - type: string
- string:
- fmt: "%s-mysqlserver"
- - fromFieldPath: "spec.parameters.version"
- toFieldPath: "spec.forProvider.version"
- - fromFieldPath: "spec.parameters.location"
- toFieldPath: "spec.forProvider.location"
- transforms:
- - type: map
- map:
- us-west: West US
- us-east: East US
- au-east: Australia East
- - fromFieldPath: "spec.parameters.storageGB"
- toFieldPath: "spec.forProvider.storageProfile.storageMB"
- # Transform the value from the MySQLInstance by multiplying it by 1024 to
- # convert Gigabytes to Megabytes.
- transforms:
- - type: math
- math:
- multiply: 1024
- # In addition to a base and patches, this composed MySQLServer declares that
- # it can fulfil the connectionSecretKeys contract required by the definition
- # of the MySQLInstance. This MySQLServer writes a connection secret with a
- # username, password, and endpoint that may be used to connect to it. These
- # connection details will also be exposed via the composite resource's
- # connection secret. Exactly one composed resource must provide each secret
- # key, but different composed resources may provide different keys.
- connectionDetails:
- - fromConnectionSecretKey: username
- - fromConnectionSecretKey: password
- # The name of the required MySQLInstance connection secret key can be
- # supplied if it is different from the connection secret key exposed by
- # the MySQLServer.
- - name: hostname
- fromConnectionSecretKey: endpoint
- # In some cases it may be desirable to inject a fixed connection secret
- # value, for example to expose fixed, non-sensitive connection details
- # like standard ports that are not published to the composed resource's
- # connection secret.
- - name: port
- value: "3306"
- # A MySQLInstance that uses this Composition will also be composed of an
- # Azure MySQLServerFirewallRule.
- - base:
- apiVersion: database.azure.crossplane.io/v1alpha3
- kind: MySQLServerFirewallRule
- spec:
- forProvider:
- resourceGroupNameSelector:
- matchControllerRef: true
- serverNameSelector:
- matchControllerRef: true
- properties:
- startIpAddress: 10.10.0.0
- endIpAddress: 10.10.255.254
- virtualNetworkSubnetIdSelector:
- name: sample-subnet
- providerRef:
- name: example
- reclaimPolicy: Delete
- patches:
- - fromFieldPath: "metadata.labels"
- toFieldPath: "metadata.labels"
- - fromFieldPath: "metadata.annotations"
- toFieldPath: "metadata.annotations"
- # Some composite resources may be "dynamically provisioned" - i.e. provisioned
- # on-demand to satisfy an application's requirement for infrastructure. The
- # writeConnectionSecretsToNamespace and reclaimPolicy fields configure default
- # values used when dynamically provisioning a composite resource; they are
- # explained in more detail below.
- writeConnectionSecretsToNamespace: crossplane-system
- reclaimPolicy: Delete
-```
-
-Field paths reference a field within a Kubernetes object via a simple string.
-API conventions describe the syntax as "standard JavaScript syntax for accessing
-that field, assuming the JSON object was transformed into a JavaScript object,
-without the leading dot, such as metadata.name". Array indices are specified via
-square braces while object fields may be specified via a period or via square
-braces.Kubernetes field paths do not support advanced features of JSON paths,
-such as `@`, `$`, or `*`. For example given the below `Pod`:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: example-pod
- annotations:
- example.org/a: example-annotation
-spec:
- containers:
- - name: example-container
- image: example:latest
- command: [example]
- args: ["--debug", "--example"]
-```
-
-* `metadata.name` would contain "example-pod"
-* `metadata.annotations['example.org/a']` would contain "example-annotation"
-* `spec.containers[0].name` would contain "example-container"
-* `spec.containers[0].args[1]` would contain "--example"
-
-> Note that Compositions provide _intentionally_ limited functionality when
-> compared to powerful templating and composition tools like Helm or Kustomize.
-> This allows a Composition to be a schemafied Kubernetes-native resource that
-> can be stored in and validated by the Kubernetes API server at authoring time
-> rather than invocation time.
-
-### Publish Your Infrastructure Resource
-
-An infrastructure operator may choose to publish any defined kind of composite
-infrastructure resource to their application operators. Doing so is optional -
-a kind of resource that is defined but not published may still be created at the
-cluster scope, but application operators may not create a namespaced requirement
-for that kind of resource.
-
-Infrastructure is published by an `InfrastructurePublication`:
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: InfrastructurePublication
-metadata:
- # InfrastructurePublications must use the same name as the
- # InfrastructureDefinition that defines the resource they publish.
- name: mysqlinstances.example.org
-spec:
- infrastructureDefinitionRef:
- name: mysqlinstances.example.org
-```
-
-`kubectl describe` can be used to confirm that a composite infrastructure
-resource was successfully published. Note the `Established` condition and
-events, which indicate the process was successful.
-
-```console
-$ kubectl describe infrastructurepublication mysqlinstances.example.org
-
-Name: mysqlinstances.example.org
-Namespace:
-Labels:
-Annotations: API Version: apiextensions.crossplane.io/v1alpha1
-Kind: InfrastructurePublication
-Metadata:
- Creation Timestamp: 2020-05-15T05:30:44Z
- Finalizers:
- published.apiextensions.crossplane.io
- Generation: 1
- Resource Version: 1418122
- Self Link: /apis/apiextensions.crossplane.io/v1alpha1/infrastructurepublications/mysqlinstances.example.org
- UID: 534c5151-2adc-4b4b-9248-fa30740e6b32
-Spec:
- Infrastructure Definition Ref:
- Name: mysqlinstances.example.or
-Status:
- Conditions:
- Last Transition Time: 2020-05-15T05:30:46Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
- Last Transition Time: 2020-05-15T05:30:46Z
- Reason: Created CRD and started controller
- Status: True
- Type: Established
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal ApplyInfrastructurePublication 7m35s apiextensions/infrastructurepublication.apiextensions.crossplane.io waiting for CustomResourceDefinition to be established
- Normal GetInfrastructureDefinition 7m32s (x7 over 7m36s) apiextensions/infrastructurepublication.apiextensions.crossplane.io Got published InfrastructureDefinition
- Normal RenderCustomResourceDefinition 7m32s (x7 over 7m36s) apiextensions/infrastructurepublication.apiextensions.crossplane.io Rendered CustomResourceDefinition
- Normal ApplyInfrastructurePublication 7m32s (x5 over 7m34s) apiextensions/infrastructurepublication.apiextensions.crossplane.io Applied CustomResourceDefinition and (re)started requirement controller
-```
-
-### Permit Crossplane to Reconcile Your Infrastructure Resource
-
-Typically Crossplane runs using a service account that does not have access to
-reconcile arbitrary kinds of resource. A `ClusterRole` can grant Crossplane
-permission to reconcile your newly defined and published resource:
-
-```yaml
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: mysqlinstances.example.org
- labels:
- rbac.crossplane.io/aggregate-to-crossplane: "true"
-rules:
-- apiGroups:
- - example.org
- resources:
- - mysqlinstances
- - mysqlinstances/status
- - mysqlinstancerequirements
- - mysqlinstancerequirements/status
- verbs:
- - "*"
-```
-
-## Using Infrastructure
-
-![Infrastructure Composition Provisioning]
-
-Crossplane offers several ways for both infrastructure operators and application
-operators to use the composite infrastructure they've defined and published:
-
-1. Only infrastructure operators can create or manage infrastructure of a kind
- that is not published to application operators.
-1. Infrastructure operators can create infrastructure of a published kind. This
- allows an application operator to create a requirement that specifically
- requires the resource the infrastructure operator created.
-1. Application operators can create a requirement for infrastructure of a kind
- that has been published, and it will be provisioned on-demand.
-
-Options one and two are frequently referred to as "static provisioning", while
-option three is known as "dynamic provisioning".
-
-> Note that infrastructure operator focused Crossplane concepts are cluster
-> scoped - they exist outside any namespace. Crossplane assumes infrastructure
-> operators will have similar RBAC permissions to cluster administrators, and
-> will thus be permitted to manage cluster scoped resources. Application
-> operator focused Crossplane concepts are namespaced. Crossplane assumes
-> application operators will be permitted access to the namespace(s) in which
-> their applications run, and not to cluster scoped resources.
-
-### Creating and Managing Composite Infrastructure
-
-An infrastructure operator may wish to author a composite resource of a kind
-that is published - i.e. a resource kind that has an `InfrastructurePublication`
-as well as an `InfrastructureDefinition` - so that an application operator may
-later author a requirement for that exact resource. This pattern is useful for
-infrastructure resources that may take several minutes to provision - the
-infrastructure operator can keep a pool of resources available in advance in
-order to ensure application requirements may be instantly satisfied.
-
-In some cases an infrastructure operator may wish to use Crossplane to model
-composite infrastructure that they do not wish to allow application operators to
-provision. Consider a `VPCNetwork` composite resource that creates an AWS VPC
-network with an internet gateway, route table, and several subnets. Defining
-this resource as a composite allows the infrastructure operator to easily reuse
-their configuration, but it does not make sense in their organisation to allow
-application operators to create "supporting infrastructure" like a VPC network.
-
-In both of the above scenarios the infrastructure operator may statically
-provision a composite resource; i.e. author it directly rather than via its
-corresponding requirement. The `MySQLInstance` composite infrastructure resource
-defined above could be authored as follows:
-
-```yaml
-apiVersion: example.org/v1alpha1
-kind: MySQLInstance
-metadata:
- # Composite resources are cluster scoped, so there's no need for a namespace.
- name: example
-spec:
- # The schema of the spec.parameters object is defined by the earlier example
- # of an InfrastructureDefinition. The location, storageGB, and version fields
- # are patched onto the ResourceGroup, MySQLServer, and MySQLServerFirewallRule
- # that this MySQLInstance composes.
- parameters:
- location: au-east
- storageGB: 20
- version: "5.7"
- # Support for a compositionRef is automatically injected into the schema of
- # all defined composite infrastructure resources. This allows the resource
- # author to explicitly reference a Composition that this composite resource
- # should use - in this case the earlier example-azure Composition. Note that
- # it is also possible to select a composition by labels - see the below
- # MySQLInstanceRequirement for an example of this approach.
- compositionRef:
- name: example-azure
- # Support for a writeConnectionSecretToRef is automatically injected into the
- # schema of all defined composite infrastructure resources. This allows the
- # resource to write a connection secret containing any details required to
- # connect to it - in this case the hostname, username, and password. Composite
- # resource authors may omit this reference if they do not need or wish to
- # write these details.
- writeConnectionSecretToRef:
- namespace: infra-secrets
- name: example-mysqlinstance
- # Support for a reclaimPolicy is automatically injected into the schema of all
- # defined composite infrastructure resources. The reclaim policy applies only
- # to published kinds of infrastructure - it controls whether the resource is
- # deleted or retained when its corresponding Requirement is deleted. If an
- # application authored a MySQLInstanceRequirement for this MySQLInstance then
- # later deleted their MySQLInstanceRequirement this MySQLInstance and all of
- # the resources it composes would be deleted. If the policy were instead set
- # to 'Retain' the MySQLInstance would be retained, for example to allow an
- # infrastructure operator to perform manual cleanup.
- reclaimPolicy: Delete
-```
-
-Any updates to the `MySQLInstance` composite infrastructure resource will be
-immediately reconciled with the resources it composes. For example if more
-storage were needed an update to the `spec.parameters.storageGB` field would
-immediately be propagated to the `spec.forProvider.storageProfile.storageMB`
-field of the composed `MySQLServer` due to the relationship established between
-these two fields by the patches configured in the `example-azure` `Composition`.
-
-`kubectl describe` may be used to examine a composite infrastructure resource.
-Note the `Synced` and `Ready` conditions below. The former indicates that
-Crossplane is successfully reconciling the composite resource by updating the
-composed resources. The latter indicates that all composed resources are also
-indicating that they are in condition `Ready`, and therefore the composite
-resource should be online and ready to use. More detail about the health and
-configuration of the composite resource can be determined by describing each
-composite resource. The kinds and names of each composed resource are exposed as
-"Resource Refs" - for example `kubectl describe mysqlserver example-zrpgr` will
-describe the detailed state of the composed Azure `MySQLServer`.
-
-```console
-$ kubectl describe mysqlinstance.example.org
-
-Name: example
-Namespace:
-Labels:
-Annotations: API Version: example.org/v1alpha1
-Kind: MySQLInstance
-Metadata:
- Creation Timestamp: 2020-05-15T06:53:16Z
- Generation: 4
- Resource Version: 1425809
- Self Link: /apis/example.org/v1alpha1/mysqlinstances/example
- UID: f654dd52-fe0e-47c8-aa9b-235c77505674
-Spec:
- Composition Ref:
- Name: example-azure
- Parameters:
- Location: au-east
- Storage GB: 20
- Version: 5.7
- Reclaim Policy: Delete
- Resource Refs:
- API Version: azure.crossplane.io/v1alpha3
- Kind: ResourceGroup
- Name: example-wspmk
- UID: 4909ab46-95ef-4ba7-8f7a-e1d9ee1a6b23
- API Version: database.azure.crossplane.io/v1beta1
- Kind: MySQLServer
- Name: example-zrpgr
- UID: 3afb903e-32db-4834-a6e7-31249212dca0
- API Version: database.azure.crossplane.io/v1alpha3
- Kind: MySQLServerFirewallRule
- Name: example-h4zjn
- UID: 602c8412-7c33-4338-a3af-78166c17b1a0
- Write Connection Secret To Ref:
- Name: example-mysqlinstance
- Namespace: infra-secrets
-Status:
- Conditions:
- Last Transition Time: 2020-05-15T06:56:46Z
- Reason: Resource is available for use
- Status: True
- Type: Ready
- Last Transition Time: 2020-05-15T06:53:16Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal SelectComposition 10s (x7 over 3m40s) composite/mysqlinstances.example.org Successfully selected composition
- Normal PublishConnectionSecret 10s (x7 over 3m40s) composite/mysqlinstances.example.org Successfully published connection details
- Normal ComposeResources 10s (x7 over 3m40s) composite/mysqlinstances.example.org Successfully composed resources
-```
-
-### Creating an Infrastructure Requirement
-
-Infrastructure requirements represent an application's requirement for a defined
-kind of infrastructure, for example the above `MySQLInstance`. Requirements are
-a proxy for the kind of resource they require, allowing application operators to
-provision and consume infrastructure. An infrastructure requirement may require
-pre-existing, statically provisioned infrastructure or it may dynamically
-provision infrastructure on-demand. A requirement for a defined kind of
-composite infrastructure resource is always suffixed with `Requirement`. A
-requirement for a composite infrastructure resource of kind `MySQLInstance` is,
-for example, of kind `MySQLInstanceRequirement`.
-
-The below requirement explicitly requires the `MySQLInstance` authored in the
-previous example:
-
-```yaml
-# The MySQLInstanceRequirement always has the same API group and version as the
-# resource it requires. Its kind is always suffixed with Requirement.
-apiVersion: example.org/v1alpha1
-kind: MySQLInstanceRequirement
-metadata:
- # Infrastructure requirements are namespaced.
- namespace: default
- name: example
-spec:
- # The schema of the spec.parameters object is defined by the earlier example
- # of an InfrastructureDefinition. The location, storageGB, and version fields
- # are patched onto the ResourceGroup, MySQLServer, and MySQLServerFirewallRule
- # composed by the required MySQLInstance.
- parameters:
- location: au-east
- storageGB: 20
- version: "5.7"
- # Support for a resourceRef is automatically injected into the schema of all
- # published infrastructure requirement resources. The resourceRef specifies
- # the explicit MySQLInstance that is required.
- resourceRef:
- name: example
- # Support for a writeConnectionSecretToRef is automatically injected into the
- # schema of all published infrastructure requirement resources. This allows
- # the resource to write a connection secret containing any details required to
- # connect to it - in this case the hostname, username, and password.
- writeConnectionSecretToRef:
- name: example-mysqlinstance
-```
-
-A requirement may omit the `resourceRef` and instead include a `compositionRef`
-(as in the previous `MySQLInstance` example) or a `compositionSelector` in order
-to trigger dynamic provisioning. A requirement that does not include a reference
-to an existing composite infrastructure resource will have a suitable composite
-resource provisioned on demand:
-
-```yaml
-apiVersion: example.org/v1alpha1
-kind: MySQLInstanceRequirement
-metadata:
- namespace: default
- name: example
-spec:
- parameters:
- location: au-east
- storageGB: 20
- version: "5.7"
- # Support for a compositionSelector is automatically injected into the schema
- # of all published infrastructure requirement resources. This selector selects
- # the example-azure composition by its labels.
- compositionSelector:
- matchLabels:
- purpose: example
- provider: azure
- writeConnectionSecretToRef:
- name: example-mysqlinstance
-```
-
-> Note that compositionSelector labels can form a shared language between the
-> infrastructure operators who define compositions and the application operators
-> who require composite resources. Compositions could be labelled by zone, size,
-> or purpose in order to allow application operators to request a class of
-> composite resource by describing their needs such as "east coast, production".
-
-Like composite resources, requirements can be examined using `kubectl describe`.
-The `Synced` and `Ready` conditions have the same meaning as the `MySQLInstance`
-above. The "Resource Ref" indicates the name of the composite resource that was
-either explicitly required, or in the case of the below requirement dynamically
-provisioned.
-
-```console
-$ kubectl describe mysqlinstancerequirement.example.org example
-
-Name: example
-Namespace: default
-Labels:
-Annotations: API Version: example.org/v1alpha1
-Kind: MySQLInstanceRequirement
-Metadata:
- Creation Timestamp: 2020-05-15T07:08:11Z
- Finalizers:
- finalizer.apiextensions.crossplane.io
- Generation: 3
- Resource Version: 1428420
- Self Link: /apis/example.org/v1alpha1/namespaces/default/mysqlinstancerequirements/example
- UID: d87e9580-9d2e-41a7-a198-a39851815840
-Spec:
- Composition Selector:
- Match Labels:
- Provider: azure
- Purpose: example
- Parameters:
- Location: au-east
- Storage GB: 20
- Version: 5.7
- Resource Ref:
- Name: default-example-8t4tb
- Write Connection Secret To Ref:
- Name: example-mysqlinstance
-Status:
- Conditions:
- Last Transition Time: 2020-05-15T07:26:49Z
- Reason: Resource is available for use
- Status: True
- Type: Ready
- Last Transition Time: 2020-05-15T07:08:11Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal ConfigureCompositeResource 8m23s requirement/mysqlinstances.example.org Successfully configured composite resource
- Normal BindCompositeResource 8m23s (x7 over 8m23s) requirement/mysqlinstances.example.org Composite resource is not yet ready
- Normal BindCompositeResource 4m53s (x4 over 23m) requirement/mysqlinstances.example.org Successfully bound composite resource
- Normal PropagateConnectionSecret 4m53s (x4 over 23m) requirement/mysqlinstances.example.org Successfully propagated connection details from composite resource
-```
-
-## Current Limitations
-
-Defining and publishing composite infrastructure resources is an experimental
-feature of Crossplane. At present the below functionality is planned but not yet
-implemented:
-
-* Updates to a composite infrastructure resource are immediately applied to the
- resources it composes, but updates to a requirement are not yet applied to the
- composite resource that was allocated to satisfy the requirement. In a future
- release of Crossplane updating a requirement will update its allocated
- composite infrastructure resource.
-* A composite infrastructure resource (or dynamically provisioned requirement)
- must specify a composition reference or selector. In a future Crossplane
- release it will be possible to configure a default composition for resources
- that provide no information about what composition they desire, and to
- configure a single composition that will be enforced for all resources.
-* Only three transforms are currently supported - string format, multiplication,
- and map. Crossplane intends to limit the set of supported transforms, and will
- add more as clear use cases appear.
-* Compositions are mutable, and updating a composition causes all composite
- resources that use that composition to be updated accordingly. A future
- release of Crossplane may alter this behaviour.
-* Composite resources that are retained when the requirement they were allocated
- to is deleted become available for allocation to another requirement. This may
- not be the desired behaviour, for example if the application that previously
- required the composite infrastructure resource wrote sensitive data to it. A
- future release of Crossplane may alter the reclaim policy options.
-
-[Current Limitations]: #current-limitations
-[Infrastructure Composition Concepts]: composition-concepts.png
-[structural schemas]: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#specifying-a-structural-schema
-[Infrastructure Composition Provisioning]: composition-provisioning.png
diff --git a/docs/v0.11/introduction/crossplane-concepts.png b/docs/v0.11/introduction/crossplane-concepts.png
deleted file mode 100644
index 436d65cd..00000000
Binary files a/docs/v0.11/introduction/crossplane-concepts.png and /dev/null differ
diff --git a/docs/v0.11/introduction/managed-resources.md b/docs/v0.11/introduction/managed-resources.md
deleted file mode 100644
index 2cd3a21c..00000000
--- a/docs/v0.11/introduction/managed-resources.md
+++ /dev/null
@@ -1,261 +0,0 @@
----
-title: Managed Resources
-toc: true
-weight: 102
-indent: true
----
-
-# Managed Resources
-
-## Overview
-
-Managed resources are the Crossplane representation of the cloud [provider][provider]
-resources and they are considered primitive low level custom resources that can
-be used directly to provision external cloud resources for an application or as
-part of an infrastructure composition.
-
-For example, `RDSInstance` in AWS Provider corresponds to an actual RDS Instance
-in AWS. There is a one-to-one relationship and the changes on managed resources are
-reflected directly on the corresponding resource in the provider.
-
-You can browse [API Reference][api-reference] to discover all available managed resources.
-
-## Syntax
-
-Crossplane API conventions extend the Kubernetes API conventions for the schema
-of Crossplane managed resources. Following is an example of `RDSInstance`:
-
-```yaml
-apiVersion: database.aws.crossplane.io/v1beta1
-kind: RDSInstance
-metadata:
- name: foodb
-spec:
- forProvider:
- dbInstanceClass: db.t2.small
- masterUsername: root
- allocatedStorage: 20
- engine: mysql
- writeConnectionSecretToRef:
- name: mysql-secret
- namespace: crossplane-system
- providerRef:
- name: mycreds
- reclaimPolicy: Delete
-```
-
-In Kubernetes, `spec` top field represents the desired state of the user.
-Crossplane adheres to that and has its own conventions about how the fields under
-`spec` should look like.
-
-* `writeConnectionSecretToRef`: A reference to the secret that you want this
- managed resource to write its connection secret that you'd be able to mount
- to your pods in the same namespace. For `RDSInstance`, this secret would contain
- `endpoint`, `username` and `password`.
-
-* `providerRef`: Reference to the `Provider` resource that will provide information
- regarding authentication of Crossplane to the provider. `Provider` resources
- refer to `Secret` and potentially contain other information regarding authentication.
-
-* `reclaimPolicy`: Enum to specify whether the actual cloud resource should be
- deleted when this managed resource is deleted in Kubernetes API server. Possible
- values are `Delete` and `Retain`.
-
-* `forProvider`: While the rest of the fields relate to how Crossplane should
- behave, the fields under `forProvider` are solely used to configure the actual
- external resource. In most of the cases, the field names correspond to the what
- exists in provider's API Reference.
-
- The objects under `forProvider` field can get huge depending on the provider
- API. For example, GCP `ServiceAccount` has only a few fields while GCP `CloudSQLInstance`
- has over 100 fields that you can configure.
-
-### Versioning
-
-Crossplane closely follows the [Kubernetes API versioning conventions][api-versioning]
-for the CRDs that it deploys. In short, for `vXbeta` and `vX` versions, you can
-expect that either automatic migration or instructions for manual migration will
-be provided when a new version of that CRD schema is released.
-
-### Grouping
-
-In general, managed resources are high fidelity resources meaning they will provide
-parameters and behaviors that are provided by the external resource API. This applies
-to grouping of resources, too. For example, `RDSInstance` appears under `database`
-API group, so, its `APIVersion` and `Kind` look like the following:
-
-```yaml
-apiVersion: database.aws.crossplane.io/v1beta1
-kind: RDSInstance
-```
-
-## Behavior
-
-As a general rule, managed resource controllers try not to make any decision
-that is not specified by the user in the desired state since managed resources
-are the lowest level primitives that operate directly on the cloud provider APIs.
-
-### Continuous Reconciliation
-
-Crossplane providers continuously reconcile the managed resource to achieve the
-desired state. The parameters under `spec` are considered the one and only source
-of truth for the external resource. This means that if someone changed a
-configuration in the UI of the provider, like AWS Console, Crossplane will change
-it back to what's given under `spec`.
-
-#### Immutable Properties
-
-There are configuration parameters in external resources that cloud providers do not
-allow to be changed. If the corresponding field in the managed resource is changed
-by the user, Crossplane submits the new desired state to the provider and returns
-the error, if any. For example, in AWS, you cannot change the region of
-an `RDSInstance`.
-
-Some infrastructure tools such as Terraform delete and recreate the resource
-to accommodate those changes but Crossplane does not take that route. Unless
-the managed resource is deleted and its `reclaimPolicy` is `Delete`, its controller
-never deletes the external resource in the provider.
-
-> Immutable fields are marked as `immutable` in Crossplane codebase
-but Kubernetes does not yet have immutable field notation in CRDs.
-
-### External Name
-
-By default the name of the managed resource is used as the name of the external
-cloud resource that will show up in your cloud console.
-To specify a different external name, Crossplane has a special annotation to
-represent the name of the external resource. For example, I would like to
-have a `CloudSQLInstance` with an external name that is different than its
-managed resource name:
-
-```yaml
-apiVersion: database.gcp.crossplane.io/v1beta1
-kind: CloudSQLInstance
-metadata:
- name: foodb
- annotations:
- crossplane.io/external-name: my-special-db
-spec:
- ...
-```
-
-When you create this managed resource, you will see that the name of `CloudSQLInstance`
-in GCP console will be `my-special-db`.
-
-If the annotation is not given, Crossplane will fill it with the name of the managed
-resource by default. In cases where provider doesn't allow you to name the resource,
-like AWS VPC, the controller creates the resource and sets external annotation
-to be the name that the cloud provider chose. So, you would see something like
-`vpc-28dsnh3` as the value of `crossplane.io/external-name` annotation of your
-AWS `VPC` resource even if you added your own custom external name during creation.
-
-### Late Initialization
-
-For some of the optional fields, users rely on the default that the cloud provider
-chooses for them. Since Crossplane treats the managed resource as the source of
-the truth, values of those fields need to exist in `spec` of the managed resource.
-So, in each reconciliation, Crossplane will fill the value of a field that is
-left empty by the user but is assigned a value by the provider. For example,
-there could be two fields like `region` and `availabilityZone` and you might want
-to give only `region` and leave the availability zone to be chosen by the cloud
-provider. In that case, if the provider assigns an availability zone, Crossplane
-gets that value and fills `availabilityZone`. Note that if the field is already
-filled, the controller won't override its value.
-
-### Deletion
-
-When a deletion request is made for a managed resource, its controller starts the
-deletion process immediately. However, the managed resource is kept in the Kubernetes
-API (via a finalizer) until the controller confirms the external resource in the
-cloud is gone. So you can be sure that if the managed resource is deleted, then
-the external cloud resource is also deleted. Any errors that happen during
-deletion will be added to the `status` of the managed resource, so you can
-troubleshoot any issues.
-
-## Dependencies
-
-In many cases, an external resource refers to another one for a specific configuration.
-For example, you could want your Azure Kubernetes cluster in a specific
-Virtual Network. External resources have specific fields for these relations, however,
-they usually require the information to be supplied in different formats. In Azure
-MySQL, you might be required to enter only the name of the Virtual Network while in
-Azure Kubernetes, it could be required to enter a string in a specific format
-that includes other information such as resource group name.
-
-In Crossplane, users have 3 fields to refer to another resource. Here is an example
-from Azure MySQL managed resource referring to a Azure Resource Group:
-
-```yaml
-spec:
- forProvider:
- resourceGroupName: foo-res-group
- resourceGroupNameRef:
- name: resourcegroup
- resourceGroupNameSelector:
- matchLabels:
- app: prod
-```
-
-In this example, the user provided only a set of labels to select a `ResourceGroup`
-managed resource that already exists in the cluster via `resourceGroupNameSelector`.
-Then after a specific `ResourceGroup` is selected, `resourceGroupNameRef` is filled
-with the name of that `ResourceGroup` managed resource. Then in the last step,
-Crossplane fills the actual `resourceGroupName` field with whatever format Azure
-accepts it. Once a dependency is resolved, the controller never changes it.
-
-Users are able to specify any of these three fields:
- - Selector to select via labels
- - Reference to point to a determined managed resource
- - Actual value that will be submitted to the provider
-
-It's important to note that in case a reference exists, the managed resource does
-not create the external resource until the referenced object is ready. In this
-example, creation call of Azure MySQL Server will not be made until referenced
-`ResourceGroup` has its `status.condition` named `Ready` to be true.
-
-## Importing Existing Resources
-
-If you have some resources that are already provisioned in the cloud provider,
-you can import them as managed resources and let Crossplane manage them. What you
-need to do is to enter the name of the external resource as well as the required
-fields on the managed resource. For example, let's say I have a GCP Network
-provisioned from GCP console and I would like to migrate it to Crossplane. Here
-is the YAML that I need to create:
-
-```yaml
-apiVersion: compute.gcp.crossplane.io/v1beta1
-kind: Network
-metadata:
- name: foo-network
- annotation:
- crossplane.io/external-name: existing-network
-spec:
- providerRef:
- name: gcp-creds
-```
-
-Crossplane will check whether a GCP Network called `existing-network` exists, and
-if it does, then the optional fields under `forProvider` will be filled with the
-values that are fetched from the provider.
-
-Note that if a resource has required fields, you must fill those fields or the
-creation of the managed resource will be rejected. So, in those cases, you will
-need to enter the name of the resource as well as the required fields as indicated
-in the [API Reference][api-reference] documentation.
-
-## Backup and Restore
-
-Crossplane adheres to Kubernetes conventions as much as possible and one of the
-advantages we gain is backup & restore ability with tools that work with native
-Kubernetes types, like [Verero][velero].
-
-If you'd like to backup and restore manually, you can simply export them and save
-YAMLs in your file system. When you reload them, as we've discovered in import
-section, their `crosssplane.io/external-name` annotation and required fields are
-there and those are enough to import a resource. The tool you're using needs to
-store `annotations` and `spec` fields, which most tools do including Velero.
-
-[api-versioning]: https://kubernetes.io/docs/reference/using-api/api-overview/#api-versioning
-[velero]: https://velero.io/
-[api-reference]: api-docs/overview.md
-[provider]: provider.md
\ No newline at end of file
diff --git a/docs/v0.11/introduction/overview.md b/docs/v0.11/introduction/overview.md
deleted file mode 100644
index cfcf500a..00000000
--- a/docs/v0.11/introduction/overview.md
+++ /dev/null
@@ -1,133 +0,0 @@
----
-title: Introduction
-toc: true
-weight: 100
----
-
-# Overview
-
-Crossplane introduces multiple building blocks that enable you to provision,
-publish, and consume infrastructure using the Kubernetes API. These individual
-concepts work together to allow for powerful separation of concern between
-different personas in an organization, meaning that each member of a team
-interacts with Crossplane at an appropriate level of abstraction.
-
-![Crossplane Concepts]
-
-The diagram above illustrates a common workflow using most of Crossplane's
-functionality.
-
-An infrastructure operator...
-1. Installs Crossplane and one or more [providers] (in this case
- [provider-azure]) as [packages]. This enables provisioning of external
- infrastructure from the Kubernetes cluster.
-2. Creates an `InfrastructureDefinition` to define a new type of resource (in
- this case a `MySQLInstance`). Crossplane creates a cluster-scoped CRD of kind
- `MySQLInstance` in response.
-3. Creates an `InfrastructurePublication` to make provisioning a `MySQLInstance`
- possible at the namespace scope. Crossplane creates a namespace-scoped CRD of
- kind `MySQLInstanceRequirement` in response.
-4. Creates a `Composition` that instructs Crossplane how to render one or more
- infrastructure primitives installed by providers in response to the creation
- of a `MySQLInstance` or `MySQLInstanceRequirement`. In this case the
- `Composition` specifies that Azure `MySQLServer` and `MySQLFirewallRule`
- [managed resources] should be created.
-
-An application developer...
-1. Creates an [OAM] `Component` for their service that specifies that they wish
- to be run as an OAM `ContainerizedWorkload`.
-2. Creates an OAM `Component` for their MySQL database that can be satisfied by
- the published `MySQLInstanceRequirement` type.
-
-An application operator...
-1. Creates an OAM `ApplicationConfiguration`, which is comprised of the two
- `Component` types that were defined by the application developer, and a
- `ManualScalerTrait` trait to modify the replicas in the
- `ContainerizedWorkload`. In response, Crossplane translates the OAM types
- into Kubernetes-native types, in this case a `Deployment` and `Service` for
- the `ContainerizedWorkload` component, and a `MySQLServer` and
- `MySQLFirewallRule` for the `MySQLInstanceRequirement` component.
-2. Crossplane provisions the external infrastructure and makes the connection
- information available to the application, allowing it to connect to and
- consume the MySQL database on Azure.
-
-The concepts used in this workflow are explained in greater detail below and in
-their individual documentation.
-
-## Packages
-
-Packages allow Crossplane to be extended to include new functionality. This
-typically looks like bundling a set of Kubernetes [CRDs] and [controllers] that
-represent and manage external infrastructure (i.e. a provider), then installing
-them into a cluster where Crossplane is running. Crossplane handles making sure
-any new CRDs do not conflict with existing ones, as well as manages the RBAC and
-security of new packages. Packages are not strictly required to be providers,
-but it is the most common use-case for packages at this time.
-
-## Providers
-
-Providers are packages that enable Crossplane to provision infrastructure on an
-external service. They bring CRDs (i.e. managed resources) that map one-to-one
-to external infrastructure resources, as well as controllers to manage the
-life-cycle of those resources. You can read more about providers, including how
-to install and configure them, in the [providers documentation].
-
-## Managed Resources
-
-Managed resources are Kubernetes custom resources that represent infrastructure
-primitives. Managed resources with an API version of `v1beta1` or higher support
-every field that the cloud provider does for the given resource. You can find
-the Managed Resources and their API specifications for each provider on
-[doc.crds.dev] and learn more in the [managed resource documentation].
-
-## Composition
-
-Composition refers the machinery that allows you to bundle managed resources
-into higher-level infrastructure units, using only the Kubernetes API. New
-infrastructure units are defined using the `InfrastructureDefinition`,
-`InfrastructurePublication`, and `Composition` types, which result in the
-creation of new CRDs in a cluster. Creating instances of these new CRDs result
-in the creation of one or more managed resources. You can learn more about all
-of these concepts in the [composition documentation].
-
-## OAM
-
-Crossplane supports application management as the Kubernetes implementation of
-the [Open Application Model]. As such, Crossplane currently implements the
-following OAM API types as Kubernetes custom resources.
-
-* `WorkloadDefinition`: defines the kind of components that an application
- developer can use in an application, along with the component's schema.
- * Crossplane also implements the core `ContainerizedWorkload` type.
- Infrastructure owners may define any resource as a workload type by
- referencing it in a `WorkloadDefinition`.
-* `Component`: describe functional units that may be instantiated as part of a
- larger distributed application. For example, each micro-service in an
- application is described as a `Component`.
-* `Trait`: a discretionary runtime overlay that augments a component workload
- type with additional features. It represents an opportunity for those in the
- application operator role to make specific decisions about the configuration
- of components, without having to involve the developer.
- * Crossplane also implements the core `ManualScalerTrait` type.
-* `ApplicationConfiguration`: includes one or more component instances, each
- represented by a component definition that defines how an instance of a
- component spec should be deployed.
-
-For more information, take a look at the [OAM documentation].
-
-
-
-[Crossplane Concepts]: crossplane-concepts.png
-[providers]: #providers
-[provider-azure]: https://github.com/crossplane/provider-azure
-[packages]: #packages
-[managed resources]: #managed-resources
-[OAM]: #oam
-[CRDs]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[controllers]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-controllers
-[providers documentation]: providers.md
-[doc.crds.dev]: https://doc.crds.dev
-[managed resources documentation]: managed-resources.md
-[composition documentation]: composition.md
-[Open Application Model]: https://oam.dev/
-[OAM documentation]: oam.md
diff --git a/docs/v0.11/introduction/providers.md b/docs/v0.11/introduction/providers.md
deleted file mode 100644
index 61ecce9b..00000000
--- a/docs/v0.11/introduction/providers.md
+++ /dev/null
@@ -1,129 +0,0 @@
----
-title: Providers
-toc: true
-weight: 101
-indent: true
----
-
-# Providers
-
-Providers extend Crossplane to enable infrastructure resource provisioning.
-In order to provision a resource, a Custom Resource Definition(CRD)
-needs to be registered in your Kubernetes cluster and its controller should
-be watching the Custom Resources those CRDs define. Provider packages
-contain many Custom Resource Definitions and their controllers.
-
-Here is the list of current providers:
-
-### AWS Provider
-* [GitHub][provider-aws]
-* [API Reference][aws-reference]
-
-### GCP Provider
-* [GitHub][provider-gcp]
-* [API Reference][gcp-reference]
-
-### Azure Provider
-* [GitHub][provider-azure]
-* [API Reference][azure-reference]
-
-### Rook Provider
-* [GitHub][provider-rook]
-* [API Reference][rook-reference]
-
-### Alibaba Cloud Provider
-* [GitHub][provider-alibaba]
-* [API Reference][alibaba-reference]
-
-## Installing Providers
-
-The core Crossplane controller can install provider controllers and CRDs for you
-through its own provider packaging mechanism, which is triggered by the application
-of a `ClusterPackageInstall` resource. For example, in order to request
-installation of the `provider-gcp` package, apply the following resource to the
-cluster where Crossplane is running:
-
-```yaml
-apiVersion: packages.crossplane.io/v1alpha1
-kind: ClusterPackageInstall
-metadata:
- name: provider-gcp
- namespace: crossplane-system
-spec:
- package: "crossplane/provider-gcp:master"
-```
-
-The field `spec.package` is where you refer to the container image of the
-provider. Crossplane Package Manager will unpack that container, register
-CRDs and set up necessary RBAC rules and then start the controllers.
-
-There are a few other ways to to trigger the installation of provider
-packages:
-
-* As part of Crossplane Helm chart by adding the following
- statement to your `helm install` command: `--set clusterPackages.gcp.deploy=true`
- It will install the default version hard-coded in that release of Crossplane
- Helm chart but if you'd like to specif an exact version, you can add:
- `--set clusterPackages.gcp.version=master`.
-* Using [Crossplane kubectl plugin][crossplane-cli]:
- `kubectl crossplane package install --cluster -n crossplane-system 'crossplane/provider-gcp:master' provider-gcp`
-
-You can uninstall a provider by deleting the `ClusterPackageInstall` resource
-you've created.
-
-## Configuring Providers
-
-In order to authenticate with the external provider API, the provider controllers
-need to have access to credentials. It could be an IAM User for AWS, a Service
-Account for GCP or a Service Principal for Azure. Every provider has a type called
-`Provider` that has information about how to authenticate to the provider API.
-An example `Provider` resource for Azure looks like the following:
-
-```yaml
-apiVersion: azure.crossplane.io/v1alpha3
-kind: Provider
-metadata:
- name: prod-acc
-spec:
- credentialsSecretRef:
- namespace: crossplane-system
- name: azure-prod-creds
- key: credentials
-```
-
-You can see that there is a reference to a key in a specific `Secret`. The value
-of that key should contain the credentials that the controller will use. The
-documentation of each provider should give you an idea of how that credentials
-blob should look like. See [Getting Started][getting-started] guide for more details.
-
-The following is an example usage of Azure `Provider`, referenced by a `MySQLServer`:
-
-```yaml
-apiVersion: database.azure.crossplane.io/v1beta1
-kind: MySQLServer
-metadata:
- name: prod-sql
-spec:
- providerRef: prod-acc
- ...
-```
-
-The Azure provider controller will use that provider for this instance of `MySQLServer`.
-Since every resource has its own reference to a `Provider`, you can have multiple
-`Provider` resources in your cluster referenced by different resources.
-
-
-
-
-[provider-aws]: https://github.com/crossplane/provider-aws
-[aws-reference]: https://doc.crds.dev/github.com/crossplane/provider-aws
-[provider-gcp]: https://github.com/crossplane/provider-gcp
-[gcp-reference]: https://doc.crds.dev/github.com/crossplane/provider-gcp
-[provider-azure]: https://github.com/crossplane/provider-azure
-[azure-reference]: https://doc.crds.dev/github.com/crossplane/provider-azure
-[provider-rook]: https://github.com/crossplane/provider-rook
-[rook-reference]: https://doc.crds.dev/github.com/crossplane/provider-rook
-[provider-alibaba]: https://github.com/crossplane/provider-alibaba
-[alibaba-reference]: https://doc.crds.dev/github.com/crossplane/provider-alibaba
-[getting-started]: ../getting-started/install-configure.md
-[crossplane-cli]: https://github.com/crossplane/crossplane-cli
diff --git a/docs/v0.11/media/arch.png b/docs/v0.11/media/arch.png
deleted file mode 100644
index 8205e62e..00000000
Binary files a/docs/v0.11/media/arch.png and /dev/null differ
diff --git a/docs/v0.11/media/banner.png b/docs/v0.11/media/banner.png
deleted file mode 100644
index 0a495e1d..00000000
Binary files a/docs/v0.11/media/banner.png and /dev/null differ
diff --git a/docs/v0.11/media/crossplane-overview.png b/docs/v0.11/media/crossplane-overview.png
deleted file mode 100644
index 87c25a89..00000000
Binary files a/docs/v0.11/media/crossplane-overview.png and /dev/null differ
diff --git a/docs/v0.11/media/logo.svg b/docs/v0.11/media/logo.svg
deleted file mode 100644
index 3af90369..00000000
--- a/docs/v0.11/media/logo.svg
+++ /dev/null
@@ -1,310 +0,0 @@
-
-
-
diff --git a/docs/v0.11/reference/configure.md b/docs/v0.11/reference/configure.md
deleted file mode 100644
index 45c4934c..00000000
--- a/docs/v0.11/reference/configure.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Configure
-toc: true
-weight: 302
-indent: true
----
-
-# Configure Your Cloud Provider Account
-
-In order for Crossplane to be able to manage resources in a specific cloud
-provider, you will need to create an account for Crossplane to use. Use the
-links below for cloud-specific instructions to create an account that can be
-used throughout the guides:
-
-* [Google Cloud Platform (GCP) Service Account]
-* [Microsoft Azure Service Principal]
-* [Amazon Web Services (AWS) IAM User]
-
-Once you have configured your cloud provider account, you can get started
-provisioning resources!
-
-
-
-[Google Cloud Platform (GCP) Service Account]: ../cloud-providers/gcp/gcp-provider.md
-[Microsoft Azure Service Principal]: ../cloud-providers/azure/azure-provider.md
-[Amazon Web Services (AWS) IAM User]: ../cloud-providers/aws/aws-provider.md
diff --git a/docs/v0.11/reference/install.md b/docs/v0.11/reference/install.md
deleted file mode 100644
index f7b3a3cd..00000000
--- a/docs/v0.11/reference/install.md
+++ /dev/null
@@ -1,347 +0,0 @@
----
-title: Install
-toc: true
-weight: 301
-indent: true
----
-
-# Install Crossplane
-
-Crossplane can be easily installed into any existing Kubernetes cluster using
-the regularly published Helm chart. The Helm chart contains all the custom
-resources and controllers needed to deploy and configure Crossplane.
-
-## Pre-requisites
-
-* [Kubernetes cluster]
- * For example [Minikube], minimum version `v0.28+`
-* [Helm], minimum version `v2.12.0+`.
- * For Helm 2, make sure Tiller is initialized with sufficient permissions to
- work on `crossplane-system` namespace.
-
-## Installation
-
-Helm charts for Crossplane are currently published to the `alpha` and `master`
-channels. In the future, `beta` and `stable` will also be available.
-
-### Alpha
-
-The alpha channel is the most recent release of Crossplane that is considered
-ready for testing by the community.
-
-Install with Helm 2:
-
-```console
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-Install with Helm 3:
-
-If your Kubernetes version is lower than 1.15 and you'd like to install
-Crossplane via Helm 3, you'll need Helm v3.1.0+ that has the flag
-`--disable-openapi-validation`.
-
-```console
-kubectl create namespace crossplane-system
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-
-# Kubernetes 1.15 and newer versions
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane
-
-# Kubernetes 1.14 and older versions
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane --disable-openapi-validation
-```
-
-### Master
-
-The `master` channel contains the latest commits, with all automated tests
-passing. `master` is subject to instability, incompatibility, and features may
-be added or removed without much prior notice. It is recommended to use one of
-the more stable channels, but if you want the absolute newest Crossplane
-installed, then you can use the `master` channel.
-
-To install the Helm chart from master, you will need to pass the specific
-version returned by the `search` command:
-
-Install with Helm 2:
-
-```console
-helm repo add crossplane-master https://charts.crossplane.io/master/
-helm search crossplane-master
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version
-```
-
-For example:
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version 0.0.0-249.637ccf9
-```
-
-Install with Helm 3:
-
-If your Kubernetes version is lower than 1.15 and you'd like to install
-Crossplane via Helm 3, you'll need Helm v3.1.0+.
-
-```console
-kubectl create namespace crossplane-system
-helm repo add crossplane-master https://charts.crossplane.io/master/
-helm search repo crossplane-master --devel
-
-# Kubernetes 1.15 and newer versions
-helm install crossplane --namespace crossplane-system crossplane-master/crossplane --version --devel
-
-# Kubernetes 1.14 and older versions
-helm install crossplane --namespace crossplane-system crossplane-master/crossplane --version --devel --disable-openapi-validation
-```
-
-## Installing Infrastructure Providers
-
-You can add additional functionality to Crossplane's control plane by installing
-`providers`. For example, each supported cloud provider has its own
-corresponding Crossplane `provider` that contains all the functionality for that
-particular cloud. After a cloud provider's infrastructure `provider` is
-installed, you will be able to provision and manage resources within that cloud
-from Crossplane.
-
-### Installation with Helm
-
-You can include deployment of additional infrastructure providers into your helm
-installation by setting `clusterPackages..deploy` to `true`.
-
-For example, the following will install `master` version of the GCP package.
-
-Using Helm 2:
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version --set clusterPackages.gcp.deploy=true --set clusterPackages.gcp.version=master
-```
-
-Using Helm 3:
-
-```console
-kubectl create namespace crossplane-system
-helm install crossplane --namespace crossplane-system crossplane-master/crossplane --version --set clusterPackages.gcp.deploy=true --set clusterPackages.gcp.version=master --devel
-```
-
-See [helm configuration parameters](#configuration) for supported packages and
-parameters.
-
-### Manual Installation
-
-After Crossplane has been installed, it is possible to extend Crossplane's
-functionality by installing Crossplane providers.
-
-#### GCP Provider
-
-To get started with Google Cloud Platform (GCP), create a file named
-`provider-gcp.yaml` with the following content:
-
-```yaml
-apiVersion: packages.crossplane.io/v1alpha1
-kind: ClusterPackageInstall
-metadata:
- name: provider-gcp
- namespace: crossplane-system
-spec:
- package: "crossplane/provider-gcp:v0.10.0"
-```
-
-Then you can install the GCP provider into Crossplane in the `gcp` namespace
-with the following command:
-
-```console
-kubectl apply -f provider-gcp.yaml
-```
-
-#### AWS Provider
-
-To get started with Amazon Web Services (AWS), create a file named
-`provider-aws.yaml` with the following content:
-
-```yaml
-apiVersion: packages.crossplane.io/v1alpha1
-kind: ClusterPackageInstall
-metadata:
- name: provider-aws
- namespace: crossplane-system
-spec:
- package: "crossplane/provider-aws:v0.10.0"
-```
-
-Then you can install the AWS provider into Crossplane in the `aws` namespace
-with the following command:
-
-```console
-kubectl apply -f provider-aws.yaml
-```
-
-#### Azure Provider
-
-To get started with Microsoft Azure, create a file named `provider-azure.yaml`
-with the following content:
-
-```yaml
-apiVersion: packages.crossplane.io/v1alpha1
-kind: ClusterPackageInstall
-metadata:
- name: provider-azure
- namespace: crossplane-system
-spec:
- package: "crossplane/provider-azure:v0.10.0"
-```
-
-Then you can install the Azure provider into Crossplane in the `azure` namespace
-with the following command:
-
-```console
-kubectl apply -f provider-azure.yaml
-```
-
-#### Rook Provider
-
-To get started with Rook, create a file named `provider-rook.yaml` with the
-following content:
-
-```yaml
-apiVersion: packages.crossplane.io/v1alpha1
-kind: ClusterPackageInstall
-metadata:
- name: provider-rook
- namespace: crossplane-system
-spec:
- package: "crossplane/provider-rook:v0.7.0"
-```
-
-Then you can install the Rook provider into Crossplane in the `rook` namespace
-with the following command:
-
-```console
-kubectl apply -f provider-rook.yaml
-```
-
-### Uninstalling Infrastructure Providers
-
-The infrastructure can be uninstalled simply by deleting the provider resources
-from the cluster with a command similar to what's shown below. **Note** that
-this will also **delete** any resources that Crossplane has provisioned in the
-cloud provider if their `ReclaimPolicy` is set to `Delete`.
-
-After you have ensured that you are completely done with all your cloud provider
-resources, you can then run one of the commands below, depending on which cloud
-provider you are removing, to remove its provider from Crossplane:
-
-#### Uninstalling GCP
-
-```console
-kubectl delete -f provider-gcp.yaml
-```
-
-#### Uninstalling AWS
-
-```console
-kubectl delete -f provider-aws.yaml
-```
-
-#### Uninstalling Azure
-
-```console
-kubectl delete -f provider-azure.yaml
-```
-
-#### Uninstalling Rook
-
-```console
-kubectl delete -f provider-rook.yaml
-```
-
-## Uninstalling the Chart
-
-To uninstall/delete the `crossplane` deployment:
-
-```console
-helm delete --purge crossplane
-```
-
-That command removes all Kubernetes components associated with Crossplane,
-including all the custom resources and controllers.
-
-## Configuration
-
-The following tables lists the configurable parameters of the Crossplane chart
-and their default values.
-
-| Parameter | Description | Default |
-| -------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------ |
-| `image.repository` | Image | `crossplane/crossplane` |
-| `image.tag` | Image tag | `master` |
-| `image.pullPolicy` | Image pull policy | `Always` |
-| `imagePullSecrets` | Names of image pull secrets to use | `dockerhub` |
-| `replicas` | The number of replicas to run for the Crossplane operator | `1` |
-| `deploymentStrategy` | The deployment strategy for the Crossplane operator | `RollingUpdate` |
-| `clusterPackages.aws.deploy` | Deploy AWS package | `false`
-| `clusterPackages.aws.version` | AWS provider version to deploy | ``
-| `clusterPackages.gcp.deploy` | Deploy GCP package | `false`
-| `clusterPackages.gcp.version` | GCP provider version to deploy | ``
-| `clusterPackages.azure.deploy` | Deploy Azure package | `false`
-| `clusterPackages.azure.version` | Azure provider version to deploy | ``
-| `clusterPackages.rook.deploy` | Deploy Rook package | `false`
-| `clusterPackages.rook.version` | Rook provider version to deploy | ``
-| `personas.deploy` | Install roles and bindings for Crossplane user personas | `true`
-| `templateStacks.enabled` | Enable experimental template stacks support | `true`
-| `templateStacks.controllerImage` | Template Stack controller image | `crossplane/templating-controller:v0.2.1`
-| `priorityClassName ` | Priority class name for crossplane and package manager pods | `""`
-| `resourcesCrossplane.limits.cpu` | CPU resource limits for Crossplane | `100m`
-| `resourcesCrossplane.limits.memory` | Memory resource limits for Crossplane | `512Mi`
-| `resourcesCrossplane.requests.cpu` | CPU resource requests for Crossplane | `100m`
-| `resourcesCrossplane.requests.memory` | Memory resource requests for Crossplane | `256Mi`
-| `resourcesPackageManager.limits.cpu` | CPU resource limits for PackageManager | `100m`
-| `resourcesPackageManager.limits.memory` | Memory resource limits for PackageManager | `512Mi`
-| `resourcesPackageManager.requests.cpu` | CPU resource requests for PackageManager | `100m`
-| `resourcesPackageManager.requests.memory` | Memory resource requests for PackageManager | `256Mi`
-| `forceImagePullPolicy` | Force the named ImagePullPolicy on Package install and containers | `""`
-| `insecureAllowAllApigroups` | Enable core Kubernetes API group permissions for Packages. When enabled, Packages may declare dependency on core Kubernetes API types.) | `false` |
-| `insecurePassFullDeployment` | Enable packages to pass their full deployment, including security context. When omitted, Package controller deployments will have security context removed and all containers will have `privileged` and `allowPrivilegeEscalation` set to `false`, and `runAsNonRoot` set to `true`. | `false` |
-| `insecureInstallJob` | Enable package install jobs to run as root. When omitted, Package install jobs will have security context removed and all containers will have `privileged` and `allowPrivilegeEscalation` set to `false`, and `runAsNonRoot` set to `true`. | `false` |
-
-### Command Line
-
-You can pass the settings with helm command line parameters. Specify each
-parameter using the `--set key=value[,key=value]` argument to `helm install`.
-For example, the following command will install Crossplane with an image pull
-policy of `IfNotPresent`.
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane --set image.pullPolicy=IfNotPresent
-```
-
-### Settings File
-
-Alternatively, a yaml file that specifies the values for the above parameters
-(`values.yaml`) can be provided while installing the chart.
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane -f values.yaml
-```
-
-Here are the sample settings to get you started.
-
-```yaml
-replicas: 1
-
-deploymentStrategy: RollingUpdate
-
-image:
- repository: crossplane/crossplane
- tag: master
- pullPolicy: Always
-
-imagePullSecrets:
-- dockerhub
-```
-
-
-
-[Kubernetes cluster]: https://kubernetes.io/docs/setup/
-[Minikube]: https://kubernetes.io/docs/tasks/tools/install-minikube/
-[Helm]: https://docs.helm.sh/using_helm/
diff --git a/docs/v0.11/reference/learn_more.md b/docs/v0.11/reference/learn_more.md
deleted file mode 100644
index 40d23292..00000000
--- a/docs/v0.11/reference/learn_more.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: Learn More
-toc: true
-weight: 304
-indent: true
----
-
-# Learn More
-
-If you have any questions, please drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us]!
-
-***Learn more about using Crossplane***
- - [GitLab deploys into multiple clouds from kubectl using Crossplane](https://about.gitlab.com/2019/05/20/gitlab-first-deployed-kubernetes-api-to-multiple-clouds/)
- - [CNCF Talks & Community Presentations](https://www.youtube.com/playlist?list=PL510POnNVaaZJj9OG6PbgsZvgYbhwJRyE)
- - [Software Engineering Daily - Intro Podcast](https://softwareengineeringdaily.com/2019/01/02/crossplane-multicloud-control-plane-with-bassam-tabbara/)
- - [Crossplane Architecture](https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit?usp=sharing)
- - [Latest Design Docs](https://github.com/crossplane/crossplane/tree/master/design)
- - [Roadmap](https://github.com/crossplane/crossplane/blob/master/ROADMAP.md)
-
-***Writing Kubernetes controllers to extend Crossplane***
- - [Keep the Space Shuttle Flying: Writing Robust Operators](https://www.youtube.com/watch?v=uf97lOApOv8)
- - [Best practices for building Kubernetes Operators](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)
- - [Programming Kubernetes Book](https://www.oreilly.com/library/view/programming-kubernetes/9781492047094/)
- - [Crossplane Reconciler Patterns](https://github.com/crossplane/crossplane/blob/master/design/design-doc-reconciler-patterns.md)
- - [Contributor Guide](https://github.com/crossplane/crossplane/blob/master/CONTRIBUTING.md)
-
-***Join the growing Crossplane community and get involved!***
-- Join our [Community Slack](https://slack.crossplane.io/)!
-- Submit an issue on [GitHub](https://github.com/crossplane/crossplane)
-- Attend our bi-weekly [Community Meeting](https://github.com/crossplane/crossplane#community-meeting)
-- Join our bi-weekly live stream: [The Binding Status](https://github.com/crossplane/tbs)
-- Subscribe to our [YouTube Channel](https://www.youtube.com/channel/UC19FgzMBMqBro361HbE46Fw)
-- Drop us a note on Twitter: [@crossplane_io](https://twitter.com/crossplane_io)
-- Email us: [info@crossplane.io](mailto:info@crossplane.io)
-
-
-
-[join-crossplane-slack]: https://slack.crossplane.io
-[contact-us]: https://github.com/crossplane/crossplane#contact
diff --git a/docs/v0.11/reference/overview.md b/docs/v0.11/reference/overview.md
deleted file mode 100644
index 3376f8c9..00000000
--- a/docs/v0.11/reference/overview.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Reference
-toc: true
-weight: 300
----
-
-# Overview
-
-The reference documentation includes answers to frequently asked questions, information about similar projects, and links to resources that can help you learn more about Crossplane and Kubernetes. If you have additional information that you think would be valuable for the community, please feel free to [open a pull request]() and add it.
-
-1. [Install]
-1. [Configure]
-1. [Troubleshoot]
-1. [Learn More]
-
-
-
-[Install]: install.md
-[Configure]: configure.md
-[Troubleshoot]: troubleshoot.md
-[Learn More]: learn_more.md
\ No newline at end of file
diff --git a/docs/v0.11/reference/troubleshoot.md b/docs/v0.11/reference/troubleshoot.md
deleted file mode 100644
index 44857359..00000000
--- a/docs/v0.11/reference/troubleshoot.md
+++ /dev/null
@@ -1,262 +0,0 @@
----
-title: Troubleshoot
-toc: true
-weight: 303
-indent: true
----
-
-# Troubleshooting
-
-* [Using the trace command]
-* [Resource Status and Conditions]
-* [Crossplane Logs]
-* [Pausing Crossplane]
-* [Deleting a Resource Hangs]
-* [Host-Aware Resource Debugging]
-
-## Using the trace command
-
-The [Crossplane CLI] trace command provides a holistic view for a particular
-object and related ones to ease debugging and troubleshooting process. It finds
-the relevant Crossplane resources for a given one and provides detailed
-information as well as an overview indicating what could be wrong.
-
-Usage:
-```
-kubectl crossplane trace TYPE[.GROUP] NAME [-n| --namespace NAMESPACE] [--kubeconfig KUBECONFIG] [-o| --outputFormat dot]
-```
-
-Examples:
-```
-# Trace a KubernetesApplication
-kubectl crossplane trace KubernetesApplication wordpress-app-83f04457-0b1b-4532-9691-f55cf6c0da6e -n app-project1-dev
-
-# Trace a MySQLInstance
-kubectl crossplane trace MySQLInstance wordpress-mysql-83f04457-0b1b-4532-9691-f55cf6c0da6e -n app-project1-dev
-```
-
-For more information, see [the trace command documentation].
-
-## Resource Status and Conditions
-
-Most Crossplane resources have a `status` section that can represent the current
-state of that particular resource. Running `kubectl describe` against a
-Crossplane resource will frequently give insightful information about its
-condition. For example, to determine the status of a MySQLInstance resource
-claim, run:
-
-```shell
-kubectl -n app-project1-dev describe mysqlinstance mysql-claim
-```
-
-This should produce output that includes:
-
-```console
-Status:
- Conditions:
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Managed claim is waiting for managed resource to become bindable
- Status: False
- Type: Ready
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Successfully reconciled managed resource
- Status: True
- Type: Synced
-```
-
-Most Crossplane resources set exactly two condition types; `Ready` and `Synced`.
-`Ready` represents the availability of the resource itself - whether it is
-creating, deleting, available, unavailable, binding, etc. `Synced` represents
-the success of the most recent attempt to 'reconcile' the _desired_ state of the
-resource with its _actual_ state. The `Synced` condition is the first place you
-should look when a Crossplane resource is not behaving as expected.
-
-## Crossplane Logs
-
-The next place to look to get more information or investigate a failure would be
-in the Crossplane pod logs, which should be running in the `crossplane-system`
-namespace. To get the current Crossplane logs, run the following:
-
-```shell
-kubectl -n crossplane-system logs -lapp=crossplane
-```
-
-Remember that much of Crossplane's functionality is provided by Stacks. You can
-use `kubectl logs` to view Stack logs too, though Stacks may not run in the
-`crossplane-system` namespace.
-
-## Pausing Crossplane
-
-Sometimes, for example when you encounter a bug. it can be useful to pause
-Crossplane if you want to stop it from actively attempting to manage your
-resources. To pause Crossplane without deleting all of its resources, run the
-following command to simply scale down its deployment:
-
-```bash
-kubectl -n crossplane-system scale --replicas=0 deployment/crossplane
-```
-
-Once you have been able to rectify the problem or smooth things out, you can
-unpause Crossplane simply by scaling its deployment back up:
-
-```bash
-kubectl -n crossplane-system scale --replicas=1 deployment/crossplane
-```
-
-Remember that much of Crossplane's functionality is provided by Stacks. You can
-use `kubectl scale` to pause Stack pods too, though Stacks may not run in the
-`crossplane-system` namespace.
-
-## Deleting a Resource Hangs
-
-The resources that Crossplane manages will automatically be cleaned up so as not
-to leave anything running behind. This is accomplished by using finalizers, but
-in certain scenarios the finalizer can prevent the Kubernetes object from
-getting deleted.
-
-To deal with this, we essentially want to patch the object to remove its
-finalizer, which will then allow it to be deleted completely. Note that this
-won't necessarily delete the external resource that Crossplane was managing, so
-you will want to go to your cloud provider's console and look there for any
-lingering resources to clean up.
-
-In general, a finalizer can be removed from an object with this command:
-
-```console
-kubectl patch -p '{"metadata":{"finalizers": []}}' --type=merge
-```
-
-For example, for a Workload object (`workloads.compute.crossplane.io`) named
-`test-workload`, you can remove its finalizer with:
-
-```console
-kubectl patch workloads.compute.crossplane.io test-workload -p '{"metadata":{"finalizers": []}}' --type=merge
-```
-
-## Host-Aware Resource Debugging
-
-Stack resources (including the Stack, service accounts, deployments, and jobs)
-are usually easy to identify by name. These resource names are based on the name
-used in the StackInstall or Stack resource.
-
-### Resource Location
-
-In a host-aware configuration, these resources may be divided between the host
-and the tenant.
-
-The host, which runs the Stack controller, does not need (or get) the CRDs used
-by the Stack controller. The Stack controller connects to the tenant Kubernetes
-API to watch the owned types of the Stack (which is why the CRDs are only
-installed on the Tenant).
-
-Kind | Name | Place
----- | ----- | ------
-pod | crossplane | Host (ns: tenantFoo-system)
-pod | stack-manager | Host (ns: tenantFoo-system)
-job | (stack installjob) | Host (ns: tenantFoo-controllers)
-pod | (stack controller) | Host (ns: tenantFoo-controllers)
-
-Kind | Name | Place
----- | ----- | ------
-crd | Stack, SI, CSI | Tenant
-Stack | wordpress | Tenant
-StackInstall | wordpress | Tenant
-crd | KubernetesEngine, MysqlInstance, ... | Tenant
-crd | GKEInstance, CloudSQLInstance, ... | Tenant
-(rbac) | (stack controller) | Tenant
-(rbac) | (workspace owner, crossplane-admin) | Tenant
-(rbac) | (stack:namespace:1.2.3:admin) | Tenant
-crd | WordpressInstance | Tenant
-WordpressInstance | wp-instance | Tenant
-KubernetesApplication | wp-instance | Tenant
-
-Kind | Name | Place
----- | ----- | ------
-pod | wp-instance (from KubernetesAplication) | New Cluster
-
-### Name Truncation
-
-In some cases, the full name of a Stack resource, which could be up to 253
-characters long, can not be represented in the created resources. For example,
-jobs and deployment names may not exceed 63 characters because these names are
-turned into resource label values which impose a 63 character limit. Stack
-created resources whose names would otherwise not be permitted in the Kubernetes
-API will be truncated with a unique suffix.
-
-When running the Stack Manager in host-aware mode, tenant stack resources
-created in the host controller namespace generally reuse the Stack names:
-"{tenant namespace}.{tenant name}". In order to avoid the name length
-restrictions, these resources may be truncated at either or both of the
-namespace segment or over the entire name. In these cases resource labels,
-owner references, and annotations should be consulted to identify the
-responsible Stack.
-
-* [Relationship Labels]
-* [Owner References]
-* Annotations: `tenant.crossplane.io/{singular}-name` and
- `tenant.crossplane.io/{singular}-namespace` (_singular_ may be `stackinstall`,
- `clusterstackinstall` or `stack`)
-
-#### Example
-
-Long resource names may be present on the tenant.
-
-```console
-$ name=stack-with-a-really-long-resource-name-so-long-that-it-will-be-truncated
-$ ns=this-is-just-a-really-long-namespace-name-at-the-character-max
-$ kubectl create ns $ns
-$ kubectl crossplane stack install --namespace $ns crossplane/sample-stack-wordpress:0.1.1 $name
-```
-
-When used as host resource names, the stack namespace and stack are concatenated
- to form host names, as well as labels. These resource names and label values
- must be truncated to fit the 63 character limit on label values.
-
-```console
-$ kubectl --context=crossplane-host -n tenant-controllers get job -o yaml
-apiVersion: v1
-items:
-- apiVersion: batch/v1
- kind: Job
- metadata:
- annotations:
- tenant.crossplane.io/stackinstall-name: stack-with-a-really-long-resource-name-so-long-that-it-will-be-truncated
- tenant.crossplane.io/stackinstall-namespace: this-is-just-a-really-long-namespace-name-at-the-character-max
- creationTimestamp: "2020-03-20T17:06:25Z"
- labels:
- core.crossplane.io/parent-group: stacks.crossplane.io
- core.crossplane.io/parent-kind: StackInstall
- core.crossplane.io/parent-name: stack-with-a-really-long-resource-name-so-long-that-it-wi-alqdw
- core.crossplane.io/parent-namespace: this-is-just-a-really-long-namespace-name-at-the-character-max
- core.crossplane.io/parent-uid: 596705e4-a28e-47c9-a907-d2732f07a85e
- core.crossplane.io/parent-version: v1alpha1
- name: this-is-just-a-really-long-namespace-name-at-the-characte-egoav
- namespace: tenant-controllers
- spec:
- backoffLimit: 0
- completions: 1
- parallelism: 1
- selector:
- matchLabels:
- controller-uid: 8f290bf2-8c91-494a-a76b-27c2ccb9e0a8
- template:
- metadata:
- creationTimestamp: null
- labels:
- controller-uid: 8f290bf2-8c91-494a-a76b-27c2ccb9e0a8
- job-name: this-is-just-a-really-long-namespace-name-at-the-characte-egoav
- ...
-```
-
-
-
-[Using the trace command]: #using-the-trace-command
-[Resource Status and Conditions]: #resource-status-and-conditions
-[Crossplane Logs]: #crossplane-logs
-[Pausing Crossplane]: #pausing-crossplane
-[Deleting a Resource Hangs]: #deleting-a-resource-hangs
-[Host-Aware Resource Debugging]: #host-aware-resource-debugging
-[Crossplane CLI]: https://github.com/crossplane/crossplane-cli
-[the trace command documentation]: https://github.com/crossplane/crossplane-cli/tree/master/docs/trace-command.md
-[Relationship Labels]: https://github.com/crossplane/crossplane/blob/master/design/one-pager-stack-relationship-labels.md
-[Owner References]: https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents
diff --git a/docs/v0.11/release/release-process.md b/docs/v0.11/release/release-process.md
deleted file mode 100644
index 215a59ea..00000000
--- a/docs/v0.11/release/release-process.md
+++ /dev/null
@@ -1,485 +0,0 @@
-# Release Process
-
-This document is meant to be a complete end-to-end guide for how to release new
-versions of software for Crossplane and its related projects.
-
-## tl;dr Process Overview
-
-All the details are available in the sections below, but we'll start this guide
-with a very high level sequential overview for how to run the release process.
-
-1. **feature freeze**: Merge all completed features into master branches of all
- repos to begin "feature freeze" period
-1. **API docs/user guides**: Regenerate API docs and update all user guides with
- current content for scenarios included in the release
-1. **release crossplane-runtime**: Tag and release a new version of
- crossplane-runtime using the GitHub UI.
-1. **pin crossplane dependencies**: Update the go modules of core crossplane in
- master to depend on the newly released version of crossplane-runtime.
-1. **pre-release tag crossplane**: Run tag pipeline to tag the start of
- pre-releases in master in the crossplane repo
-1. **branch crossplane**: Create a new release branch using the GitHub UI for
- the crossplane repo
-1. **crossplane release branch prep**: In Crossplane's release branch, update
- all examples, docs, and integration tests to update references and versions,
- including the yet to be released versions of providers and stacks.
-1. **tag**: Run the tag pipeline to tag Crossplane's release branch with an
- official semver
-1. **release providers**: Run the release process for each **provider** that we
- maintain
- 1. **pin dependencies**: Update the go modules of each provider repo to
- depend on the new version of crossplane and crossplane-runtime.
- 1. **pre-release tag**: Run tag pipeline to tag the start of pre-releases in
- **master** of each provider repo
- 1. **branch**: Create a new release branch using the GitHub UI for the
- provider repo
- 1. **release branch prep**: In the release branch, update all examples,
- docs, and integration tests to update references and versions
- 1. **test** Test builds from the release branch, fix any critical bugs that
- are found
- 1. **tag**: Run the tag pipeline to tag the release branch with an official
- semver
- 1. **build/publish**: Run build pipeline to publish build with official
- semver
-1. **release template stacks**: Run the release process for each **template
- stack** that we maintain. Note that the process for template stacks is
- slightly different from the stack release process.
- 1. **test** Test builds from the release branch (typically `master`), fix
- any critical bugs that are found
- 1. **version**: Update all version information in the docs, as appropriate
- 1. **tag**: Run the tag pipeline to tag the release branch with an official
- semver
- 1. **build/publish**: Run the publish pipeline to publish build with
- official semver
-1. **build/publish**: Run build pipeline to publish Crossplane build from
- release branch with official semver
-1. **verify**: Verify all artifacts have been published successfully, perform
- sanity testing
-1. **promote**: Run promote pipelines on all repos to promote releases to
- desired channel(s)
-1. **release notes**: Publish well authored and complete release notes on GitHub
-1. **announce**: Announce the release on Twitter, Slack, etc.
-
-## Detailed Process
-
-This section will walk through the release process in more fine grained and
-prescriptive detail.
-
-### Scope
-
-This document will cover the release process for all of the repositories that
-the Crossplane team maintains and publishes regular versioned artifacts from.
-This set of repositories covers both core Crossplane and the set of Providers,
-Stacks, and Apps that Crossplane currently maintains:
-
-* [`crossplane`](https://github.com/crossplane/crossplane)
-* [`provider-gcp`](https://github.com/crossplane/provider-gcp)
-* [`provider-aws`](https://github.com/crossplane/provider-aws)
-* [`provider-azure`](https://github.com/crossplane/provider-azure)
-* [`provider-rook`](https://github.com/crossplane/provider-rook)
-* [`stack-minimal-gcp`](https://github.com/crossplane/stack-minimal-gcp)
-* [`stack-minimal-aws`](https://github.com/crossplane/stack-minimal-aws)
-* [`stack-minimal-azure`](https://github.com/crossplane/stack-minimal-azure)
-* [`app-wordpress`](https://github.com/crossplane/app-wordpress)
-
-The release process for Providers is almost identical to that of core Crossplane
-because they use the same [shared build
-logic](https://github.com/upbound/build/). The steps in this guide will apply
-to all repositories listed above unless otherwise mentioned.
-
-### Feature Freeze
-
-Feature freeze should be performed on all repos. In order to start the feature
-freeze period, the following conditions should be met:
-
-* All expected features should be
- ["complete"](https://github.com/crossplane/crossplane/blob/master/design/one-pager-definition-of-done.md)
- and merged into master. This includes user guides, examples, API documentation
- via [crossdocs](https://github.com/negz/crossdocs/), and test updates.
-* All issues in the
- [milestone](https://github.com/crossplane/crossplane/milestones) should be
- closed
-* Sanity testing has been performed on `master`
-
-After these conditions are met, the feature freeze begins by creating the RC tag
-and the release branch.
-
-### Pin Dependencies
-
-It is a best practice to release Crossplane projects with "pinned" dependencies
-to specific versions of other upstream Crossplane projects. For example, after
-crossplane-runtime has been released, we want to update the main Crossplane repo
-to use that specific released version.
-
-To update a dependency to a specific version, simply edit the `go.mod` file to
-point to the desired version, then run `go mod tidy`.
-
-### Pre-release Tag
-
-The next step is to create the pre-release tag for the `HEAD` commit in
-`master`. This tag serves as an indication of when the release was branched
-from master and is also important for generating future versions of `master`
-builds since that [versioning
-process](https://github.com/upbound/build/blob/master/makelib/common.mk#L182-L196)
-is based on `git describe --tags`.
-
-> **NOTE:** The `tag` pipeline does not yet support additional (pre-release)
-tags in the version number, such as `v0.5.0-rc`.
-[#330](https://github.com/crossplane/crossplane/issues/330) will be resolved
-when this functionality is available. In the meantime, **manually tagging and
-pushing to the repo is required**. Ignore the steps below about running the
-pipeline because the pipeline won't work.
-
-To accomplish this, run the `tag` pipeline for each repo on the `master` branch.
-You will be prompted to enter the `version` for the tag and the `commit` hash to
-tag. It's possible to leave the `commit` field blank to default to tagging
-`HEAD`.
-
-Since this tag will essentially be the start of pre-releases working towards the
-**next** version, the `version` should be the **next** release number, plus a
-trailing tag to indicate it is a pre-release. The current convention is to use
-`*-rc`. For example, when we are releasing the `v0.9.0` release and we are
-ready for master to start working towards the **next** release of `v0.10.0`, we
-would make the tag `v0.10.0-rc`
-
-After the tag pipeline has succeeded, verify in the [GitHub
-UI](https://github.com/crossplane/crossplane/tags) that the tag was successfully
-applied to the correct commit.
-
-### Create Release Branch
-
-Creating the release branch can be done within the [GitHub
-UI](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-and-deleting-branches-within-your-repository).
-Basically, you just use the branch selector drop down and type in the name of
-the new release branch, e.g. `release-0.5`. Release branch names always follow
-the convention of `release-[minor-semver]`.
-
-If this is the first ever release branch being created in a repo (uncommon), you
-should also set up branch protection rules for the `release-*` pattern. You can
-find existing examples in the [Crossplane repo
-settings](https://github.com/crossplane/crossplane/settings/branches).
-
-At this point, the `HEAD` commit in the release branch will be our release
-candidate. The build pipeline will automatically be started due to the create
-branch event, so we can start to perform testing on this build. Note that it
-should be the exact same as what is currently in `master` since they are using
-the same commit and have the same tag. Also note that this is not the official
-release build since we have not made the official release tag yet (e.g.
-`v0.5.0`).
-
-The `master` branch can now be opened for new features since we have a safe
-release branch to continue bug fixes and improvements for the release itself.
-Essentially, `master` is free to now diverge from the release branch.
-
-### Release Branch Prep
-
-In the core Crossplane repository, we need to update the release branch docs and
-examples to point to the new versions that we will be releasing soon.
-
-* Documentation, such as [Installation
- instructions](https://github.com/crossplane/crossplane/blob/release-0.9/docs/install.md#installing-infrastructure-providers),
- and
- [Stack](https://github.com/crossplane/crossplane/blob/release-0.9/docs/stack.md)
- and
- [App](https://github.com/crossplane/crossplane/blob/release-0.9/docs/app.md)
- guides.
- * searching for `:master` will help a lot here
-* Examples, such as [`StackInstall` yaml
- files](https://github.com/crossplane/crossplane/tree/release-0.9/cluster/examples/provider)
-* [Helm chart
- defaults](https://github.com/crossplane/crossplane/blob/release-0.9/cluster/charts/crossplane/values.yaml.tmpl),
- ensure all `values.yaml.tmpl` files are updated.
- * provider versions
- * `templating-controller` version (if a new version is available and ready)
-
-#### Bug Fixes in Release Branch
-
-During our testing of the release candidate, we may find issues or bugs that we
-triage and decide we want to fix before the release goes out. In order to fix a
-bug in the release branch, the following process is recommended:
-
-1. Make the bug fix into `master` first through the normal PR process
- 1. If the applicable code has already been removed from `master` then simply
- fix the bug directly in the release branch by opening a PR directly
- against the release branch
-1. Backport the fix by performing a cherry-pick of the fix's commit hash
- (**not** the merge commit) from `master` into the release branch. For
- example, to backport a fix from master to `v0.5.0`, something like the
- following should be used:
-
- ```console
- git fetch --all
- git checkout -b release-0.5 upstream/release-0.5
- git cherry-pick -x
- ```
-
-1. Open a PR with the cherry-pick commit targeting the release-branch
-
-After all bugs have been fixed and backported to the release branch, we can move
-on to tagging the final release commit.
-
-### Tag Core Crossplane
-
-Similar to running the `tag` pipelines for each stack, now it's time to run the
-[`tag`
-pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fcrossplane%2Fcrossplane-tag/branches)
-for core Crossplane. In fact, the [instructions](#stack-tag-pipeline) are
-exactly the same:
-
-Run the tag pipeline by clicking the Run button in the Jenkins UI in the correct
-release branch's row. You will be prompted for the version you are tagging,
-e.g., `v0.5.0` as well as the commit hash. The hash is optional and if you leave
-it blank it will default to `HEAD` of the branch, which is what you want.
-
-> **Note:** The first time you run a pipeline on a new branch, you won't get
-> prompted for the values to input. The build will quickly fail and then you can
-> run (not replay) it a second time to be prompted. This is a Jenkins bug that
-> is tracked by [#41929](https://issues.jenkins-ci.org/browse/JENKINS-41929) and
-> has been open for almost 3 years, so don't hold your breath.
-
-### Draft Release Notes
-
-We're getting close to starting the official release, so you should take this
-opportunity to draft up the release notes. You can create a [new release draft
-here](https://github.com/crossplane/crossplane/releases/new). Make sure you
-select "This is a pre-release" and hit "Save draft" when you are ready to share
-and collect feedback. Do **not** hit "Publish release" yet.
-
-You can see and follow the template and structure from [previous
-releases](https://github.com/crossplane/crossplane/releases).
-
-### Provider Release Process
-
-This section will walk through how to release the Providers and does not
-directly apply to core Crossplane.
-
-#### Pin Provider Dependencies
-
-Similar to core crossplane, each provider should have its crossplane related
-dependencies pinned to the versions that we are releasing. In the **master**
-branch of each provider repo, update the `crossplane` and `crossplane-runtime`
-dependencies to the versions we are releasing.
-
-Simply edit `go.mod` with the new versions, then run `go mod tidy`.
-
-The providers also depend on `crossplane-tools`, but that currently does not
-have official releases, so in practice should be using the latest from master.
-
-#### Provider Pre-release tag
-
-Follow the same steps that we did for core crossplane to tag the **master**
-branch of each provider repo with a pre-release tag for the **next** version.
-
-These steps can be found in the [pre-release tag section](#pre-release-tag).
-
-#### Create Provider Release Branches
-
-Now create a release branch for each of the provider repos using the GitHub UI.
-The steps are the same as what we did to [create the release
-branch](#create-release-branch) for core crossplane.
-
-#### Provider Release Branch Prep
-
-In the **release branch** for each provider, you should update the version tags
-and metadata in:
-
-* `integration_tests.sh` - `STACK_IMAGE`
-* `ClusterStackInstall` sample and example yaml files
-* `*.resource.yaml` - docs links in markdown
- * Not all of these `*.resource.yaml` files have links that need to be updated,
- they are infrequent and inconsistent
-
-Searching for `:master` will be a big help here.
-
-#### Provider Tag, Build, and Publish
-
-Now that the Providers are all tested and their version metadata has been
-updated, it's time to tag the release branch with the official version tag. You
-can do this by running the `tag` pipeline on the release branch of each
-Provider:
-
-* [`provider-gcp` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-gcp-pipelines%2Fprovider-gcp-tag/branches)
-* [`provider-aws` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-aws-pipelines%2Fprovider-aws-tag/branches/)
-* [`provider-azure` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-azure-pipelines%2Fprovider-azure-tag/branches/)
-* [`provider-rook` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-rook-pipelines%2Fprovider-rook-tag/branches/)
-
-* Run the `tag` pipeline on the release branch
-* Enter the version and commit hash (leave blank for `HEAD`)
-* The first time you run on a new release branch, you won't be prompted and the
- build will fail, just run (not replay) a second time
-
-After the tag pipeline has been run and the release branch has been tagged, you
-can run the normal build pipeline on the release branch. This will kick off the
-official release build and upon success, all release artifacts will be
-officially published.
-
-After the release build succeeds, verify that the correctly versioned Provider
-images have been pushed to Docker Hub.
-
-### Template Stack Release Process
-
-The Template Stacks we maintain are slightly different from the controller-based
-stacks that we maintain. Their processes are similar but a little simpler. This
-section will walk through how to release the Template Stacks themselves, and
-does not directly apply to core Crossplane.
-
-For Template Stacks, we do not use release branches unless we need to make a
-patch release. In the future we may need a more robust branching strategy, but
-for now we are not using branches because it is simpler.
-
-Note that Template Stacks **do not** require any code changes to update their
-version. A slight exception to this is for their `behavior.yaml` files, which
-should have the `controllerImage` field updated if a new version of the
-`templating-controller` is available and ready.
-
-### Template Stack Tag And Publish Pipeline
-
-Here is the list of all template stacks:
-
-* [`stack-minimal-gcp`](https://github.com/crossplane/stack-minimal-gcp)
-* [`stack-minimal-aws`](https://github.com/crossplane/stack-minimal-aws)
-* [`stack-minimal-azure`](https://github.com/crossplane/stack-minimal-azure)
-* [`app-wordpress`](https://github.com/crossplane/app-wordpress)
-
-Each one should be released as part of a complete release, using the
-instructions below. To read even more about the template stack release process,
-see [the release section of this
-document](https://github.com/crossplane/cicd/blob/master/docs/pipelines.md#how-do-i-cut-a-release)
-
-Note that there's also the
-[`templating-controller`](https://github.com/crossplane/templating-controller),
-which supports template stacks. It is possible that it **may** need to be
-released as well, but typically is released independently from Crossplane.
-
-#### Tag the Template Stack
-
-Once a template stack is tested and ready for cutting a semver release, we will
-want to tag the repository with the new release version. In most cases, to get
-the version, take a look at the most recent tag in the repo, and increment the
-minor version. For example, if the most recent tag was `v0.2.0`, the new tag
-should be `v0.3.0`.
-
-Run the template stack's tag job on Jenkins, against the `master` branch. Enter
-in the new tag to use. If the current release candidate is not the head of
-`master`, enter in the commit to tag.
-
-You can find the tag pipeline for the individual stack by going to the
-[crossplane org in Jenkins](https://jenkinsci.upbound.io/job/crossplane/),
-finding the folder with the same name as the template stack, and then going to
-the `tag` job group. Then going to the `master` branch job under the group. For
-example, here is [a link to the stack-minimal-gcp tag job for
-master](https://jenkinsci.upbound.io/job/crossplane/job/stack-minimal-gcp/job/tag/job/master/).
-
-> **Note:** The first time you run a pipeline on a new branch, you won't get
-> prompted for the values to input and the build will fail. See details in the
-> [tagging core crossplane section](#tag-core-crossplane).
-
-#### Publish the Template Stack
-
-After the tag pipeline has been run and the repository has been tagged, you can
-run the `publish` job for the template stack. For example, here's a [link to the
-stack-minimal-gcp publish
-job](https://jenkinsci.upbound.io/job/crossplane/job/stack-minimal-gcp/job/publish/job/master/).
-This will kick off the official release build and upon success, all release
-artifacts will be officially published. This should also be run from the
-`master` branch in most cases. Or, if a release branch was used, from the
-release branch. The tag parameter should be used, and the tag for the current
-release should be used. For example, if the new tag we created was `v0.3.0`, we
-would want to provide `v0.3.0` for the `publish` job.
-
-#### Verify the Template Stack was Published
-
-After the publish build succeeds, verify that the correctly versioned template
-stack images have been pushed to Docker Hub.
-
-### Template Stack Patch Releases
-
-To do a patch release with a template stack, create a release branch from the
-minor version tag on the `master` branch, if a release branch doesn't already
-exist. Then, the regular tagging and publishing process for template stacks can
-be followed, incrementing the patch version to get the new release tag.
-
-### Build and Release Core Crossplane
-
-After the providers, stacks, and apps have all been released, ensure the [normal
-build
-pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fcrossplane%2Fbuild/branches)
-is run on the release branch for core crossplane. This will be the official
-release build with an official version number and all of its release artifacts
-will be published.
-
-After the pipeline runs successfully, you should verify that all artifacts have
-been published to:
-
-* [Docker Hub](https://hub.docker.com/repository/docker/crossplane/crossplane)
-* [S3 releases bucket](https://releases.crossplane.io/)
-* [Helm chart repository](https://charts.crossplane.io/)
-* [Docs website](https://crossplane.io/docs/latest)
-
-### Promotion
-
-If everything looks good with the official versioned release that we just
-published, we can go ahead and run the `promote` pipeline for the core
-crossplane and provider repos. This is a very quick pipeline that doesn't
-rebuild anything, it simply makes metadata changes to the published release to
-also include the release in the channel of your choice.
-
-Currently, we only support the `master` and `alpha` channels.
-
-For the core crossplane and each provider repo, run the `promote` pipeline on
-the release branch and input the version you would like to promote (e.g.
-`v0.5.0`) and the channel you'd like to promote it to. The first time you run
-this pipeline on a new release branch, you will not be prompted for values, so
-the pipeline will fail. Just run (not replay) it a second time to be prompted.
-
-* Run `promote` pipeline for `master` channel
-* Run `promote` pipeline for `alpha` channel
-
-After the `promote` pipelines have succeeded, verify on DockerHub and the Helm
-chart repository that the release has been promoted to the right channels.
-
-### Publish Release Notes
-
-Now that the release has been published and verified, you can publish the
-[release notes](https://github.com/crossplane/crossplane/releases) that you
-drafted earlier. After incorporating all feedback, you can now click on the
-"Publish release" button.
-
-This will send an email notification with the release notes to all watchers of
-the repo.
-
-### Announce Release
-
-We have completed the entire release, so it's now time to announce it to the
-world. Using the [@crossplane_io](https://twitter.com/crossplane_io) Twitter
-account, tweet about the new release and blog. You'll see examples from the
-previous releases, such as this tweet for
-[v0.4](https://twitter.com/crossplane_io/status/1189307636350705664).
-
-Post a link to this tweet on the Slack #announcements channel, then copy a link
-to that and post it in the #general channel.
-
-### Patch Releases
-
-We also have the ability to run patch releases to update previous releases that
-have already been published. These patch releases are always run from the last
-release branch, we do **not** create a new release branch for a patch release.
-
-The basic flow is **very** similar to a normal release, but with a few less
-steps. Please refer to details for each step in the sections above.
-
-* Fix any bugs in `master` first and then `cherry-pick -x` to the release branch
- * If `master` has already removed the relevant code then make your fix
- directly in the release branch
-* After all testing on the release branch look good and any docs/examples/tests
- have been updated with the new version number, run the `tag` pipeline on the
- release branch with the new patch version (e.g. `v0.5.1`)
-* Run the normal build pipeline on the release branch to build and publish the
- release
-* Publish release notes
-* Run promote pipeline to promote the patch release to the `master` and `alpha`
- channels
diff --git a/docs/v0.11/snippets/provision/alibaba.yaml b/docs/v0.11/snippets/provision/alibaba.yaml
deleted file mode 100644
index 125a45c6..00000000
--- a/docs/v0.11/snippets/provision/alibaba.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-apiVersion: database.alibaba.crossplane.io/v1alpha1
-kind: RDSInstance
-metadata:
- name: rdspostgresql
-spec:
- forProvider:
- engine: PostgreSQL
- engineVersion: "9.4"
- dbInstanceClass: rds.pg.s1.small
- dbInstanceStorageInGB: 20
- securityIPList: "0.0.0.0/0"
- masterUsername: "test123"
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: alibaba-rdspostgresql-conn
- providerRef:
- name: alibaba-provider
- reclaimPolicy: Delete
diff --git a/docs/v0.11/snippets/provision/aws.yaml b/docs/v0.11/snippets/provision/aws.yaml
deleted file mode 100644
index 8473eef5..00000000
--- a/docs/v0.11/snippets/provision/aws.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-apiVersion: database.aws.crossplane.io/v1beta1
-kind: RDSInstance
-metadata:
- name: rdspostgresql
-spec:
- forProvider:
- dbInstanceClass: db.t2.small
- masterUsername: masteruser
- allocatedStorage: 20
- engine: postgres
- engineVersion: "9.6"
- skipFinalSnapshotBeforeDeletion: true
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: aws-rdspostgresql-conn
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
diff --git a/docs/v0.11/snippets/provision/azure.yaml b/docs/v0.11/snippets/provision/azure.yaml
deleted file mode 100644
index d8302e2b..00000000
--- a/docs/v0.11/snippets/provision/azure.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
-apiVersion: azure.crossplane.io/v1alpha3
-kind: ResourceGroup
-metadata:
- name: sqlserverpostgresql-rg
-spec:
- location: West US 2
- reclaimPolicy: Delete
- providerRef:
- name: azure-provider
----
-apiVersion: database.azure.crossplane.io/v1beta1
-kind: PostgreSQLServer
-metadata:
- name: sqlserverpostgresql
-spec:
- forProvider:
- administratorLogin: myadmin
- resourceGroupNameRef:
- name: sqlserverpostgresql-rg
- location: West US 2
- sslEnforcement: Disabled
- version: "9.6"
- sku:
- tier: GeneralPurpose
- capacity: 2
- family: Gen5
- storageProfile:
- storageMB: 20480
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: sqlserverpostgresql-conn
- providerRef:
- name: azure-provider
- reclaimPolicy: Delete
diff --git a/docs/v0.11/snippets/provision/gcp.yaml b/docs/v0.11/snippets/provision/gcp.yaml
deleted file mode 100644
index 9c53acec..00000000
--- a/docs/v0.11/snippets/provision/gcp.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-apiVersion: database.gcp.crossplane.io/v1beta1
-kind: CloudSQLInstance
-metadata:
- name: cloudsqlpostgresql
-spec:
- forProvider:
- databaseVersion: POSTGRES_9_6
- region: us-central1
- settings:
- tier: db-custom-1-3840
- dataDiskType: PD_SSD
- dataDiskSizeGb: 10
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: cloudsqlpostgresql-conn
- providerRef:
- name: gcp-provider
- reclaimPolicy: Delete
diff --git a/docs/v0.11/snippets/publish/clusterrole.yaml b/docs/v0.11/snippets/publish/clusterrole.yaml
deleted file mode 100644
index 1b391c56..00000000
--- a/docs/v0.11/snippets/publish/clusterrole.yaml
+++ /dev/null
@@ -1,16 +0,0 @@
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: postgresqlinstances.database.example.org
- labels:
- rbac.crossplane.io/aggregate-to-crossplane: "true"
-rules:
-- apiGroups:
- - database.example.org
- resources:
- - postgresqlinstances
- - postgresqlinstances/status
- - postgresqlinstancerequirements
- - postgresqlinstancerequirements/status
- verbs:
- - "*"
diff --git a/docs/v0.11/snippets/publish/composition-alibaba.yaml b/docs/v0.11/snippets/publish/composition-alibaba.yaml
deleted file mode 100644
index 62aa42d3..00000000
--- a/docs/v0.11/snippets/publish/composition-alibaba.yaml
+++ /dev/null
@@ -1,44 +0,0 @@
----
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: Composition
-metadata:
- name: postgresqlinstances.alibaba.database.example.org
- labels:
- provider: alibaba
- guide: quickstart
-spec:
- writeConnectionSecretsToNamespace: crossplane-system
- reclaimPolicy: Delete
- from:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstance
- to:
- - base:
- apiVersion: database.alibaba.crossplane.io/v1alpha1
- kind: RDSInstance
- spec:
- forProvider:
- engine: PostgreSQL
- engineVersion: "9.4"
- dbInstanceClass: rds.pg.s1.small
- securityIPList: "0.0.0.0/0"
- masterUsername: "myuser"
- writeConnectionSecretToRef:
- namespace: crossplane-system
- providerRef:
- name: alibaba-provider
- reclaimPolicy: Delete
- patches:
- - fromFieldPath: "metadata.uid"
- toFieldPath: "spec.writeConnectionSecretToRef.name"
- transforms:
- - type: string
- string:
- fmt: "%s-postgresql"
- - fromFieldPath: "spec.parameters.storageGB"
- toFieldPath: "spec.forProvider.dbInstanceStorageInGB"
- connectionDetails:
- - fromConnectionSecretKey: username
- - fromConnectionSecretKey: password
- - fromConnectionSecretKey: endpoint
- - fromConnectionSecretKey: port
\ No newline at end of file
diff --git a/docs/v0.11/snippets/publish/composition-aws-with-vpc.yaml b/docs/v0.11/snippets/publish/composition-aws-with-vpc.yaml
deleted file mode 100644
index d1c9a044..00000000
--- a/docs/v0.11/snippets/publish/composition-aws-with-vpc.yaml
+++ /dev/null
@@ -1,163 +0,0 @@
----
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: Composition
-metadata:
- name: vpcpostgresqlinstances.aws.database.example.org
- labels:
- provider: aws
- guide: quickstart
- vpc: new
-spec:
- writeConnectionSecretsToNamespace: crossplane-system
- reclaimPolicy: Delete
- from:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstance
- to:
- - base:
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: VPC
- spec:
- cidrBlock: 192.168.0.0/16
- enableDnsSupport: true
- enableDnsHostNames: true
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: Subnet
- metadata:
- labels:
- zone: us-west-2a
- spec:
- cidrBlock: 192.168.64.0/18
- vpcIdSelector:
- matchControllerRef: true
- availabilityZone: us-west-2a
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: Subnet
- metadata:
- labels:
- zone: us-west-2b
- spec:
- cidrBlock: 192.168.128.0/18
- vpcIdSelector:
- matchControllerRef: true
- availabilityZone: us-west-2b
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: Subnet
- metadata:
- labels:
- zone: us-west-2c
- spec:
- cidrBlock: 192.168.192.0/18
- vpcIdSelector:
- matchControllerRef: true
- availabilityZone: us-west-2c
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: database.aws.crossplane.io/v1beta1
- kind: DBSubnetGroup
- spec:
- forProvider:
- description: An excellent formation of subnetworks.
- subnetIdSelector:
- matchControllerRef: true
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: InternetGateway
- spec:
- vpcIdSelector:
- matchControllerRef: true
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: RouteTable
- spec:
- vpcIdSelector:
- matchControllerRef: true
- routes:
- - destinationCidrBlock: 0.0.0.0/0
- gatewayIdSelector:
- matchControllerRef: true
- associations:
- - subnetIdSelector:
- matchLabels:
- zone: us-west-2a
- - subnetIdSelector:
- matchLabels:
- zone: us-west-2b
- - subnetIdSelector:
- matchLabels:
- zone: us-west-2c
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: SecurityGroup
- spec:
- vpcIdSelector:
- matchControllerRef: true
- groupName: crossplane-getting-started
- description: Allow access to PostgreSQL
- ingress:
- - fromPort: 5432
- toPort: 5432
- protocol: tcp
- cidrBlocks:
- - cidrIp: 0.0.0.0/0
- description: Everywhere
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: database.aws.crossplane.io/v1beta1
- kind: RDSInstance
- spec:
- forProvider:
- dbSubnetGroupNameSelector:
- matchControllerRef: true
- vpcSecurityGroupIDSelector:
- matchControllerRef: true
- dbInstanceClass: db.t2.small
- masterUsername: masteruser
- engine: postgres
- engineVersion: "9.6"
- skipFinalSnapshotBeforeDeletion: true
- publiclyAccessible: true
- writeConnectionSecretToRef:
- namespace: crossplane-system
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- patches:
- - fromFieldPath: "metadata.uid"
- toFieldPath: "spec.writeConnectionSecretToRef.name"
- transforms:
- - type: string
- string:
- fmt: "%s-postgresql"
- - fromFieldPath: "spec.parameters.storageGB"
- toFieldPath: "spec.forProvider.allocatedStorage"
- connectionDetails:
- - fromConnectionSecretKey: username
- - fromConnectionSecretKey: password
- - fromConnectionSecretKey: endpoint
- - fromConnectionSecretKey: port
diff --git a/docs/v0.11/snippets/publish/composition-aws.yaml b/docs/v0.11/snippets/publish/composition-aws.yaml
deleted file mode 100644
index 8db4f332..00000000
--- a/docs/v0.11/snippets/publish/composition-aws.yaml
+++ /dev/null
@@ -1,46 +0,0 @@
----
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: Composition
-metadata:
- name: postgresqlinstances.aws.database.example.org
- labels:
- provider: aws
- guide: quickstart
- vpc: default
-spec:
- writeConnectionSecretsToNamespace: crossplane-system
- reclaimPolicy: Delete
- from:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstance
- to:
- - base:
- apiVersion: database.aws.crossplane.io/v1beta1
- kind: RDSInstance
- spec:
- forProvider:
- dbInstanceClass: db.t2.small
- masterUsername: masteruser
- engine: postgres
- engineVersion: "9.6"
- skipFinalSnapshotBeforeDeletion: true
- publiclyAccessible: true
- writeConnectionSecretToRef:
- namespace: crossplane-system
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- patches:
- - fromFieldPath: "metadata.uid"
- toFieldPath: "spec.writeConnectionSecretToRef.name"
- transforms:
- - type: string
- string:
- fmt: "%s-postgresql"
- - fromFieldPath: "spec.parameters.storageGB"
- toFieldPath: "spec.forProvider.allocatedStorage"
- connectionDetails:
- - fromConnectionSecretKey: username
- - fromConnectionSecretKey: password
- - fromConnectionSecretKey: endpoint
- - fromConnectionSecretKey: port
\ No newline at end of file
diff --git a/docs/v0.11/snippets/publish/composition-azure.yaml b/docs/v0.11/snippets/publish/composition-azure.yaml
deleted file mode 100644
index 435fd40a..00000000
--- a/docs/v0.11/snippets/publish/composition-azure.yaml
+++ /dev/null
@@ -1,77 +0,0 @@
----
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: Composition
-metadata:
- name: postgresqlinstances.azure.database.example.org
- labels:
- provider: azure
- guide: quickstart
-spec:
- writeConnectionSecretsToNamespace: crossplane-system
- reclaimPolicy: Delete
- from:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstance
- to:
- - base:
- apiVersion: azure.crossplane.io/v1alpha3
- kind: ResourceGroup
- spec:
- location: West US 2
- reclaimPolicy: Delete
- providerRef:
- name: azure-provider
- - base:
- apiVersion: database.azure.crossplane.io/v1beta1
- kind: PostgreSQLServer
- spec:
- forProvider:
- administratorLogin: myadmin
- resourceGroupNameSelector:
- matchControllerRef: true
- location: West US 2
- sslEnforcement: Disabled
- version: "9.6"
- sku:
- tier: GeneralPurpose
- capacity: 2
- family: Gen5
- writeConnectionSecretToRef:
- namespace: crossplane-system
- providerRef:
- name: azure-provider
- reclaimPolicy: Delete
- patches:
- - fromFieldPath: "metadata.uid"
- toFieldPath: "spec.writeConnectionSecretToRef.name"
- transforms:
- - type: string
- string:
- fmt: "%s-postgresql"
- - fromFieldPath: "spec.parameters.storageGB"
- toFieldPath: "spec.forProvider.storageProfile.storageMB"
- transforms:
- - type: math
- math:
- multiply: 1024
- connectionDetails:
- - fromConnectionSecretKey: username
- - fromConnectionSecretKey: password
- - fromConnectionSecretKey: endpoint
- - name: port
- value: "5432"
- - base:
- apiVersion: database.azure.crossplane.io/v1alpha3
- kind: PostgreSQLServerFirewallRule
- spec:
- forProvider:
- serverNameSelector:
- matchControllerRef: true
- resourceGroupNameSelector:
- matchControllerRef: true
- properties:
- startIpAddress: 0.0.0.0
- endIpAddress: 255.255.255.254
- reclaimPolicy: Delete
- providerRef:
- name: azure-provider
diff --git a/docs/v0.11/snippets/publish/composition-gcp.yaml b/docs/v0.11/snippets/publish/composition-gcp.yaml
deleted file mode 100644
index bf937168..00000000
--- a/docs/v0.11/snippets/publish/composition-gcp.yaml
+++ /dev/null
@@ -1,49 +0,0 @@
----
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: Composition
-metadata:
- name: postgresqlinstances.gcp.database.example.org
- labels:
- provider: gcp
- guide: quickstart
-spec:
- writeConnectionSecretsToNamespace: crossplane-system
- reclaimPolicy: Delete
- from:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstance
- to:
- - base:
- apiVersion: database.gcp.crossplane.io/v1beta1
- kind: CloudSQLInstance
- spec:
- forProvider:
- databaseVersion: POSTGRES_9_6
- region: us-central1
- settings:
- tier: db-custom-1-3840
- dataDiskType: PD_SSD
- ipConfiguration:
- ipv4Enabled: true
- authorizedNetworks:
- - value: "0.0.0.0/0"
- writeConnectionSecretToRef:
- namespace: crossplane-system
- providerRef:
- name: gcp-provider
- reclaimPolicy: Delete
- patches:
- - fromFieldPath: "metadata.uid"
- toFieldPath: "spec.writeConnectionSecretToRef.name"
- transforms:
- - type: string
- string:
- fmt: "%s-postgresql"
- - fromFieldPath: "spec.parameters.storageGB"
- toFieldPath: "spec.forProvider.settings.dataDiskSizeGb"
- connectionDetails:
- - fromConnectionSecretKey: username
- - fromConnectionSecretKey: password
- - fromConnectionSecretKey: endpoint
- - name: port
- value: "5432"
\ No newline at end of file
diff --git a/docs/v0.11/snippets/publish/definition.yaml b/docs/v0.11/snippets/publish/definition.yaml
deleted file mode 100644
index d3126e9e..00000000
--- a/docs/v0.11/snippets/publish/definition.yaml
+++ /dev/null
@@ -1,35 +0,0 @@
----
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: InfrastructureDefinition
-metadata:
- name: postgresqlinstances.database.example.org
-spec:
- connectionSecretKeys:
- - username
- - password
- - endpoint
- - port
- crdSpecTemplate:
- group: database.example.org
- version: v1alpha1
- names:
- kind: PostgreSQLInstance
- listKind: PostgreSQLInstanceList
- plural: postgresqlinstances
- singular: postgresqlinstance
- validation:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- parameters:
- type: object
- properties:
- storageGB:
- type: integer
- required:
- - storageGB
- required:
- - parameters
\ No newline at end of file
diff --git a/docs/v0.11/snippets/publish/pod.yaml b/docs/v0.11/snippets/publish/pod.yaml
deleted file mode 100644
index 0b65ecef..00000000
--- a/docs/v0.11/snippets/publish/pod.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
- name: see-db
- namespace: default
-spec:
- containers:
- - name: see-db
- image: postgres:9.6
- command: ['psql']
- args: ['-c', 'SELECT current_database();']
- env:
- - name: PGDATABASE
- value: postgres
- - name: PGHOST
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: endpoint
- - name: PGUSER
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: username
- - name: PGPASSWORD
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: password
- - name: PGPORT
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: port
diff --git a/docs/v0.11/snippets/publish/publication.yaml b/docs/v0.11/snippets/publish/publication.yaml
deleted file mode 100644
index 064ef9f6..00000000
--- a/docs/v0.11/snippets/publish/publication.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
----
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: InfrastructurePublication
-metadata:
- name: postgresqlinstances.database.example.org
-spec:
- infrastructureDefinitionRef:
- name: postgresqlinstances.database.example.org
\ No newline at end of file
diff --git a/docs/v0.11/snippets/publish/requirement-alibaba.yaml b/docs/v0.11/snippets/publish/requirement-alibaba.yaml
deleted file mode 100644
index 8428da04..00000000
--- a/docs/v0.11/snippets/publish/requirement-alibaba.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstanceRequirement
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: alibaba
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.11/snippets/publish/requirement-aws.yaml b/docs/v0.11/snippets/publish/requirement-aws.yaml
deleted file mode 100644
index 6d4cc00d..00000000
--- a/docs/v0.11/snippets/publish/requirement-aws.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstanceRequirement
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: aws
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.11/snippets/publish/requirement-azure.yaml b/docs/v0.11/snippets/publish/requirement-azure.yaml
deleted file mode 100644
index d850307b..00000000
--- a/docs/v0.11/snippets/publish/requirement-azure.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstanceRequirement
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: azure
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.11/snippets/publish/requirement-gcp.yaml b/docs/v0.11/snippets/publish/requirement-gcp.yaml
deleted file mode 100644
index 9bc3bc92..00000000
--- a/docs/v0.11/snippets/publish/requirement-gcp.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstanceRequirement
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: gcp
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.11/snippets/run/appconfig.yaml b/docs/v0.11/snippets/run/appconfig.yaml
deleted file mode 100644
index 9bfca5d8..00000000
--- a/docs/v0.11/snippets/run/appconfig.yaml
+++ /dev/null
@@ -1,59 +0,0 @@
----
-apiVersion: core.oam.dev/v1alpha2
-kind: ApplicationConfiguration
-metadata:
- name: service-tracker
-spec:
- components:
- - componentName: data-api-database
- parameterValues:
- - name: database-secret
- value: tracker-database-secret
- - componentName: data-api
- parameterValues:
- - name: database-secret
- value: tracker-database-secret
- - componentName: flights-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: flights-api
- spec:
- replicaCount: 2
- - componentName: quakes-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: quakes-api
- spec:
- replicaCount: 2
- - componentName: weather-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: weather-api
- spec:
- replicaCount: 2
- - componentName: service-tracker-ui
- parameterValues:
- - name: flights-uri
- value: "http://flights-api.default.svc.cluster.local:3003/"
- - name: weather-uri
- value: "http://weather-api.default.svc.cluster.local:3015/"
- - name: quakes-uri
- value: "http://quakes-api.default.svc.cluster.local:3012/"
diff --git a/docs/v0.11/snippets/run/components.yaml b/docs/v0.11/snippets/run/components.yaml
deleted file mode 100644
index 51ade0c9..00000000
--- a/docs/v0.11/snippets/run/components.yaml
+++ /dev/null
@@ -1,197 +0,0 @@
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: data-api-database
-spec:
- workload:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstanceRequirement
- metadata:
- name: app-postgresql
- spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- guide: quickstart
- parameters:
- - name: database-secret
- description: Secret to which to write PostgreSQL database connection details.
- required: true
- fieldPaths:
- - spec.writeConnectionSecretToRef.name
- - name: database-provider
- description: |
- Cloud provider that should be used to create a PostgreSQL database.
- Either alibaba, aws, azure, or gcp.
- fieldPaths:
- - spec.compositionSelector.matchLabels.provider
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: data-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: data-api
- spec:
- containers:
- - name: data-api
- image: artursouza/rudr-data-api:0.50
- env:
- - name: DATABASE_USER
- fromSecret:
- key: username
- - name: DATABASE_PASSWORD
- fromSecret:
- key: password
- - name: DATABASE_HOSTNAME
- fromSecret:
- key: endpoint
- - name: DATABASE_PORT
- fromSecret:
- key: port
- - name: DATABASE_NAME
- value: postgres
- - name: DATABASE_DRIVER
- value: postgresql
- ports:
- - name: http
- containerPort: 3009
- protocol: TCP
- livenessProbe:
- exec:
- command: [wget, -q, http://127.0.0.1:3009/status, -O, /dev/null, -S]
- parameters:
- - name: database-secret
- description: Secret from which to read PostgreSQL connection details.
- required: true
- fieldPaths:
- - spec.containers[0].env[0].fromSecret.name
- - spec.containers[0].env[1].fromSecret.name
- - spec.containers[0].env[2].fromSecret.name
- - spec.containers[0].env[3].fromSecret.name
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: flights-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: flights-api
- spec:
- containers:
- - name: flights-api
- image: sonofjorel/rudr-flights-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3003
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: quakes-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: quakes-api
- spec:
- containers:
- - name: quakes-api
- image: sonofjorel/rudr-quakes-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3012
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: service-tracker-ui
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: web-ui
- spec:
- containers:
- - name: service-tracker-ui
- image: sonofjorel/rudr-web-ui:0.49
- env:
- - name: FLIGHT_API_ROOT
- - name: WEATHER_API_ROOT
- - name: QUAKES_API_ROOT
- ports:
- - name: http
- containerPort: 8080
- protocol: TCP
- parameters:
- - name: flights-uri
- description: URI at which the flights service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
- - name: weather-uri
- description: URI at which the weather service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[1].value
- - name: quakes-uri
- description: URI at which the quakes service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[2].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: weather-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: weather-api
- spec:
- containers:
- - name: weather-api
- image: sonofjorel/rudr-weather-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3015
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
\ No newline at end of file
diff --git a/docs/v0.11/snippets/run/definitions.yaml b/docs/v0.11/snippets/run/definitions.yaml
deleted file mode 100644
index ef19bc8a..00000000
--- a/docs/v0.11/snippets/run/definitions.yaml
+++ /dev/null
@@ -1,24 +0,0 @@
----
-apiVersion: core.oam.dev/v1alpha2
-kind: WorkloadDefinition
-metadata:
- name: containerizedworkloads.core.oam.dev
-spec:
- definitionRef:
- name: containerizedworkloads.core.oam.dev
----
-apiVersion: core.oam.dev/v1alpha2
-kind: TraitDefinition
-metadata:
- name: manualscalertraits.core.oam.dev
-spec:
- definitionRef:
- name: manualscalertraits.core.oam.dev
----
-apiVersion: core.oam.dev/v1alpha2
-kind: WorkloadDefinition
-metadata:
- name: postgresqlinstancerequirements.database.example.org
-spec:
- definitionRef:
- name: postgresqlinstancerequirements.database.example.org
diff --git a/docs/v0.12/README.md b/docs/v0.12/README.md
deleted file mode 100644
index adf74605..00000000
--- a/docs/v0.12/README.md
+++ /dev/null
@@ -1,66 +0,0 @@
-# Overview
-
-
-
-Crossplane is an open source Kubernetes add-on that extends any cluster with
-the ability to provision and manage cloud infrastructure, services, and
-applications using kubectl, GitOps, or any tool that works with the Kubernetes
-API.
-
-With Crossplane you can:
-
-* **Provision & manage cloud infrastructure with kubectl**
- * [Install Crossplane] to provision and manage cloud infrastructure and
- services from any Kubernetes cluster.
- * Provision infrastructure primitives from any provider ([GCP], [AWS],
- [Azure], [Alibaba], on-prem) and use them alongside existing application
- configurations.
- * Version, manage, and deploy with your favorite tools and workflows that
- you’re using with your clusters today.
-
-* **Publish custom infrastructure resources for your applications to use**
- * Define, compose, and publish your own [infrastructure resources] with
- declarative YAML, resulting in your own infrastructure CRDs being added to
- the Kubernetes API for applications to use.
- * Hide infrastructure complexity and include policy guardrails, so
- applications can easily and safely consume the infrastructure they need,
- using any tool that works with the Kubernetes API.
- * Consume infrastructure resources alongside any Kubernetes application to
- provision and manage the cloud services they need with Crossplane as an
- add-on to any Kubernetes cluster.
-
-* **Deploy applications using a team-centric approach with OAM**
- * Define cloud native applications and the infrastructure they require with
- the Open Application Model ([OAM]).
- * Collaborate with a team-centric approach with a strong separation of
- concerns.
- * Deploy application configurations from app delivery pipelines or GitOps
- workflows, using the proven Kubernetes declarative model.
-
-Separation of concerns is core to Crossplane’s approach to infrastructure and
-application management, so team members can deliver value by focusing on what
-they know best. Crossplane's team-centric approach reflects individuals often
-specializing in the following roles:
-
-* **Infrastructure Operators** - provide infrastructure and services for apps
- to consume
-* **Application Developers** - build application components independent of
- infrastructure
-* **Application Operators** - compose, deploy, and run application
- configurations
-
-## Getting Started
-
-[Install Crossplane] into any Kubernetes cluster to get started.
-
-
-
-[Install Crossplane]: getting-started/install-configure.md
-[Custom Resource Definitions]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[reconciling]: https://kubernetes.io/docs/concepts/architecture/controller/
-[GCP]: https://github.com/crossplane/provider-gcp
-[AWS]: https://github.com/crossplane/provider-aws
-[Azure]: https://github.com/crossplane/provider-azure
-[Alibaba]: https://github.com/crossplane/provider-alibaba
-[infrastructure resources]: https://blog.crossplane.io/crossplane-v0-10-compose-and-publish-your-own-infrastructure-crds-velero-backup-restore-compatibility-and-more/
-[OAM]: https://github.com/oam-dev/spec/releases/tag/v1.0.0-alpha.2
diff --git a/docs/v0.12/api-docs/crossplane.md b/docs/v0.12/api-docs/crossplane.md
deleted file mode 100644
index afa6876d..00000000
--- a/docs/v0.12/api-docs/crossplane.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: crossplane
-toc: true
-weight: 401
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/crossplane
----
\ No newline at end of file
diff --git a/docs/v0.12/api-docs/overview.md b/docs/v0.12/api-docs/overview.md
deleted file mode 100644
index e9a92c48..00000000
--- a/docs/v0.12/api-docs/overview.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: API Documentation
-toc: true
-weight: 400
----
-
-# API Documentation
-
-The Crossplane ecosystem contains many CRDs that map to API types represented by
-external infrastructure providers. The documentation for these CRDs are
-auto-generated on [doc.crds.dev]. To find the CRDs available for providers
-maintained by the Crossplane organization, you can search for the Github URL, or
-append it in the [doc.crds.dev] URL path.
-
-For instance, to find the CRDs available for [provider-azure], you would go to:
-
-[doc.crds.dev/github.com/crossplane/provider/azure]
-
-By default, you will be served the latest CRDs on the `master` branch for the
-repository. If you prefer to see the CRDs for a specific version, you can append
-the git tag for the release:
-
-[doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0]
-
-Crossplane repositories that are not providers but do publish CRDs are also
-served on [doc.crds.dev]. For instance, the [crossplane/crossplane] repository.
-
-Bugs and feature requests for API documentation should be [opened as issues] on
-the open source [doc.crds.dev repo].
-
-
-
-[doc.crds.dev]: https://doc.crds.dev/
-[provider-azure]: https://github.com/crossplane/provider-azure
-[doc.crds.dev/github.com/crossplane/provider/azure]: https://doc.crds.dev/github.com/crossplane/provider-azure
-[doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0]: https://doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0
-[crossplane/crossplane]: https://doc.crds.dev/github.com/crossplane/crossplane
-[opened as issues]: https://github.com/crdsdev/doc/issues/new
-[doc.crds.dev repo]: https://github.com/crdsdev/doc
diff --git a/docs/v0.12/api-docs/provider-alibaba.md b/docs/v0.12/api-docs/provider-alibaba.md
deleted file mode 100644
index 471122ef..00000000
--- a/docs/v0.12/api-docs/provider-alibaba.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-alibaba
-toc: true
-weight: 402
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-alibaba
----
\ No newline at end of file
diff --git a/docs/v0.12/api-docs/provider-aws.md b/docs/v0.12/api-docs/provider-aws.md
deleted file mode 100644
index c826c3f0..00000000
--- a/docs/v0.12/api-docs/provider-aws.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-aws
-toc: true
-weight: 403
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-aws
----
\ No newline at end of file
diff --git a/docs/v0.12/api-docs/provider-azure.md b/docs/v0.12/api-docs/provider-azure.md
deleted file mode 100644
index 444d84c2..00000000
--- a/docs/v0.12/api-docs/provider-azure.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-azure
-toc: true
-weight: 404
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-azure
----
\ No newline at end of file
diff --git a/docs/v0.12/api-docs/provider-gcp.md b/docs/v0.12/api-docs/provider-gcp.md
deleted file mode 100644
index 160fe053..00000000
--- a/docs/v0.12/api-docs/provider-gcp.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-gcp
-toc: true
-weight: 405
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-gcp
----
\ No newline at end of file
diff --git a/docs/v0.12/api-docs/provider-rook.md b/docs/v0.12/api-docs/provider-rook.md
deleted file mode 100644
index c365e387..00000000
--- a/docs/v0.12/api-docs/provider-rook.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-rook
-toc: true
-weight: 406
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-rook
----
\ No newline at end of file
diff --git a/docs/v0.12/cloud-providers/aws/aws-provider.md b/docs/v0.12/cloud-providers/aws/aws-provider.md
deleted file mode 100644
index 5f27eef0..00000000
--- a/docs/v0.12/cloud-providers/aws/aws-provider.md
+++ /dev/null
@@ -1,143 +0,0 @@
-# Adding Amazon Web Services (AWS) to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your AWS
-account to be ready for integration with Crossplane. This will be done by adding
-an AWS `Provider` resource type, which enables Crossplane to communicate with an
-AWS account.
-
-## Requirements
-
-Prior to adding AWS to Crossplane, following steps need to be taken
-
-- Crossplane is installed in a k8s cluster
-- AWS Stack is installed in the same cluster
-- `kubectl` is configured to communicate with the same cluster
-
-## Step 1: Configure `aws` CLI
-
-Crossplane uses [AWS security credentials], and stores them as a [secret] which
-is managed by an AWS `Provider` instance. In addition, the AWS default region is
-also used for targeting a specific region. Crossplane requires to have [`aws`
-command line tool] [installed] and [configured]. Once installed, the credentials
-and configuration will reside in `~/.aws/credentials` and `~/.aws/config`
-respectively.
-
-## Step 2: Setup `aws` Provider
-
-Run [setup.sh] script to read `aws` credentials and region, and create an `aws
-provider` instance in Crossplane:
-
-```bash
-./cluster/examples/aws-setup-provider/setup.sh [--profile aws_profile]
-```
-
-The `--profile` switch is optional and specifies the [aws named profile] that
-was set in Step 1. If not provided, the `default` profile will be selected.
-
-Once the script is successfully executed, Crossplane will use the specified aws
-account and region in the given named profile to create subsequent AWS managed
-resources.
-
-You can confirm the existense of the AWS `Provider` by running:
-
-```bash
-kubectl -n crossplane-system get provider/aws-provider
-```
-
-## Optional: Setup AWS Provider Manually
-
-An AWS [user][aws user] with `Administrative` privileges is needed to enable
-Crossplane to create the required resources. Once the user is provisioned, an
-[Access Key][] needs to be created so the user can have API access.
-
-Using the set of [access key credentials][AWS security credentials] for the user
-with the right access, we need to [install][install-aws] [`aws cli`][aws command
-line tool], and then [configure][aws-cli-configure] it.
-
-When the AWS cli is configured, the credentials and configuration will be in
-`~/.aws/credentials` and `~/.aws/config` respectively. These will be consumed in
-the next step.
-
-When configuring the AWS cli, the user credentials could be configured under a
-specific [AWS named profile][], or under `default`. Without loss of generality,
-in this guide let's assume that the credentials are configured under the
-`aws_profile` profile (which could also be `default`). We'll use this profile to
-setup cloud provider in the next section.
-
-Crossplane uses the AWS user credentials that were configured in the previous
-step to create resources in AWS. These credentials will be stored as a
-[secret][kubernetes secret] in Kubernetes, and will be used by an AWS `Provider`
-instance. The default AWS region is also pulled from the cli configuration, and
-added to the AWS provider.
-
-To store the credentials as a secret, run:
-
-```bash
-# retrieve profile's credentials, save it under 'default' profile, and base64 encode it
-BASE64ENCODED_AWS_ACCOUNT_CREDS=$(echo -e "[default]\naws_access_key_id = $(aws configure get aws_access_key_id --profile $aws_profile)\naws_secret_access_key = $(aws configure get aws_secret_access_key --profile $aws_profile)" | base64 | tr -d "\n")
-# retrieve the profile's region from config
-AWS_REGION=$(aws configure get region --profile ${aws_profile})
-```
-
-At this point, the region and the encoded credentials are stored in respective
-variables. Next, we'll need to create an instance of AWS provider:
-
-```bash
-cat > provider.yaml <
-
-[`aws` command line tool]: https://aws.amazon.com/cli/
-[AWS SDK for GO]: https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/setting-up.html
-[installed]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html
-[configured]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html
-[AWS security credentials]: https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html
-[secret]:https://kubernetes.io/docs/concepts/configuration/secret/
-[setup.sh]: https://github.com/crossplane/crossplane/blob/master/cluster/examples/aws-setup-provider/setup.sh
-[aws named profile]: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html
-[aws user]: https://docs.aws.amazon.com/mediapackage/latest/ug/setting-up-create-iam-user.html
-[Access Key]: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
-[AWS security credentials]: https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html
-[aws command line tool]: https://aws.amazon.com/cli/
-[install-aws]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html
-[aws-cli-configure]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html
-[kubernetes secret]: https://kubernetes.io/docs/concepts/configuration/secret/
-[AWS named profile]: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html
diff --git a/docs/v0.12/cloud-providers/azure/azure-provider.md b/docs/v0.12/cloud-providers/azure/azure-provider.md
deleted file mode 100644
index c566b61f..00000000
--- a/docs/v0.12/cloud-providers/azure/azure-provider.md
+++ /dev/null
@@ -1,125 +0,0 @@
-# Adding Microsoft Azure to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your Azure
-account to be ready for integration with Crossplane. The general steps we will
-take are summarized below:
-
-* Create a new service principal (account) that Crossplane will use to create
- and manage Azure resources
-* Add the required permissions to the account
-* Consent to the permissions using an administrator account
-
-## Preparing your Microsoft Azure Account
-
-In order to manage resources in Azure, you must provide credentials for a Azure
-service principal that Crossplane can use to authenticate. This assumes that you
-have already [set up the Azure CLI
-client](https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli?view=azure-cli-latest)
-with your credentials.
-
-Create a JSON file that contains all the information needed to connect and
-authenticate to Azure:
-
-```bash
-# create service principal with Owner role
-az ad sp create-for-rbac --sdk-auth --role Owner > crossplane-azure-provider-key.json
-```
-
-Take note of the `clientID` value from the JSON file that we just created, and
-save it to an environment variable:
-
-```bash
-export AZURE_CLIENT_ID=
-```
-
-Now add the required permissions to the service principal that will allow it to
-manage the necessary resources in Azure:
-
-```bash
-# add required Azure Active Directory permissions
-az ad app permission add --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --api-permissions 1cda74f2-2616-4834-b122-5cb1b07f8a59=Role 78c8a3c8-a07e-4b9e-af1b-b5ccab50a175=Role
-
-# grant (activate) the permissions
-az ad app permission grant --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --expires never
-```
-
-You might see an error similar to the following, but that is OK, the permissions
-should have gone through still:
-
-```console
-Operation failed with status: 'Conflict'. Details: 409 Client Error: Conflict for url: https://graph.windows.net/e7985bc4-a3b3-4f37-b9d2-fa256023b1ae/oauth2PermissionGrants?api-version=1.6
-```
-
-Finally, you need to grant admin permissions on the Azure Active Directory to
-the service principal because it will need to create other service principals
-for your `AKSCluster`:
-```bash
-# grant admin consent to the service princinpal you created
-az ad app permission admin-consent --id "${AZURE_CLIENT_ID}"
-```
-
-Note: You might need `Global Administrator` role to `Grant admin consent for
-Default Directory`. Please contact the administrator of your Azure subscription.
-To check your role, go to `Azure Active Directory` -> `Roles and
-administrators`. You can find your role(s) by clicking on `Your Role (Preview)`
-
-After these steps are completed, you should have the following file on your
-local filesystem:
-
-* `crossplane-azure-provider-key.json`
-
-## Setup Azure Provider
-
-Before creating any resources, we need to create and configure an Azure cloud
-provider resource in Crossplane, which stores the cloud account information in
-it. All the requests from Crossplane to Azure Cloud will use the credentials
-attached to this provider resource. The following command assumes that you have
-a `crossplane-azure-provider-key.json` file that belongs to the account you’d
-like Crossplane to use.
-
-```bash
-BASE64ENCODED_AZURE_ACCOUNT_CREDS=$(base64 crossplane-azure-provider-key.json | tr -d "\n")
-```
-
-Now we’ll create our `Secret` that contains the credential and `Provider`
-resource that refers to that secret:
-
-```bash
-cat > provider.yaml < provider.yaml <
-[templating-controller]: https://github.com/crossplane/templating-controller
-[stack-gcp-sample]: https://github.com/crossplane/stack-gcp-sample
-[stack-aws-sample]: https://github.com/crossplane/stack-aws-sample
-[stack-azure-sample]: https://github.com/crossplane/stack-azure-sample
-[app-wordpress]: https://github.com/crossplane/app-wordpress
-[Wordpress Quickstart Guide]: https://github.com/crossplane/app-wordpress/blob/master/docs/quickstart.md
-[packaging an app]: experimental/packaging_an_app.md
\ No newline at end of file
diff --git a/docs/v0.12/contributing/experimental/packaging_an_app.md b/docs/v0.12/contributing/experimental/packaging_an_app.md
deleted file mode 100644
index 38cdbc71..00000000
--- a/docs/v0.12/contributing/experimental/packaging_an_app.md
+++ /dev/null
@@ -1,198 +0,0 @@
----
-title: Packaging an Application
-toc: false
-weight: 2000
-indent: true
----
-
-# Packaging an Application
-
-In the quick start guide, we demonstrated how Wordpress can be installed as a
-Crossplane `Application`. Now we want to learn more about how to package any
-application in a similar fashion. The good news is that we can use common
-Kubernetes configuration tools, such as [Helm] and [Kustomize], which you may
-already be familiar with.
-
-## Setting up a Repository
-
-The required components of an application repository are minimal. For example,
-the required components of the [Wordpress application] we deployed in the quick
-start are the following:
-
-```
-├── Dockerfile
-├── .registry
-│ ├── app.yaml
-│ ├── behavior.yaml
-│ ├── icon.svg
-│ └── resources
-│ ├── wordpress.apps.crossplane.io_wordpressinstances.crd.yaml
-│ ├── wordpressinstance.icon.svg
-│ ├── wordpressinstance.resource.yaml
-│ └── wordpressinstance.ui-schema.yaml
-├── helm-chart
-│ ├── Chart.yaml
-│ ├── templates
-│ │ ├── app.yaml
-│ │ ├── cluster.yaml
-│ │ └── database.yaml
-│ └── values.yaml
-```
-
-Let's take a look at each component in-depth.
-
-### Dockerfile
-
-The Dockerfile is only responsible for copying the configuration directory
-(`helm-chart/` in this case) and the `.registry` directory. You can likely use a
-very similar Dockerfile across all of your applications:
-
-```Dockerfile
-FROM alpine:3.7
-WORKDIR /
-COPY helm-chart /helm-chart
-COPY .registry /.registry
-```
-
-### .registry
-
-The `.registry` directory informs Crossplane how to install your application. It
-consists of the following:
-
-**app.yaml** `[required]`
-
-The `app.yaml` file is responsible for defining the metadata for an application,
-such as name, version, and required permissions. The Wordpress `app.yaml` is a
-good reference for available fields:
-
-```yaml
-# Human readable title of application.
-title: Wordpress
-
-overviewShort: Cloud portable Wordpress deployments behind managed Kubernetes and SQL services are demonstrated in this Crossplane Stack.
-
-overview: |-
- This Wordpress application uses a simple controller that uses Crossplane to orchestrate managed SQL services and managed Kubernetes clusters which are then used to run a Wordpress deployment.
- A simple Custom Resource Definition (CRD) is provided allowing for instances of this Crossplane managed Wordpress Application to be provisioned with a few lines of yaml.
- The Sample Wordpress Application is intended for demonstration purposes and should not be used to deploy production instances of Wordpress.
-
-# Markdown description of this entry
-readme: |-
- ### Create wordpresses
- Before wordpresses will provision, the Crossplane control cluster must
- be configured to connect to a provider (e.g. GCP, Azure, AWS).
- Once a provider is configured, starting the process of creating a
- Wordpress Application instance is easy.
-
- cat <.icon.svg`: an image to be displayed for your application CRD
-- `.resource.yaml`: a description of your application CRD
-- `.ui-schema.yaml`: the configurable fields on your CRD that you
- wish to be displayed in a UI
-
-Crossplane will take these files and apply them as [annotations] on the
-installed application. They can then be parsed by a user interface.
-
-### Configuration Directory
-
-The configuration directory contains the actual manifests for deploying your
-application. In the case of Wordpress, this includes a `KubernetesApplication`
-(`helm-chart/templates/app.yaml`), a `KubernetesCluster` claim
-(`helm-chart/templates/cluster.yaml`), and a `MySQLInstance` claim
-(`helm-chart/templates/database.yaml`). The configuration tool for the manifests
-in the directory should match the `engine` field in your
-`.registry/behavior.yaml`. The options for engines at this time are `helm3` and
-`kustomize`. Crossplane will pass values from the `spec` of the application's
-CRD as variables in the manifests. For instance, the `provisionPolicy` field in
-the `spec` of the `WordpressInstance` CRD will be passed to the Helm chart
-defined in the `helm-chart/` directory.
-
-
-
-[Helm]: https://helm.sh/
-[Kustomize]: https://kustomize.io/
-[Wordpress application]: https://github.com/crossplane/app-wordpress
-[CustomResourceDefinition]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[controller-tools]: https://github.com/kubernetes-sigs/controller-tools
-[annotations]: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
diff --git a/docs/v0.12/contributing/observability_developer_guide.md b/docs/v0.12/contributing/observability_developer_guide.md
deleted file mode 100644
index 9741512f..00000000
--- a/docs/v0.12/contributing/observability_developer_guide.md
+++ /dev/null
@@ -1,200 +0,0 @@
----
-title: Observability Developer Guide
-toc: true
-weight: 1002
-indent: true
----
-
-# Observability Developer Guide
-
-## Introduction
-
-Observability is crucial to Crossplane users; both those operating Crossplane
-and those using Crossplane to operate their infrastructure. Crossplane currently
-approaches observability via Kubernetes events and structured logs. Timeseries
-metrics are desired but [not yet implemented].
-
-## Goals
-
-In short, a non-admin user and an admin user should both be able to debug any
-issues only by inspecting logs and events. There should be no need to rebuild
-the Crossplane binary or to reach out to a Crossplane developer.
-
-A user should be able to:
-
-* Debug an issue without rebuilding the Crossplane binary
-* Understand an issue without contacting a cluster admin
-* Ask a cluster admin to check the logs for more details about the reason the
- issue happened, if the details are not part of the error message
-
-A cluster admin should be able to:
-
-* Debug an issue without rebuilding the Crossplane binary
-* Debug an issue only by looking at the logs
-* Debug an issue without needing to contact a Crossplane developer
-
-## Error reporting in the logs
-
-Error reporting in the logs is mostly intended for consumption by Crossplane
-cluster admins. A cluster admin should be able to debug any issue by inspecting
-the logs, without needing to add more logs themselves or contact a Crossplane
-developer. This means that logs should contain:
-
-* Error messages, at either the info or debug level as contextually appropriate
-* Any context leading up to an error, typically at debug level, so that the
- errors can be debugged
-
-## Error reporting as events
-
-Error reporting as Kubernetes events is primarily aimed toward end-users of
-Crossplane who are not cluster admins. Crossplane typically runs as a Kubernetes
-pod, and thus it is unlikely that most users of Crossplane will have access to
-its logs. [Events], on the other hand, are available as top-level Kubernetes
-objects, and show up the objects they relate to when running `kubectl describe`.
-
-Events should be recorded in the following cases:
-
-* A significant operation is taken on a resource
-* The state of a resource is changed
-* An error occurs
-
-The events recorded in these cases can be thought of as forming an event log of
-things that happen for the resources that Crossplane manages. Each event should
-refer back to the relevant controller and resource, and use other fields of the
-Event kind as appropriate.
-
-More details about examples of how to interact with events can be found in the
-guide to [debugging an application cluster].
-
-## Choosing between methods of error reporting
-
-There are many ways to report errors, such as:
-
-* Metrics
-* Events
-* Logging
-* Tracing
-
-It can be confusing to figure out which one is appropriate in a given situation.
-This section will try to offer advice and a mindset that can be used to help
-make this decision.
-
-Let's set the context by listing the different user scenarios where error
-reporting may be consumed. Here are the typical scenarios as we imagine them:
-
-1. A person **using** a system needs to figure out why things aren't working as
- expected, and whether they made a mistake that they can correct.
-2. A person **operating** a service needs to monitor the service's **health**,
- both now and historically.
-3. A person **debugging** a problem which happened in a **live environment**
- (often an **operator** of the system) needs information to figure out what
- happened.
-4. A person **developing** the software wants to **observe** what is happening.
-5. A person **debugging** the software in a **development environment**
- (typically a **developer** of the system) wants to debug a problem (there is
- a lot of overlap between this and the live environment debugging scenario).
-
-The goal is to satisfy the users in all of the scenarios. We'll refer to the
-scenarios by number.
-
-The short version is: we should do whatever satisfies all of the scenarios.
-Logging and events are the recommendations for satisfying the scenarios,
-although they don't cover scenario 2.
-
-The longer version is:
-
-* Scenario 1 is best served by events in the context of Crossplane, since the
- users may not have access to read logs or metrics, and even if they did, it
- would be hard to relate them back to the event the user is trying to
- understand.
-* Scenario 2 is best served by metrics, because they can be aggregated and
- understood as a whole. And because they can be used to track things over time.
-* Scenario 3 is best served by either logging that contains all the information
- about and leading up to the event. Request-tracing systems are also useful for
- this scenario.
-* Scenario 4 is usually logs, maybe at a more verbose level than normal. But it
- could be an attached debugger or some other type of tool. It could also be a
- test suite.
-* Scenario 5 is usually either logs, up to the highest imaginable verbosity, or
- an attached debugging session. If there's a gap in reporting, it could involve
- adding some print statements to get more logging.
-
-As for the question of how to decide whether to log or not, we believe it helps
-to try to visualize which of the scenarios the error or information in question
-will be used for. We recommend starting with reporting as much information as
-possible, but with configurable runtime behavior so that, for example, debugging
-logs don't show up in production normally.
-
-For the question of what constitutes an error, errors should be actionable by a
-human. See the [Dave Cheney article] on this topic for some more discussion.
-
-## In Practice
-
-Crossplane provides two observability libraries as part of crossplane-runtime:
-
-* [`event`] emits Kubernetes events.
-* [`logging`] produces structured logs. Refer to its package documentation for
- additional context on its API choices.
-
-Keep the following in mind when using the above libraries:
-
-* [Do] [not] use package level loggers or event recorders. Instantiate them in
- `main()` and plumb them down to where they're needed.
-* Each [`Reconciler`] implementation should use its own `logging.Logger` and
- `event.Recorder`. Implementations are strongly encouraged to default to using
- `logging.NewNopLogger()` and `event.NewNopRecorder()`, and accept a functional
- loggers and recorder via variadic options. See for example the [managed
- resource reconciler].
-* Each controller should use its name as its event recorder's name, and include
- its name under the `controller` structured logging key. The controllers name
- should be of the form `controllertype/resourcekind`, for example
- `managed/cloudsqlinstance` or `stacks/stackdefinition`. Controller names
- should always be lowercase.
-* Logs and events should typically be emitted by the `Reconcile` method of the
- `Reconciler` implementation; not by functions called by `Reconcile`. Author
- the methods orchestrated by `Reconcile` as if they were a library; prefer
- surfacing useful information for the `Reconciler` to log (for example by
- [wrapping errors]) over plumbing loggers and event recorders down to
- increasingly deeper layers of code.
-* Almost nothing is worth logging at info level. When deciding which logging
- level to use, consider a production deployment of Crossplane reconciling tens
- or hundreds of managed resources. If in doubt, pick debug. You can easily
- increase the log level later if it proves warranted.
-* The above is true even for errors; consider the audience. Is this an error
- only the Crossplane cluster operator can fix? Does it indicate a significant
- degradation of Crossplane's functionality? If so, log it at info. If the error
- pertains to a single Crossplane resource emit an event instead.
-* Always log errors under the structured logging key `error` (e.g.
- `log.Debug("boom!, "error", err)`). Many logging implementations (including
- Crossplane's) add context like stack traces for this key.
-* Emit events liberally; they're rate limited and deduplicated.
-* Follow [API conventions] when emitting events; ensure event reasons are unique
- and `CamelCase`.
-* Consider emitting events and logs when a terminal condition is encountered
- (e.g. `Reconcile` returns) over logging logic flow. i.e. Prefer one log line
- that reads "encountered an error fooing the bar" over two log lines that read
- "about to foo the bar" and "encountered an error". Recall that if the audience
- is a developer debugging Crossplane they will be provided a stack trace with
- file and line context when an error is logged.
-* Consider including the `reconcile.Request`, and the resource's UID and
- resource version (not API version) under the keys `request`, `uid`, and
- `version`. Doing so allows log readers to determine what specific version of a
- resource the log pertains to.
-
-Finally, when in doubt, aim for consistency with existing Crossplane controller
-implementations.
-
-
-
-[not yet implemented]: https://github.com/crossplane/crossplane/issues/314
-[Events]: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#event-v1-core
-[debugging an application cluster]: https://kubernetes.io/docs/tasks/debug-application-cluster/
-[Dave Cheney article]: https://dave.cheney.net/2015/11/05/lets-talk-about-logging
-[`event`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/event
-[`logging`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/logging
-[Do]: https://peter.bourgon.org/go-best-practices-2016/#logging-and-instrumentation
-[not]: https://dave.cheney.net/2017/01/23/the-package-level-logger-anti-pattern
-[`Reconciler`]: https://godoc.org/sigs.k8s.io/controller-runtime/pkg/reconcile#Reconciler
-[managed resource reconciler]: https://github.com/crossplane/crossplane-runtime/blob/a6bb0/pkg/reconciler/managed/reconciler.go#L436
-[wrapping errors]: https://godoc.org/github.com/pkg/errors#Wrap
-[API conventions]: https://github.com/kubernetes/community/blob/09f55c6/contributors/devel/sig-architecture/api-conventions.md#events
diff --git a/docs/v0.12/contributing/overview.md b/docs/v0.12/contributing/overview.md
deleted file mode 100644
index bbf258a5..00000000
--- a/docs/v0.12/contributing/overview.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Contributing
-toc: true
-weight: 1000
----
-
-# Contributing
-
-The following documentation is for developers who wish to contribute to or
-extend Crossplane. Please [open an
-issue](https://github.com/crossplane/crossplane/issues/new) for any additional
-documentation you would like to see in this section.
-
-1. [Services Developer Guide]
-2. [Observability Developer Guide]
-
-# Experimental Projects
-See [experimental] projects.
-
-
-[Services Developer Guide]: services_developer_guide.md
-[Observability Developer Guide]: observability_developer_guide.md
-[experimental]: experimental.md
diff --git a/docs/v0.12/contributing/services_developer_guide.md b/docs/v0.12/contributing/services_developer_guide.md
deleted file mode 100644
index 4fbee07f..00000000
--- a/docs/v0.12/contributing/services_developer_guide.md
+++ /dev/null
@@ -1,646 +0,0 @@
----
-title: Managed Resource Developer Guide
-toc: true
-weight: 1001
-indent: true
----
-
-# Managed Resource Developer Guide
-
-Crossplane allows you to manage infrastructure directly from Kubernetes. Each
-infrastructure API resource that Crossplane orchestrates is known as a "managed
-resource". This guide will walk through the process of adding support for a new
-kind of managed resource to Crossplane.
-
-## What Makes a Crossplane Infrastructure Resource
-
-Crossplane builds atop Kubernetes's powerful architecture in which declarative
-configuration, known as resources, are continually 'reconciled' with reality by
-one or more controllers. A controller is an endless loop that:
-
-1. Observes the desired state (the declarative configuration resource).
-1. Observes the actual state (the thing said configuration resource represents).
-1. Tries to make the actual state match the desired state.
-
-Typical Crossplane managed infrastructure consists of two configuration
-resources and one controller. The GCP Provider's support for Google Cloud
-Memorystore illustrates this. First, the configuration resources:
-
-1. A [managed resource]. Managed resources are cluster scoped, high-fidelity
- representations of a resource in an external system such as a cloud
- provider's API. Managed resources are _non-portable_ across external systems
- (i.e. cloud providers); they're tightly coupled to the implementation details
- of the external resource they represent. Managed resources are defined by a
- Provider. The GCP Provider's [`CloudMemorystoreInstance`] resource is an
- example of a managed resource.
-1. A provider. Providers enable access to an external system, typically by
- indicating a Kubernetes Secret containing any credentials required to
- authenticate to the system, as well as any other metadata required to
- connect. Providers are cluster scoped, like managed resources and classes.
- The GCP [`Provider`] is an example of a provider. Note that provider is a
- somewhat overloaded term in the Crossplane ecosystem - it's also used to
- refer to the controller manager for a particular cloud, for example
- `provider-gcp`.
-
-A managed resource is powered by a controller. This controller is responsible
-for taking instances of the aforementioned high-fidelity managed resource kind
-and reconciling them with an external system. The `CloudMemorystoreInstance`
-controller watches for changes to `CloudMemorystoreInstance` resources and calls
-Google's Cloud Memorystore API to create, update, or delete an instance as
-necessary.
-
-Crossplane does not require controllers to be written in any particular
-language. The Kubernetes API server is our API boundary, so any process capable
-of [watching the API server] and updating resources can be a Crossplane
-controller.
-
-## Getting Started
-
-At the time of writing all Crossplane Services controllers are written in Go,
-and built using [crossplane-runtime]. While it is possible to write a controller
-using any language and tooling with a Kubernetes client this set of tools are
-the "[golden path]". They're well supported, broadly used, and provide a shared
-language with the Crossplane community. This guide targets [crossplane-runtime
-v0.9.0]. It assumes the reader is familiar with the Kubernetes [API Conventions]
-and the [kubebuilder book].
-
-## Defining Resource Kinds
-
-Let's assume we want to add Crossplane support for your favourite cloud's
-database-as-a-service. Your favourite cloud brands these instances as "Favourite
-DB instances". Under the hood they're powered by the open source FancySQL
-engine. We'll name the new managed resource kind `FavouriteDBInstance` and the
-new resource claim `FancySQLInstance`.
-
-The first step toward implementing a new managed service is to define the code
-level schema of its configuration resources. These are referred to as
-[resources], (resource) [kinds], and [objects] interchangeably. The kubebuilder
-scaffolding is a good starting point for any new Crossplane API kind, whether
-they'll be a managed resource, resource class, or resource claim.
-
-> Note that while Crossplane was originally derived from kubebuilder scaffolds
-> its patterns have diverged somewhat. It is _possible_ to use kubebuilder to
-> scaffold a resource, but the author must be careful to adapt said resource to
-> Crossplane patterns. It may often be quicker to copy and modify a v1beta1 or
-> above resource from the same provider repository, rather than using
-> kubebuilder.
-
-```console
-# The resource claim.
-kubebuilder create api \
- --group example --version v1alpha1 --kind FancySQLInstance \
- --resource=true --controller=false --namespaced=false
-```
-
-The above command should produce a scaffold similar to the below example:
-
-```go
-type FancySQLInstanceSpec struct {
- // INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
- // Important: Run "make" to regenerate code after modifying this file
-}
-
-// FancySQLInstanceStatus defines the observed state of FancySQLInstance
-type FancySQLInstanceStatus struct {
- // INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
- // Important: Run "make" to regenerate code after modifying this file
-}
-
-// +kubebuilder:object:root=true
-
-// FancySQLInstance is the Schema for the fancysqlinstances API
-// +kubebuilder:resource:scope=Cluster
-type FancySQLInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FancySQLInstanceSpec `json:"spec,omitempty"`
- Status FancySQLInstanceStatus `json:"status,omitempty"`
-}
-```
-
-Crossplane requires that these newly generated API type scaffolds be extended
-with a set of struct fields, getters, and setters that are standard to all
-Crossplane resource kinds. The getters and setter methods required to satisfy
-crossplane-runtime interfaces are omitted from the below examples for brevity.
-They can be added by hand, but new services are encouraged to use [`angryjet`]
-to generate them automatically using a `//go:generate` comment per the
-[`angryjet` documentation].
-
-Note that in many cases a suitable provider will already exist. Frequently
-adding support for a new managed service requires only the definition of the
-managed resource itself.
-
-### Managed Resource Kinds
-
-Managed resources must:
-
-* Satisfy crossplane-runtime's [`resource.Managed`] interface.
-* Embed a [`ResourceStatus`] struct in their `Status` struct.
-* Embed a [`ResourceSpec`] struct in their `Spec` struct.
-* Embed a `Parameters` struct in their `Spec` struct.
-* Use the `+kubebuilder:subresource:status` [comment marker].
-* Use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-The `Parameters` struct should be a _high fidelity_ representation of the
-writeable fields of the external resource's API. Put otherwise, if your
-favourite cloud represents Favourite DB instances as a JSON object then
-`FavouriteDBParameters` should marshal to a something as close to that JSON
-object as possible while still complying with Kubernetes API conventions.
-
-For example, assume the external API object for Favourite DB instance was:
-
-```json
-{
- "id": 42,
- "name": "mycoolinstance",
- "fanciness_level": 100,
- "version": "2.3",
- "status": "ONLINE",
- "hostname": "cool.fcp.example.org"
-}
-```
-
-Further assume the `id`, `status`, and `hostname` fields were output only, and
-the `version` field was optional. The `FavouriteDBInstance` managed resource
-should look as follows:
-
-```go
-// FavouriteDBInstanceParameters define the desired state of an FavouriteDB
-// instance. Most fields map directly to an Instance:
-// https://favourite.example.org/api/v1/db#Instance
-type FavouriteDBInstanceParameters struct {
-
- // We're still working on a standard for naming external resources. See
- // https://github.com/crossplane/crossplane/issues/624 for context.
-
- // Name of this instance.
- Name string `json:"name"`
-
- // Note that fanciness_level becomes fancinessLevel below. Kubernetes API
- // conventions trump cloud provider fidelity.
-
- // FancinessLevel specifies exactly how fancy this instance is.
- FancinessLevel int `json:"fancinessLevel"`
-
- // Version specifies what version of FancySQL this instance will run.
- // +optional
- Version *string `json:"version,omitempty"`
-}
-
-// A FavouriteDBInstanceSpec defines the desired state of a FavouriteDBInstance.
-type FavouriteDBInstanceSpec struct {
- runtimev1alpha1.ResourceSpec `json:",inline"`
- ForProvider FavouriteDBInstanceParameters `json:"forProvider"`
-}
-
-// A FavouriteDBInstanceStatus represents the observed state of a
-// FavouriteDBInstance.
-type FavouriteDBInstanceStatus struct {
- runtimev1alpha1.ResourceStatus `json:",inline"`
-
- // Note that we add the three "output only" fields here in the status,
- // instead of the parameters. We want this representation to be high
- // fidelity just like the parameters.
-
- // ID of this instance.
- ID int `json:"id,omitempty"`
-
- // Status of this instance.
- Status string `json:"status,omitempty"`
-
- // Hostname of this instance.
- Hostname string `json:"hostname,omitempty"`
-}
-
-// A FavouriteDBInstance is a managed resource that represents a Favourite DB
-// instance.
-// +kubebuilder:subresource:status
-type FavouriteDBInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FavouriteDBInstanceSpec `json:"spec"`
- Status FavouriteDBInstanceStatus `json:"status,omitempty"`
-}
-```
-
-Note that Crossplane uses the GoDoc strings of API kinds to generate user facing
-API documentation. __Document all fields__ and prefer GoDoc that assumes the
-reader is running `kubectl explain`, or reading an API reference, not reading
-the code. Refer to the [Managed Resource API Patterns] one pager for more detail
-on authoring high fidelity managed resources.
-
-### Provider Kinds
-
-You'll typically only need to add a new Provider kind if you're creating an
-infrastructure provider that adds support for a new infrastructure provider.
-
-Providers must:
-
-* Be named exactly `Provider`.
-* Embed a [`ProviderSpec`] struct in their `Spec` struct.
-* Use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-The Favourite Cloud `Provider` would look as follows. Note that the cloud to
-which it belongs should be indicated by its API group, i.e. its API Version
-would be `favouritecloud.crossplane.io/v1alpha1` or similar.
-
-```go
-// A ProviderSpec defines the desired state of a Provider.
-type ProviderSpec struct {
- runtimev1alpha1.ProviderSpec `json:",inline"`
-
- // Information required outside of the Secret referenced in the embedded
- // runtimev1alpha1.ProviderSpec that is required to authenticate to the provider.
- // ProjectID is used as an example here.
- ProjectID string `json:"projectID"`
-}
-
-// A Provider configures a Favourite Cloud 'provider', i.e. a connection to a
-// particular Favourite Cloud project using a particular Favourite Cloud service
-// account.
-type Provider struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec ProviderSpec `json:"spec"`
-}
-```
-
-### Finishing Touches
-
-At this point we've defined the managed resource necessary to start
-building controllers. Before moving on to the controllers:
-
-* Add any kubebuilder [comment markers] that may be useful for your resource.
- Comment markers can be used to validate input, or add additional columns to
- the standard `kubectl get` output, among other things.
-* Run `make reviewable` to generate Custom Resource Definitions and additional
- helper methods for your new resource kinds.
-* Make sure any package documentation (i.e. `// Package v1alpha1...` GoDoc,
- including package level comment markers) are in a file named `doc.go`.
- kubebuilder adds them to `groupversion_info.go`, but several code generation
- tools only check `doc.go`.
-
-Finally, add convenience [`GroupVersionKind`] variables for each new resource
-kind. These are typically added to either `register.go` or
-`groupversion_info.go` depending on which version of kubebuilder scaffolded the
-API type:
-
-```go
-// FancySQLInstance type metadata.
-var (
- FancySQLInstanceKind = reflect.TypeOf(FancySQLInstance{}).Name()
- FancySQLInstanceKindAPIVersion = FancySQLInstanceKind + "." + GroupVersion.String()
- FancySQLInstanceGroupVersionKind = GroupVersion.WithKind(FancySQLInstanceKind)
-)
-```
-
-Consider opening a draft pull request and asking a Crossplane maintainer for
-review before you start work on the controller!
-
-## Adding Controllers
-
-Crossplane controllers, like those scaffolded by kubebuilder, are built around
-the [controller-runtime] library. controller-runtime flavoured controllers
-encapsulate most of their domain-specific logic in a [`reconcile.Reconciler`]
-implementation. Most Crossplane controllers are one of the three kinds mentioned
-under [What Makes a Crossplane Managed Service]. Each of these controller kinds
-are similar enough across implementations that [crossplane-runtime] provides
-'default' reconcilers. These reconcilers encode what the Crossplane community
-has learned about managing external systems and narrow the problem space from
-reconciling a Kubernetes resource kind with an arbitrary system down to
-Crossplane-specific tasks.
-
-crossplane-runtime provides the following `reconcile.Reconcilers`:
-
-* The [`managed.Reconciler`] reconciles managed resources with external systems
- by instantiating a client of the external API and using it to create, update,
- or delete the external resource as necessary.
-
-Crossplane controllers typically differ sufficiently from those scaffolded by
-kubebuilder that there is little value in using kubebuilder to generate a
-controller scaffold.
-
-### Managed Resource Controllers
-
-Managed resource controllers should use [`managed.NewReconciler`] to wrap a
-managed-resource specific implementation of [`managed.ExternalConnecter`]. Parts
-of `managed.Reconciler`'s behaviour is customisable; refer to the
-[`managed.NewReconciler`] GoDoc for a list of options. The following is an
-example controller for the `FavouriteDBInstance` managed resource we defined
-earlier:
-
-```go
-import (
- "context"
- "fmt"
- "strings"
-
- "github.com/pkg/errors"
- corev1 "k8s.io/api/core/v1"
- "k8s.io/apimachinery/pkg/types"
- ctrl "sigs.k8s.io/controller-runtime"
- "sigs.k8s.io/controller-runtime/pkg/client"
-
- // An API client of the hypothetical FavouriteDB service.
- "github.com/fcp-sdk/v1/services/database"
-
- runtimev1alpha1 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
- "github.com/crossplane/crossplane-runtime/pkg/meta"
- "github.com/crossplane/crossplane-runtime/pkg/resource"
- "github.com/crossplane/crossplane-runtime/pkg/reconciler/managed"
-
- "github.com/crossplane/provider-fcp/apis/database/v1alpha3"
- fcpv1alpha3 "github.com/crossplane/provider-fcp/apis/v1alpha3"
-)
-
-type FavouriteDBInstanceController struct{}
-
-// SetupWithManager instantiates a new controller using a managed.Reconciler
-// configured to reconcile FavouriteDBInstances using an ExternalClient produced by
-// connecter, which satisfies the ExternalConnecter interface.
-func (c *FavouriteDBInstanceController) SetupWithManager(mgr ctrl.Manager) error {
- return ctrl.NewControllerManagedBy(mgr).
- Named(strings.ToLower(fmt.Sprintf("%s.%s", v1alpha3.FavouriteDBInstanceKind, v1alpha3.Group))).
- For(&v1alpha3.FavouriteDBInstance{}).
- Complete(managed.NewReconciler(mgr,
- resource.ManagedKind(v1alpha3.FavouriteDBInstanceGroupVersionKind),
- managed.WithExternalConnecter(&connecter{client: mgr.GetClient()})))
-}
-
-// Connecter satisfies the resource.ExternalConnecter interface.
-type connecter struct{ client client.Client }
-
-// Connect to the supplied resource.Managed (presumed to be a
-// FavouriteDBInstance) by using the Provider it references to create a new
-// database client.
-func (c *connecter) Connect(ctx context.Context, mg resource.Managed) (managed.ExternalClient, error) {
- // Assert that resource.Managed we were passed in fact contains a
- // FavouriteDBInstance. We told NewControllerManagedBy that this was a
- // controller For FavouriteDBInstance, so something would have to go
- // horribly wrong for us to encounter another type.
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return nil, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Get the Provider referenced by the FavouriteDBInstance.
- p := &fcpv1alpha3.Provider{}
- if err := c.client.Get(ctx, meta.NamespacedNameOf(i.Spec.ProviderReference), p); err != nil {
- return nil, errors.Wrap(err, "cannot get Provider")
- }
-
- // Get the Secret referenced by the Provider.
- s := &corev1.Secret{}
- n := types.NamespacedName{Namespace: p.Namespace, Name: p.Spec.Secret.Name}
- if err := c.client.Get(ctx, n, s); err != nil {
- return nil, errors.Wrap(err, "cannot get Provider secret")
- }
-
- // Create and return a new database client using the credentials read from
- // our Provider's Secret.
- client, err := database.NewClient(ctx, s.Data[p.Spec.Secret.Key])
- return &external{client: client}, errors.Wrap(err, "cannot create client")
-}
-
-// External satisfies the resource.ExternalClient interface.
-type external struct{ client database.Client }
-
-// Observe the existing external resource, if any. The managed.Reconciler
-// calls Observe in order to determine whether an external resource needs to be
-// created, updated, or deleted.
-func (e *external) Observe(ctx context.Context, mg resource.Managed) (managed.ExternalObservation, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalObservation{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Use our FavouriteDB API client to get an up to date view of the external
- // resource.
- existing, err := e.client.GetInstance(ctx, i.Spec.Name)
-
- // If we encounter an error indicating the external resource does not exist
- // we want to let the managed.Reconciler know so it can create it.
- if database.IsNotFound(err) {
- return managed.ExternalObservation{ResourceExists: false}, nil
- }
-
- // Any other errors are wrapped (as is good Go practice) and returned to the
- // managed.Reconciler. It will update the "Synced" status condition
- // of the managed resource to reflect that the most recent reconcile failed
- // and ensure the reconcile is reattempted after a brief wait.
- if err != nil {
- return managed.ExternalObservation{}, errors.Wrap(err, "cannot get instance")
- }
-
- // The external resource exists. Copy any output-only fields to their
- // corresponding entries in our status field.
- i.Status.Status = existing.GetStatus()
- i.Status.Hostname = existing.GetHostname()
- i.Status.ID = existing.GetID()
-
- // Update our "Ready" status condition to reflect the status of the external
- // resource. Most managed resources use the below well known reasons that
- // the "Ready" status may be true or false, but managed resource authors
- // are welcome to define and use their own.
- switch i.Status.Status {
- case database.StatusOnline:
- // If the resource is available we also want to mark it as bindable to
- // resource claims.
- resource.SetBindable(i)
- i.SetConditions(runtimev1alpha1.Available())
- case database.StatusCreating:
- i.SetConditions(runtimev1alpha1.Creating())
- case database.StatusDeleting:
- i.SetConditions(runtimev1alpha1.Deleting())
- }
-
- // Finally, we report what we know about the external resource. In this
- // hypothetical case FancinessLevel is the only field that can be updated
- // after creation time, so the resource does not need to be updated if
- // the actual fanciness level matches our desired fanciness level. Any
- // ConnectionDetails we return will be published to the managed resource's
- // connection secret if it specified one.
- o := managed.ExternalObservation{
- ResourceExists: true,
- ResourceUpToDate: existing.GetFancinessLevel == i.Spec.FancinessLevel,
- ConnectionDetails: managed.ConnectionDetails{
- runtimev1alpha1.ResourceCredentialsSecretUserKey: []byte(existing.GetUsername()),
- runtimev1alpha1.ResourceCredentialsSecretEndpointKey: []byte(existing.GetHostname()),
- },
- }
-
- return o, nil
-}
-
-// Create a new external resource based on the specification of our managed
-// resource. managed.Reconciler only calls Create if Observe reported
-// that the external resource did not exist.
-func (e *external) Create(ctx context.Context, mg resource.Managed) (managed.ExternalCreation, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalCreation{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
- // Indicate that we're about to create the instance. Remember ExternalClient
- // authors can use a bespoke condition reason here in cases where Creating
- // doesn't make sense.
- i.SetConditions(runtimev1alpha1.Creating())
-
- // Create must return any connection details that are set or returned only
- // at creation time. The managed.Reconciler will merge any details
- // with those returned during the Observe phase.
- password := database.GeneratePassword()
- cd := managed.ConnectionDetails{runtimev1alpha1.ResourceCredentialsSecretPasswordKey: []byte(password)}
-
- // Create a new instance.
- new := database.Instance{Name: i.Name, FancinessLevel: i.FancinessLevel, Version: i.Version}
- err := e.client.CreateInstance(ctx, new, password)
-
- // Note that we use resource.Ignore to squash any error that indicates the
- // external resource already exists. Create implementations must not return
- // an error if asked to create a resource that already exists. Real managed
- // resource controllers are advised to avoid unintentially 'adoptign' an
- // existing, unrelated external resource, per
- // https://github.com/crossplane/crossplane-runtime/issues/27
- return managed.ExternalCreation{ConnectionDetails: cd}, errors.Wrap(resource.Ignore(database.IsExists, err), "cannot create instance")
-}
-
-// Update the existing external resource to match the specifications of our
-// managed resource. managed.Reconciler only calls Update if Observe
-// reported that the external resource was not up to date.
-func (e *external) Update(ctx context.Context, mg resource.Managed) (managed.ExternalUpdate, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalUpdate{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Recall that FancinessLevel is the only field that we _can_ update.
- new := database.Instance{Name: i.Name, FancinessLevel: i.FancinessLevel}
- err := e.client.UpdateInstance(ctx, new)
- return managed.ExternalUpdate{}, errors.Wrap(err, "cannot update instance")
-}
-
-// Delete the external resource. managed.Reconciler only calls Delete
-// when a managed resource with the 'Delete' reclaim policy has been deleted.
-func (e *external) Delete(ctx context.Context, mg resource.Managed) error {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return errors.New("managed resource is not a FavouriteDBInstance")
- }
- // Indicate that we're about to delete the instance.
- i.SetConditions(runtimev1alpha1.Deleting())
-
- // Delete the instance.
- err := e.client.DeleteInstance(ctx, i.Spec.Name)
-
- // Note that we use resource.Ignore to squash any error that indicates the
- // external resource does not exist. Delete implementations must not return
- // an error when asked to delete a non-existent external resource.
- return errors.Wrap(resource.Ignore(database.IsNotFound, err), "cannot delete instance")
-}
-```
-
-### Wrapping Up
-
-Once all your controllers are in place you'll want to test them. Note that most
-projects under the [crossplane org] [favor] table driven tests that use Go's
-standard library `testing` package over kubebuilder's Gingko based tests. Please
-do not add or proliferate Gingko based tests.
-
-Finally, don't forget to plumb any newly added resource kinds and controllers up
-to your controller manager. Simple providers may do this for each type within
-within `main()`, but most more complicated providers take an approach in which
-each package exposes an `AddToScheme` (for resource kinds) or `SetupWithManager`
-(for controllers) function that invokes the same function within its child
-packages, resulting in a `main.go` like:
-
-```go
-import (
- "time"
-
- "sigs.k8s.io/controller-runtime/pkg/client/config"
- "sigs.k8s.io/controller-runtime/pkg/manager"
- "sigs.k8s.io/controller-runtime/pkg/manager/signals"
-
- crossplaneapis "github.com/crossplane/crossplane/apis"
-
- fcpapis "github.com/crossplane/provider-fcp/apis"
- "github.com/crossplane/provider-fcp/pkg/controller"
-)
-
-func main() {
- cfg, err := config.GetConfig()
- if err != nil {
- panic(err)
- }
-
- mgr, err := manager.New(cfg, manager.Options{SyncPeriod: 1 * time.Hour})
- if err != nil {
- panic(err)
- }
-
- if err := crossplaneapis.AddToScheme(mgr.GetScheme()); err != nil {
- panic(err)
- }
-
- if err := fcpapis.AddToScheme(mgr.GetScheme()); err != nil {
- panic(err)
- }
-
- if err := controller.SetupWithManager(mgr); err != nil {
- panic(err)
- }
-
- panic(mgr.Start(signals.SetupSignalHandler()))
-}
-```
-
-## In Review
-
-In this guide we walked through the process of defining the resource kinds and
-controllers necessary to build support for new managed infrastructure; possibly
-even a completely new infrastructure provider. Please do not hesitate to [reach
-out] to the Crossplane maintainers and community for help designing and
-implementing support for new managed services. We would highly value any
-feedback you may have about the development process!
-
-
-
-[What Makes a Crossplane Managed Service]: #what-makes-a-crossplane-managed-service
-[managed resource]: concepts.md#managed-resource
-[dynamic provisioning]: concepts.md#dynamic-and-static-provisioning
-[`CloudMemorystoreInstance`]: https://github.com/crossplane/provider-gcp/blob/85a6ed3c669a021f1d61be51b2cbe2714b0bc70b/apis/cache/v1beta1/cloudmemorystore_instance_types.go#L184
-[`Provider`]: https://github.com/crossplane/provider-gcp/blob/85a6ed3c669a021f1d61be51b2cbe2714b0bc70b/apis/v1alpha3/types.go#L41
-[watching the API server]: https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
-[controller-runtime]: https://github.com/kubernetes-sigs/controller-runtime
-[crossplane-runtime]: https://github.com/crossplane/crossplane-runtime/
-[crossplane-runtime v0.9.0]: https://github.com/crossplane/crossplane-runtime/releases/tag/v0.9.0
-[golden path]: https://charity.wtf/2018/12/02/software-sprawl-the-golden-path-and-scaling-teams-with-agency/
-[API Conventions]: https://github.com/kubernetes/community/blob/c6e1e89a/contributors/devel/sig-architecture/api-conventions.md
-[kubebuilder book]: https://book.kubebuilder.io/
-[resources]: https://kubebuilder.io/cronjob-tutorial/gvks.html#kinds-and-resources
-[kinds]: https://kubebuilder.io/cronjob-tutorial/gvks.html#kinds-and-resources
-[objects]: https://kubernetes.io/docs/concepts/#kubernetes-objects
-[comment marker]: https://kubebuilder.io/reference/markers.html
-[comment markers]: https://kubebuilder.io/reference/markers.html
-[`resource.Managed`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/resource#Managed
-[`managed.Reconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#Reconciler
-[`managed.NewReconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#NewReconciler
-[`managed.ExternalConnecter`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalConnecter
-[`managed.ExternalClient`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalClient
-[`ResourceSpec`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ResourceSpec
-[`ResourceStatus`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ResourceStatus
-[`ProviderSpec`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ProviderSpec
-['managed.ExternalConnecter`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalConnecter
-[opening a Crossplane issue]: https://github.com/crossplane/crossplane/issues/new/choose
-[`GroupVersionKind`]: https://godoc.org/k8s.io/apimachinery/pkg/runtime/schema#GroupVersionKind
-[`reconcile.Reconciler`]: https://godoc.org/sigs.k8s.io/controller-runtime/pkg/reconcile#Reconciler
-[favor]: https://github.com/crossplane/crossplane/issues/452
-[reach out]: https://github.com/crossplane/crossplane#get-involved
-[crossplane org]: https://github.com/crossplane
-[`angryjet`]: https://github.com/crossplane/crossplane-tools
-[Managed Resource API Patterns]: ../design/one-pager-managed-resource-api-design.md
-[Crossplane CLI]: https://github.com/crossplane/crossplane-cli#quick-start-stacks
-[`angryjet` documentation]: https://github.com/crossplane/crossplane-tools/blob/master/README.md
diff --git a/docs/v0.12/faqs/faqs.md b/docs/v0.12/faqs/faqs.md
deleted file mode 100644
index 5c749815..00000000
--- a/docs/v0.12/faqs/faqs.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: FAQ
-toc: true
-weight: 1200
----
-
-# Frequently Asked Questions (FAQs)
-
-### Where did the name Crossplane come from?
-
-Crossplane is the fusing of cross-cloud control plane. We wanted to use a noun
-that refers to the entity responsible for connecting different cloud providers
-and acts as control plane across them. Cross implies “cross-cloud” and “plane”
-brings in “control plane”.
-
-### What's up with popsicle?
-
-We believe in a multi-flavor cloud.
-
-### Related Projects
-See [Related Projects].
-
-[Related Projects]: related_projects.md
\ No newline at end of file
diff --git a/docs/v0.12/faqs/related_projects.md b/docs/v0.12/faqs/related_projects.md
deleted file mode 100644
index 87f652fc..00000000
--- a/docs/v0.12/faqs/related_projects.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: Related Projects
-toc: true
-weight: 1201
-indent: true
----
-
-# Related Projects
-
-While there are many projects that address similar issues, none of them
-encapsulate the full use case that Crossplane addresses. This list is not
-exhaustive and is not meant to provide a deep analysis of the following
-projects, but instead to motivate why Crossplane was created.
-
-## Open Service Broker and Service Catalog
-
-The [Open Service Broker] and the [Kubernetes Service Catalog] are able to
-dynamically provision cloud services from Kubernetes. As a result it shares
-similar goals with Crossplane. However, service broker does not have the
-ability to define, compose, and publish your own infrastructure resources to
-the Kubernetes API in a no-code way. Crossplane goes further by enabling
-infrastructure operators to hide infrastructure complexity and include policy
-guardrails, with a team-centric approach and a strong separation of concerns,
-so applications can easily and safely consume the infrastructure they need,
-using any tool that works with the Kubernetes API. Solutions like the [GCP
-implementation of Open Service Broker][GCP OSB] have been deprecated in favor
-of a more Kubernetes-native solution, but one that is Google-specific and
-closed source.
-
-## GCP Config Connector
-
-The [GCP Config Connector] is the GCP replacement for Open Service Broker, and
-implements a set of Kubernetes controllers that are able to provision managed
-services in GCP. It defines a set of CRDs for managed services like CloudSQL,
-and controllers that can provision them via their cloud APIs. It is similar to
-Crossplane in that it can provision managed services in GCP. Crossplane goes
-further by enabling you to provision managed services from any cloud
-provider and the ability to define, compose, and publish your own
-infrastructure resources in a no-code way. Crossplane supports a team-centric
-approach with a strong separation of concerns, that enables applications to
-easily and safely consume the infrastructure they need, using any tool that
-works with the Kubernetes API. GCP Config Connector is closed-source.
-
-## AWS Service Operator
-
-The [AWS Service Operator] is a recent project that implements a set of
-Kubernetes controllers that are able to provision managed services in AWS. It
-defines a set of CRDs for managed services like DynamoDB, and controllers that
-can provision them via AWS CloudFormation. It is similar to Crossplane in that
-it can provision managed services in AWS. Crossplane goes further by
-enabling you to provision managed services from any cloud provider and the
-ability to define, compose, and publish your own infrastructure API types in
-Kubernetes in a no-code way. Crossplane supports a team-centric approach with a
-strong separation of concerns, that enables applications to easily and safely
-consume the infrastructure they need, using any tool that works with the
-Kubernetes API.
-
-## AWS CloudFormation, GCP Deployment Manager, and Others
-
-These products offer a declarative model for deploying and provisioning
-infrastructure in each of the respective cloud providers. They only work for
-one cloud provider, are generally closed source, and offer little or no
-extensibility points, let alone being able to extend the Kubernetes API to
-provide your own infrastructure abstractions in a no-code way. We have
-considered using some of these products as a way to implement resource
-controllers in Crossplane. These projects use an Infrastructure as Code
-approach to management, while Crossplane offers an API-driven control plane.
-
-## Terraform and Pulumi
-
-[Terraform] and [Pulumi] are tools for provisioning infrastructure across cloud
-providers that offer a declarative configuration language with support for
-templating, composability, referential integrity and dependency management.
-Terraform can declaratively manage any compatible API and perform changes when
-the tool is run by a human or in a deployment pipeline. Terraform is an
-Infrastructure as Code tool, while Crossplane offers an API-driven control
-plane.
-
-
-
-[Open Service Broker]: https://www.openservicebrokerapi.org/
-[Kubernetes Service Catalog]: https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/
-[GCP OSB]: https://cloud.google.com/kubernetes-engine/docs/concepts/google-cloud-platform-service-broker
-[GCP Config Connector]: https://cloud.google.com/config-connector/docs/overview
-[AWS Service Operator]: https://github.com/awslabs/aws-service-operator
-[Terraform]: https://www.terraform.io/
-[Pulumi]: https://www.pulumi.com/
diff --git a/docs/v0.12/getting-started/install-configure.md b/docs/v0.12/getting-started/install-configure.md
deleted file mode 100644
index d2d5e2e6..00000000
--- a/docs/v0.12/getting-started/install-configure.md
+++ /dev/null
@@ -1,395 +0,0 @@
----
-title: Install & Configure
-toc: true
-weight: 2
-indent: true
----
-
-# Install & Configure Crossplane
-
-Crossplane can be easily installed into any existing Kubernetes cluster using
-the regularly published Helm chart. The Helm chart contains all the custom
-resources and controllers needed to deploy and configure Crossplane.
-
-See [Install] and [Configure] docs for installing alternate versions and more
-detailed instructions.
-
-## Get a Kubernetes Cluster
-
-
-For macOS / Linux use the following:
-
-* [Kubernetes cluster]
- * [Kind]
- * [Minikube], minimum version `v0.28+`
- * etc.
-
-* [Helm], minimum version `v2.12.0+`.
- * For Helm 2, make sure Tiller is initialized with sufficient permissions to
- work on `crossplane-system` namespace.
-
-
-
-For Windows use the following:
-
-* [Kubernetes cluster]
- * [Kind]
- * [Minikube], minimum version `v0.28+`
- * etc.
-
-* [Helm], minimum version `v2.12.0+`.
- * For Helm 2, make sure Tiller is initialized with sufficient permissions to
- work on `crossplane-system` namespace.
-
-
-Use Helm 3 to install the latest official `alpha` release of Crossplane, suitable for community use and testing:
-
-```
-kubectl create namespace crossplane-system
-
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-
-# Kubernetes 1.15 and newer versions
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane
-
-# Kubernetes 1.14 and older versions
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane --disable-openapi-validation
-```
-
-
-
-Use Helm 2 to install the latest official `alpha` release of Crossplane, suitable for community use and testing:
-
-```
-kubectl create namespace crossplane-system
-
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-
-Use Helm 2 to install the latest `master` pre-release version of Crossplane, which is suitable for testing pre-release versions:
-
-```
-kubectl create namespace crossplane-system
-
-helm repo add crossplane-master https://charts.crossplane.io/master/
-helm search crossplane-master
-
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version
-```
-
-For example:
-
-```
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version 0.11.0-rc.100.gbc5d311
-```
-
-
-
-
-## Install Crossplane CLI
-The [Crossplane CLI] adds a set of `kubectl crossplane` commands to simplify common tasks:
-```
-curl -sL https://raw.githubusercontent.com/crossplane/crossplane-cli/master/bootstrap.sh | bash
-```
-
-## Select Provider
-Install and configure a provider for Crossplane to use for infrastructure provisioning:
-
-
-## Next Steps
-Now that you have a provider configured, you can [provision infrastructure].
-
-## More Info
-See [Install] and [Configure] docs for installing alternate versions and more
-detailed instructions.
-
-## Uninstall Provider
-```
-kubectl delete -f provider.yaml
-kubectl delete secret -n crossplane-system --all
-```
-
-## Uninstall Crossplane
-```
-helm delete crossplane --namespace crossplane-system
-```
-
-
-
-[provision infrastructure]: provision-infrastructure.md
-[Install]: ../reference/install.md
-[Configure]: ../reference/configure.md
-[Kubernetes cluster]: https://kubernetes.io/docs/setup/
-[Minikube]: https://kubernetes.io/docs/tasks/tools/install-minikube/
-[Helm]: https://docs.helm.sh/using_helm/
-[Kind]: https://kind.sigs.k8s.io/docs/user/quick-start/
-[Crossplane CLI]: https://github.com/crossplane/crossplane-cli
diff --git a/docs/v0.12/getting-started/provision-infrastructure.md b/docs/v0.12/getting-started/provision-infrastructure.md
deleted file mode 100644
index 922885a3..00000000
--- a/docs/v0.12/getting-started/provision-infrastructure.md
+++ /dev/null
@@ -1,249 +0,0 @@
----
-title: Provision Infrastructure
-toc: true
-weight: 3
-indent: true
----
-
-# Provision Infrastructure
-
-Crossplane allows you to provision infrastructure anywhere using the Kubernetes
-API. Once you have [installed a provider] and [configured your credentials], you
-can create any infrastructure resource currently supported by the provider.
-Let's start by provisioning a database on your provider of choice.
-
-Each provider below offers their own flavor of a managed database. When the
-provider is installed into your Crossplane cluster, it installs a cluster-scoped
-CRD that represents the managed service offering, as well as controllers that
-know how to create, update, and delete instances of the service on the cloud
-provider.
-
-
-
-The AWS provider supports provisioning an [RDS] instance with the `RDSInstance`
-CRD it installs into your cluster.
-
-```yaml
-apiVersion: database.aws.crossplane.io/v1beta1
-kind: RDSInstance
-metadata:
- name: rdspostgresql
-spec:
- forProvider:
- dbInstanceClass: db.t2.small
- masterUsername: masteruser
- allocatedStorage: 20
- engine: postgres
- engineVersion: "9.6"
- skipFinalSnapshotBeforeDeletion: true
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: aws-rdspostgresql-conn
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.12/docs/snippets/provision/aws.yaml
-```
-
-Creating the above instance will cause Crossplane to provision an RDS instance
-on AWS. You can view the progress with the following command:
-
-```console
-kubectl get rdsinstances.database.aws.crossplane.io rdspostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can then delete the `RDSInstance`:
-
-```console
-kubectl delete rdsinstances.database.aws.crossplane.io rdspostgresql
-```
-
-
-
-
-The GCP provider supports provisioning a [CloudSQL] instance with the
-`CloudSQLInstance` CRD it installs into your cluster.
-
-```yaml
-apiVersion: database.gcp.crossplane.io/v1beta1
-kind: CloudSQLInstance
-metadata:
- name: cloudsqlpostgresql
-spec:
- forProvider:
- databaseVersion: POSTGRES_9_6
- region: us-central1
- settings:
- tier: db-custom-1-3840
- dataDiskType: PD_SSD
- dataDiskSizeGb: 10
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: cloudsqlpostgresql-conn
- providerRef:
- name: gcp-provider
- reclaimPolicy: Delete
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.12/docs/snippets/provision/gcp.yaml
-```
-
-Creating the above instance will cause Crossplane to provision a CloudSQL
-instance on GCP. You can view the progress with the following command:
-
-```console
-kubectl get cloudsqlinstances.database.gcp.crossplane.io cloudsqlpostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can then delete the `CloudSQLInstance`:
-
-```console
-kubectl delete cloudsqlinstances.database.gcp.crossplane.io cloudsqlpostgresql
-```
-
-
-
-
-The Azure provider supports provisioning an [Azure Database for PostgreSQL]
-instance with the `PostgreSQLServer` CRD it installs into your cluster.
-
-> Note: provisioning an Azure Database for PostgreSQL requires the presence of a
-> [Resource Group] in your Azure account. We go ahead and provision a new
-> `ResourceGroup` here in case you do not already have a suitable one in your
-> account.
-
-```yaml
-apiVersion: azure.crossplane.io/v1alpha3
-kind: ResourceGroup
-metadata:
- name: sqlserverpostgresql-rg
-spec:
- location: West US 2
- reclaimPolicy: Delete
- providerRef:
- name: azure-provider
----
-apiVersion: database.azure.crossplane.io/v1beta1
-kind: PostgreSQLServer
-metadata:
- name: sqlserverpostgresql
-spec:
- forProvider:
- administratorLogin: myadmin
- resourceGroupNameRef:
- name: sqlserverpostgresql-rg
- location: West US 2
- sslEnforcement: Disabled
- version: "9.6"
- sku:
- tier: GeneralPurpose
- capacity: 2
- family: Gen5
- storageProfile:
- storageMB: 20480
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: sqlserverpostgresql-conn
- providerRef:
- name: azure-provider
- reclaimPolicy: Delete
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.12/docs/snippets/provision/azure.yaml
-```
-
-Creating the above instance will cause Crossplane to provision a PostgreSQL
-database instance on Azure. You can view the progress with the following
-command:
-
-```console
-kubectl get postgresqlservers.database.azure.crossplane.io sqlserverpostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can then delete the `PostgreSQLServer`:
-
-```console
-kubectl delete postgresqlservers.database.azure.crossplane.io sqlserverpostgresql
-kubectl delete resourcegroup.azure.crossplane.io sqlserverpostgresql-rg
-```
-
-
-
-
-The Alibaba provider supports provisioning an [ApsaraDB for RDS] instance with
-the `RDSInstance` CRD it installs into your cluster.
-
-```yaml
-apiVersion: database.alibaba.crossplane.io/v1alpha1
-kind: RDSInstance
-metadata:
- name: rdspostgresql
-spec:
- forProvider:
- engine: PostgreSQL
- engineVersion: "9.4"
- dbInstanceClass: rds.pg.s1.small
- dbInstanceStorageInGB: 20
- securityIPList: "0.0.0.0/0"
- masterUsername: "test123"
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: alibaba-rdspostgresql-conn
- providerRef:
- name: alibaba-provider
- reclaimPolicy: Delete
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.12/docs/snippets/provision/alibaba.yaml
-```
-
-Creating the above instance will cause Crossplane to provision an RDS instance
-on Alibaba. You can view the progress with the following command:
-
-```console
-kubectl get rdsinstances.database.alibaba.crossplane.io rdspostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can then delete the `RDSInstance`:
-
-```console
-kubectl delete rdsinstances.database.alibaba.crossplane.io rdspostgresql
-```
-
-
-
-
-## Next Steps
-
-Now that you have seen how to provision individual infrastructure resources,
-let's take a look at how we can compose infrastructure resources together and
-publish them as a single unit to be consumed in the [next section].
-
-
-
-[installed a provider]: install-configure.md
-[configured your credentials]: install-configure.md
-[RDS]: https://aws.amazon.com/rds/
-[CloudSQL]: https://cloud.google.com/sql
-[Azure Database for PostgreSQL]: https://azure.microsoft.com/en-us/services/postgresql/
-[Resource Group]: https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal#what-is-a-resource-group
-[ApsaraDB for RDS]: https://www.alibabacloud.com/product/apsaradb-for-rds-postgresql
-[next section]: publish-infrastructure.md
diff --git a/docs/v0.12/getting-started/publish-infrastructure.md b/docs/v0.12/getting-started/publish-infrastructure.md
deleted file mode 100644
index b4d40c2c..00000000
--- a/docs/v0.12/getting-started/publish-infrastructure.md
+++ /dev/null
@@ -1,829 +0,0 @@
----
-title: Publish Infrastructure
-toc: true
-weight: 4
-indent: true
----
-
-# Publish Infrastructure
-
-Provisioning infrastructure using the Kubernetes API is a powerful capability,
-but combining primitive infrastructure resources into a single unit and
-publishing them to be provisioned by developers and consumed by applications
-greatly enhances this functionality.
-
-As mentioned in the [last section], CRDs that represent infrastructure resources
-on a provider are installed at the *cluster scope*. However, applications are
-typically provisioned at the *namespace scope* using Kubernetes primitives such
-as `Pod` or `Deployment`. To make infrastructure resources available to be
-provisioned at the namespace scope, they can be *published*. This consists of
-creating the following resources:
-
-- `InfrastructureDefinition`: defines a new kind of composite resource
-- `InfrastructurePublication`: makes an `InfrastructureDefinition` available at
- the namespace scope
-- `Composition`: defines one or more resources and their configuration
-
-In addition to making provisioning available at the namespace scope,
-[composition] also allows for multiple types of managed resources to satisfy the
-same namespace-scoped resource. In the examples below, we will define and
-publish a new `PostgreSQLInstance` resource that only takes a single `storageGB`
-parameter, and specifies that it will create a connection `Secret` with keys for
-`username`, `password`, and `endpoint`. We will then create a `Composition` for
-each provider that can satisfy and be parameterized by a `PostgreSQLInstance`.
-Let's get started!
-
-## Grant RBAC Permissions
-
-Crossplane must be granted RBAC permissions to manage new infrastructure types
-that we define. This is covered in greater detail in the [composition] section,
-but you can easily run the following command now to grant all necessary RBAC
-permissions for the remainder of this quick start guide:
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.12/docs/snippets/publish/clusterrole.yaml
-```
-
-## Create InfrastructureDefinition
-
-The next step is defining an `InfrastructureDefinition` that declares the schema
-for a `PostgreSQLInstance`. You will notice that this looks very similar to a CRD,
-and after the `InfrastructureDefinition` is created, we will in fact have a
-`PostgreSQLInstance` CRD present in our cluster.
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: InfrastructureDefinition
-metadata:
- name: postgresqlinstances.database.example.org
-spec:
- connectionSecretKeys:
- - username
- - password
- - endpoint
- - port
- crdSpecTemplate:
- group: database.example.org
- version: v1alpha1
- names:
- kind: PostgreSQLInstance
- listKind: PostgreSQLInstanceList
- plural: postgresqlinstances
- singular: postgresqlinstance
- validation:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- parameters:
- type: object
- properties:
- storageGB:
- type: integer
- required:
- - storageGB
- required:
- - parameters
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.12/docs/snippets/publish/definition.yaml
-```
-
-You are now able to create instances of kind `PostgreSQLInstance` at the cluster
-scope.
-
-## Create InfrastructurePublication
-
-The `InfrastructureDefinition` will make it possible to create
-`PostgreSQLInstance` objects in our Kubernetes cluster at the cluster scope, but
-we want to make them available at the namespace scope as well. This is done by
-defining an `InfrastructurePublication` that references the new
-`PostgreSQLInstance` type.
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: InfrastructurePublication
-metadata:
- name: postgresqlinstances.database.example.org
-spec:
- infrastructureDefinitionRef:
- name: postgresqlinstances.database.example.org
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.12/docs/snippets/publish/publication.yaml
-```
-
-This will create a new CRD named `PostgreSQLInstanceRequirement`, which is the
-namespace-scoped variant of the `PostgreSQLInstance` CRD. You are now able to
-create instances of kind `PostgreSQLInstanceRequirement` at the namespace scope.
-
-## Create Compositions
-
-Now it is time to define the resources that represent the primitive
-infrastructure units that actually get provisioned. For each provider we will
-define a `Composition` that satisfies the requirements of the
-`PostgreSQLInstance` `InfrastructureDefinition`. In this case, each will result
-in the provisioning of a public PostgreSQL instance on the provider.
-
-
-
-## Create Requirement
-
-Now that we have defined our new type of infrastructure (`PostgreSQLInstance`)
-and created at least one composition that can satisfy it, we can create a
-`PostgreSQLInstanceRequirement` in the namespace of our choosing. In each
-`Composition` we defined we added a `provider: ` label. In the
-`PostgreSQLInstanceRequirement` below we can use the `compositionSelector` to
-match our `Composition` of choice.
-
-
-
-After creating the `PostgreSQLInstanceRequirement` Crossplane will provision a
-database instance on your provider of choice. Once provisioning is complete, you
-should see `READY: True` in the output when you run:
-
-```console
-kubectl get postgresqlinstancerequirement.database.example.org my-db
-```
-
-> Note: while waiting for the `PostgreSQLInstanceRequirement` to become ready, you
-> may want to look at other resources in your cluser. The following commands
-> will allow you to view groups of Crossplane resources:
->
-> - `kubectl get managed`: get all resources that represent a unit of external
-> infrastructure
-> - `kubectl get `: get all resources related to ``
-> - `kubectl get crossplane`: get all resources related to Crossplane
-
-You should also see a `Secret` in the `default` namespace named `db-conn` that
-contains fields for `username`, `password`, and `endpoint`:
-
-```console
-kubectl get secrets db-conn
-```
-
-## Consume Infrastructure
-
-Because connection secrets are written as a Kubernetes `Secret` they can easily
-be consumed by Kubernetes primitives. The most basic building block in
-Kubernetes is the `Pod`. Let's define a `Pod` that will show that we are able to
-connect to our newly provisioned database.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: see-db
- namespace: default
-spec:
- containers:
- - name: see-db
- image: postgres:9.6
- command: ['psql']
- args: ['-c', 'SELECT current_database();']
- env:
- - name: PGDATABASE
- value: postgres
- - name: PGHOST
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: endpoint
- - name: PGUSER
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: username
- - name: PGPASSWORD
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: password
- - name: PGPORT
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: port
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.12/docs/snippets/publish/pod.yaml
-```
-
-This `Pod` simply connects to a PostgreSQL database and prints its name, so you
-should see the following output (or similar) after creating it if you run
-`kubectl logs see-db`:
-
-```SQL
- current_database
-------------------
- postgres
-(1 row)
-```
-
-## Clean Up
-
-To clean up the infrastructure that was provisioned, you can delete the
-`PostgreSQLInstanceRequirement`:
-
-```console
-kubectl delete postgresqlinstancerequirement.database.example.org my-db
-```
-
-To clean up the `Pod`, run:
-
-```console
-kubectl delete pod see-db
-```
-
-> Don't clean up your `InfrastructureDefinition`, `InfrastructurePublication`,
-> or `Composition` just yet if you plan to continue on to the next section of
-> the guide! We'll use them again when we deploy an OAM application.
-
-## Next Steps
-
-Now you have seen how to provision and publish more complex infrastructure
-setups. In the [next section] you will learn how to consume infrastructure
-alongside your [OAM] application manifests.
-
-
-
-[last section]: provision-infrastructure.yaml
-[composition]: ../introduction/composition.md
-[next section]: run-applications.md
-[OAM]: https://oam.dev/
diff --git a/docs/v0.12/getting-started/run-applications-dash.png b/docs/v0.12/getting-started/run-applications-dash.png
deleted file mode 100644
index 5390190b..00000000
Binary files a/docs/v0.12/getting-started/run-applications-dash.png and /dev/null differ
diff --git a/docs/v0.12/getting-started/run-applications-diagram.jpg b/docs/v0.12/getting-started/run-applications-diagram.jpg
deleted file mode 100644
index 16037640..00000000
Binary files a/docs/v0.12/getting-started/run-applications-diagram.jpg and /dev/null differ
diff --git a/docs/v0.12/getting-started/run-applications-flights.png b/docs/v0.12/getting-started/run-applications-flights.png
deleted file mode 100644
index c7d3b8d0..00000000
Binary files a/docs/v0.12/getting-started/run-applications-flights.png and /dev/null differ
diff --git a/docs/v0.12/getting-started/run-applications.md b/docs/v0.12/getting-started/run-applications.md
deleted file mode 100644
index 027f7a20..00000000
--- a/docs/v0.12/getting-started/run-applications.md
+++ /dev/null
@@ -1,503 +0,0 @@
----
-title: Run Applications
-toc: true
-weight: 5
-indent: true
----
-
-# Run Applications
-
-Crossplane strives to be the best Kubernetes add-on to provision and manage the
-infrastructure and services your applications need directly from kubectl. A huge
-part of this mission is arriving at an elegant, flexible way to model and manage
-cloud native applications. Crossplane allows your team to deploy and run
-applications using the [Open Application Model] (OAM).
-
-OAM is a team-centric model for cloud native apps. Like Crossplane, OAM focuses
-on the different people who might be involved in the deployment of a cloud
-native application. In this getting started guide:
-
-* _Infrastructure Operators_ provide the infrastructure applications need.
-* _Application Developers_ build and supply the components of an application.
-* _Application Operators_ compose, deploy, and run application configurations.
-
-We'll play the roles of each of these team members as we deploy an application -
-Service Tracker - that consists of several services. One of these services, the
-`data-api`, is backed by a managed PostgreSQL database that is provisioned
-on-demand by Crossplane.
-
-![Service Tracker Diagram]
-
-> This guide follows on from the previous one in which we covered defining,
-> composing, and [publishing infrastructure]. You'll need to have defined and
-> published a PostgreSQLInstance with at least one working Composition in order
-> to create the OAM application we'll use in this guide.
-
-## Infrastructure Operator
-
-### Install workloads and traits
-
-As the infrastructure operator our work is almost done - we defined, published,
-and composed the infrastructure that our application developer and operator
-teammates will use in the previous guide. One task remains, which is to define
-the [_workloads_] and [_traits_] that our platform supports.
-
-OAM applications consist of workloads, each of which may be modified by traits.
-The infrastructure operator may choose which workloads and traits by creating
-or deleting `WorkloadDefinitions` and `TraitDefinitions` like below:
-
-```yaml
----
-apiVersion: core.oam.dev/v1alpha2
-kind: WorkloadDefinition
-metadata:
- name: containerizedworkloads.core.oam.dev
-spec:
- definitionRef:
- name: containerizedworkloads.core.oam.dev
-```
-Run the following command to add support for all the workloads and traits required
-by this guide:
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.12/docs/snippets/run/definitions.yaml
-```
-
-Now that we've defined our workloads and traits, we must install Crossplane's OAM addon. This addon
-packages the controllers that reconcile core OAM workloads and traits.
-
-
-Use Helm 3 to install the latest official `alpha` release of Crossplane OAM
-Addon, suitable for community use and testing:
-
-```console
-kubectl create namespace crossplane-system
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install addon-oam-kubernetes-local --namespace crossplane-system crossplane-alpha/oam-core-resources
-```
-
-> Note that the OAM Addon requires at least Kubernetes 1.16.
-
-
-
-Use Helm 2 to install the latest official `alpha` release of the Crossplane OAM
-Addon, suitable for community use and testing:
-
-```console
-kubectl create namespace crossplane-system
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name addon-oam-kubernetes-local --namespace crossplane-system crossplane-alpha/oam-core-resources
-```
-
-> Note that the OAM Addon requires at least Kubernetes 1.16.
-
-
-
-
-## Application Developer
-
-### Publish Application Components
-
-Now we'll play the role of the application developer. Our Service Tracker
-application consists of a UI service, four API services, and a PostgreSQL
-database. Under the Open Application Model application developers define
-[_components_] that application operators may compose into applications, which
-produce workloads. Creating components allows us as application developers to
-communicate any fundamental, suggested, or optional properties of our services
-and their infrastructure requirements.
-
-```yaml
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: data-api-database
-spec:
- workload:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstanceRequirement
- metadata:
- name: app-postgresql
- spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- guide: quickstart
- parameters:
- - name: database-secret
- description: Secret to which to write PostgreSQL database connection details.
- required: true
- fieldPaths:
- - spec.writeConnectionSecretToRef.name
- - name: database-provider
- description: |
- Cloud provider that should be used to create a PostgreSQL database.
- Either alibaba, aws, azure, or gcp.
- fieldPaths:
- - spec.compositionSelector.matchLabels.provider
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: data-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: data-api
- spec:
- containers:
- - name: data-api
- image: artursouza/rudr-data-api:0.50
- env:
- - name: DATABASE_USER
- fromSecret:
- key: username
- - name: DATABASE_PASSWORD
- fromSecret:
- key: password
- - name: DATABASE_HOSTNAME
- fromSecret:
- key: endpoint
- - name: DATABASE_PORT
- fromSecret:
- key: port
- - name: DATABASE_NAME
- value: postgres
- - name: DATABASE_DRIVER
- value: postgresql
- ports:
- - name: http
- containerPort: 3009
- protocol: TCP
- livenessProbe:
- exec:
- command: [wget, -q, http://127.0.0.1:3009/status, -O, /dev/null, -S]
- parameters:
- - name: database-secret
- description: Secret from which to read PostgreSQL connection details.
- required: true
- fieldPaths:
- - spec.containers[0].env[0].fromSecret.name
- - spec.containers[0].env[1].fromSecret.name
- - spec.containers[0].env[2].fromSecret.name
- - spec.containers[0].env[3].fromSecret.name
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: flights-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: flights-api
- spec:
- containers:
- - name: flights-api
- image: sonofjorel/rudr-flights-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3003
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: quakes-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: quakes-api
- spec:
- containers:
- - name: quakes-api
- image: sonofjorel/rudr-quakes-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3012
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: service-tracker-ui
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: web-ui
- spec:
- containers:
- - name: service-tracker-ui
- image: sonofjorel/rudr-web-ui:0.49
- env:
- - name: FLIGHT_API_ROOT
- - name: WEATHER_API_ROOT
- - name: QUAKES_API_ROOT
- ports:
- - name: http
- containerPort: 8080
- protocol: TCP
- parameters:
- - name: flights-uri
- description: URI at which the flights service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
- - name: weather-uri
- description: URI at which the weather service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[1].value
- - name: quakes-uri
- description: URI at which the quakes service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[2].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: weather-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: weather-api
- spec:
- containers:
- - name: weather-api
- image: sonofjorel/rudr-weather-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3015
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.12/docs/snippets/run/components.yaml
-```
-
-Each of the above components describes a particular kind of workload. The
-Service Tracker application consists of two kinds of workload:
-
-* A [`ContainerizedWorkload`] is a long-running containerized process.
-* A `PostSQLInstanceRequirement` is a PostgreSQL instance and database.
-
-All OAM components configure a kind of workload, and any kind of Kubernetes
-resource may act as an OAM workload as long as an infrastructure operator has
-allowed it to by authoring a `WorkloadDefinition`.
-
-## Application Operator
-
-### Run The Application
-
-Finally, we'll play the role of an application operator and tie together the
-application components and infrastructure that our application developer and
-infrastructure operator team-mates have published. In OAM this is done by
-authoring an [_application configuration_]:
-
-```yaml
-apiVersion: core.oam.dev/v1alpha2
-kind: ApplicationConfiguration
-metadata:
- name: service-tracker
-spec:
- components:
- - componentName: data-api-database
- parameterValues:
- - name: database-secret
- value: tracker-database-secret
- - componentName: data-api
- parameterValues:
- - name: database-secret
- value: tracker-database-secret
- - componentName: flights-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: flights-api
- spec:
- replicaCount: 2
- - componentName: quakes-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: quakes-api
- spec:
- replicaCount: 2
- - componentName: weather-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: weather-api
- spec:
- replicaCount: 2
- - componentName: service-tracker-ui
- parameterValues:
- - name: flights-uri
- value: "http://flights-api.default.svc.cluster.local:3003/"
- - name: weather-uri
- value: "http://weather-api.default.svc.cluster.local:3015/"
- - name: quakes-uri
- value: "http://quakes-api.default.svc.cluster.local:3012/"
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.12/docs/snippets/run/appconfig.yaml
-```
-
-This application configuration names each of components the application
-developer created earlier to produce workloads. The application operator may (or
-in some cases _must_) provide parameter values for a component in order to
-override or specify certain configuration values. Component parameters represent
-configuration settings that the component author - the application developer -
-deemed to be of interest to application operators.
-
-```yaml
-- componentName: data-api-database
- parameterValues:
- - name: database-provider
- value: azure
-```
-
-> If you created Compositions for more than one provider in the previous guide
-> you can add the above parameter to the `data-api-database` component to choose
-> which cloud provider the Service Tracker's database should run on.
-
-You might notice that some components include a [`ManualScalerTrait`]. Traits
-augment the workload produced by a component with additional features, allowing
-application operators to make decisions about the configuration of a component
-without having to involve the developer. The `ManualScalerTrait` allows an
-application operator to specify how many replicas should exist of any scalable
-kind of workload.
-
-> Note that the OAM spec also includes the concept of an _application scope_.
-> Crossplane does not yet support scopes.
-
-## Use The Application
-
-Finally, we'll open and use the Service Tracker application we just deployed.
-
-
-
-If you deployed Service Tracker to a managed cluster like AKS, ACK, EKS, or GKE
-with support for load balancer Services you should be able to browse to the IP
-of the `web-ui` service on port 8080 - for example .
-
-```console
-kubectl get svc web-ui -o=jsonpath={.status.loadBalancer.ingress[0].ip}
-```
-
-
-
-
-If you're using a cluster that doesn't support load balancer Services, like Kind
-or Minikube you can use a port forward instead, and connect to
-
-
-```console
-kubectl port-forward deployment/web-ui 8080
-```
-
-
-
-
-You should see the Service Tracker dashboard in your browser. Hit 'Refresh Data'
-for each of the services to ensure the Service Tracker web UI can connect to its
-various data API services and populate its PostgreSQL database:
-
-![Service Tracker Dashboard]
-
-If everything was successful you should be able to browse to Flights,
-Earthquakes, or Weather to see what's going on in the world today:
-
-![Service Tracker Flights]
-
-## Clean Up
-
-To shut down your application, simply run:
-
-```console
-kubectl delete applicationconfiguration service-tracker
-```
-
-If you also wish to delete the components, workload definitions, and trait
-definitions we created in this guide, run:
-
-```console
-kubectl delete -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.12/docs/snippets/run/components.yaml
-kubectl delete -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.12/docs/snippets/run/definitions.yaml
-```
-
-[Open Application Model]: https://oam.dev/
-[publishing infrastructure]: publish-infrastructure.md
-[Service Tracker Diagram]: run-applications-diagram.jpg
-[_workloads_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/3.workload.md
-[_traits_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/6.traits.md
-[_components_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/4.component.md
-[_application configuration_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/7.application_configuration.md
-[`ContainerizedWorkload`]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/core/workloads/containerized_workload/containerized_workload.md
-[`ManualScalerTrait`]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/core/traits/manual_scaler_trait.md
-[_application scope_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/5.application_scopes.md
-[Service Tracker Dashboard]: run-applications-dash.png
-[Service Tracker Flights]: run-applications-flights.png
diff --git a/docs/v0.12/guides/argocd.md b/docs/v0.12/guides/argocd.md
deleted file mode 100644
index 10fa909d..00000000
--- a/docs/v0.12/guides/argocd.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Argo CD
-toc: true
-weight: 201
-indent: true
-redirect_to: https://aws.amazon.com/blogs/opensource/connecting-aws-managed-services-to-your-argo-cd-pipeline-with-open-source-crossplane/
----
\ No newline at end of file
diff --git a/docs/v0.12/guides/guides.md b/docs/v0.12/guides/guides.md
deleted file mode 100644
index e92918bb..00000000
--- a/docs/v0.12/guides/guides.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: Guides
-toc: true
-weight: 200
----
-
-# Guides
-
-Because of Crossplane's standardization on the Kubernetes API, it integrates
-well with many other projects. Below is a collection of guides and tutorials that
-demonstrate how to use Crossplane with a variety tools and projects often used
-with Kubernetes plus some deep dive content on Crossplane itself!
-
-- [Argo CD] - use GitOps to provision managed services with Crossplane and Argo CD.
-- [Knative] - use managed services provisioned by Crossplane in your Knative services.
-- [Okteto] - use managed services in your Okteto development workflow.
-- [Open Policy Agent] - set global policy on provisioning cloud resources with Crossplane and OPA.
-- [OpenFaaS] - consume managed services with for your serverless functions.
-- [Provider Internals] - translate provider APIs into managed resource CRDs and explore managed resource API patterns & best practices.
-- [Velero] - backup and restore your Crossplane infrastructure resources.
-
-
-
-[Velero]: https://www.youtube.com/watch?v=eV_2QoMRqGw&list=PL510POnNVaaYFuK-B_SIUrpIonCtLVOzT&index=18&t=183s
-[Argo CD]: https://aws.amazon.com/blogs/opensource/connecting-aws-managed-services-to-your-argo-cd-pipeline-with-open-source-crossplane/
-[Open Policy Agent]: https://github.com/crossplane/tbs/tree/master/episodes/14
-[Knative]: https://github.com/crossplane/tbs/tree/master/episodes/15
-[OpenFaaS]: https://github.com/crossplane/tbs/tree/master/episodes/13
-[Okteto]: https://github.com/crossplane/tbs/tree/master/episodes/10
-[Provider Internals]: https://github.com/crossplane/tbs/tree/master/episodes/7
\ No newline at end of file
diff --git a/docs/v0.12/guides/knative.md b/docs/v0.12/guides/knative.md
deleted file mode 100644
index 6dfd0f2b..00000000
--- a/docs/v0.12/guides/knative.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Knative
-toc: true
-weight: 202
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/15
----
\ No newline at end of file
diff --git a/docs/v0.12/guides/okteto.md b/docs/v0.12/guides/okteto.md
deleted file mode 100644
index 85c250ca..00000000
--- a/docs/v0.12/guides/okteto.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Okteto
-toc: true
-weight: 203
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/10
----
\ No newline at end of file
diff --git a/docs/v0.12/guides/opa.md b/docs/v0.12/guides/opa.md
deleted file mode 100644
index 971446cb..00000000
--- a/docs/v0.12/guides/opa.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Open Policy Agent
-toc: true
-weight: 204
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/14
----
\ No newline at end of file
diff --git a/docs/v0.12/guides/openfaas.md b/docs/v0.12/guides/openfaas.md
deleted file mode 100644
index dad6f2cb..00000000
--- a/docs/v0.12/guides/openfaas.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: OpenFaaS
-toc: true
-weight: 205
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/13
----
\ No newline at end of file
diff --git a/docs/v0.12/guides/provider-internals.md b/docs/v0.12/guides/provider-internals.md
deleted file mode 100644
index 1e201d01..00000000
--- a/docs/v0.12/guides/provider-internals.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Provider Internals
-toc: true
-weight: 206
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/7
----
\ No newline at end of file
diff --git a/docs/v0.12/guides/velero.md b/docs/v0.12/guides/velero.md
deleted file mode 100644
index 79fc1fc6..00000000
--- a/docs/v0.12/guides/velero.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Velero
-toc: true
-weight: 207
-indent: true
-redirect_to: https://www.youtube.com/watch?v=eV_2QoMRqGw&list=PL510POnNVaaYFuK-B_SIUrpIonCtLVOzT&index=18&t=183s
----
\ No newline at end of file
diff --git a/docs/v0.12/introduction/composition-concepts.png b/docs/v0.12/introduction/composition-concepts.png
deleted file mode 100644
index a2d684e4..00000000
Binary files a/docs/v0.12/introduction/composition-concepts.png and /dev/null differ
diff --git a/docs/v0.12/introduction/composition-provisioning.png b/docs/v0.12/introduction/composition-provisioning.png
deleted file mode 100644
index db664080..00000000
Binary files a/docs/v0.12/introduction/composition-provisioning.png and /dev/null differ
diff --git a/docs/v0.12/introduction/composition.md b/docs/v0.12/introduction/composition.md
deleted file mode 100644
index a74f3b1c..00000000
--- a/docs/v0.12/introduction/composition.md
+++ /dev/null
@@ -1,913 +0,0 @@
----
-title: Publishing Infrastructure
-toc: true
-weight: 103
-indent: true
----
-
-# Publishing Infrastructure
-
-Crossplane allows infrastructure operators to define and compose new kinds of
-infrastructure resources then publish them for the application operators they
-support to use, all without writing any code.
-
-Infrastructure providers extend Crossplane, enabling it to manage a wide array
-of infrastructure resources like Azure SQL servers and AWS ElastiCache clusters.
-Infrastructure composition allows infrastructure operators to define, share, and
-reuse new kinds of infrastructure resources that are _composed_ of these
-infrastructure resources. Infrastructure operators may configure one or more
-compositions of any defined resource, and may publish any defined resource to
-their application operators, who may then declare that their application
-requires that kind of resource.
-
-Composition can be used to build a catalogue of kinds and configuration classes
-of infrastructure that fit the needs and opinions of your organisation. As an
-infrastructure operator you might define your own `MySQLInstance` resource. This
-resource would allow your application operators to configure only the settings
-that _your_ organisation needs - perhaps engine version and storage size. All
-other settings are deferred to a selectable composition representing a
-configuration class like "production" or "staging". Compositions can hide
-infrastructure complexity and include policy guardrails so that applications can
-easily and safely consume the infrastructure they need, while conforming to your
-organisational best-practices.
-
-> Note that composition is an **experimental** feature of Crossplane. Refer to
-> [Current Limitations] for information on functionality that is planned but not
-> yet implemented.
-
-## Concepts
-
-![Infrastructure Composition Concepts]
-
-A _Composite_ infrastructure resource is composed of other resources. Its
-configuration schema is user-defined. The `MySQLInstance` resources in the above
-diagram are composite infrastructure resources.
-
-A `Composition` specifies how Crossplane should reconcile a composite
-infrastructure resource - i.e. what infrastructure resources it should compose.
-For example the Azure `Composition` configures Crossplane to reconcile a
-`MySQLInstance` with an Azure `MySQLServer` and a `MySQLServerFirewallRule`.
-
-A _Requirement_ for an infrastructure resource declares that an application
-requires a particular kind of composite infrastructure resource, as well as
-specifying how to configure that resource. The `MySQLInstanceRequirement`
-resources in the above diagram declare that the application pods each require a
-`MySQLInstance`.
-
-An `InfrastructureDefinition` defines a new kind of composite infrastructure
-resource. The `InfrastructureDefinition` in the above diagram defines the
-existence and schema of the `MySQLInstance` composite infrastructure resource.
-
-An `InfrastructurePublication` publishes a defined composite infrastructure
-resource, allowing application operators to declare a requirement for it. The
-`InfrastructurePublication` in the above diagram allows application operators to
-author a `MySQLInstanceRequirement`.
-
-> Note that composite resources and compositions are _cluster scoped_ - they
-> exist outside of any Kubernetes namespace. A requirement is a namespaced proxy
-> for a composite resource. This enables an RBAC model under which application
-> operators may only interact with infrastructure via requirements.
-
-## Defining and Publishing Infrastructure
-
-New kinds of infrastructure resource are typically defined and published by an
-infrastructure operator. There are three steps to this process:
-
-1. Define your resource and its schema.
-1. Specify one or more possible ways your resource may be composed.
-1. Optionally, publish your resource so that applications may require it.
-
-### Define your Infrastructure Resource
-
-Infrastructure resources are defined by an `InfrastructureDefinition`:
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: InfrastructureDefinition
-metadata:
- # InfrastructureDefinitions follow the constraints of CustomResourceDefinition
- # names. They must be named ., per the plural and group names
- # configured by the crdSpecTemplate below.
- name: mysqlinstances.example.org
-spec:
- # Composite infrastructure resources may optionally expose a connection secret
- # - a Kubernetes Secret containing all of the details a pod might need to
- # connect to the infrastructure resource. Resources that wish to expose a
- # connection secret must declare what keys they support. These keys form a
- # 'contract' - any composition that intends to be compatible with this
- # infrastructure resource must compose resources that supply these connection
- # secret keys.
- connectionSecretKeys:
- - username
- - password
- - hostname
- - port
- # You can specify a default Composition resource to be selected if there is
- # no composition selector or reference was supplied on the Custom Resource.
- defaultCompositionRef:
- name: example-azure
- # Enforced composition will be selected for all instances of this type and it
- # will override the selectors and referencers that are different.
- #
- #enforcedCompositionRef:
- # name: securemysql.acme.org
- #
- # A template for the spec of a CustomResourceDefinition. Only the group,
- # version, names, validation, and additionalPrinterColumns fields of a CRD
- # spec are supported.
- crdSpecTemplate:
- group: example.org
- version: v1alpha1
- names:
- kind: MySQLInstance
- listKind: MySQLInstanceList
- plural: mysqlinstances
- singular: mysqlinstance
- validation:
- # This schema defines the configuration fields that the composite resource
- # supports. It uses the same structural OpenAPI schema as a Kubernetes CRD
- # - for example, this resource supports a spec.parameters.version enum.
- # The following fields are reserved for Crossplane's use, and will be
- # overwritten if included in this validation schema:
- #
- # - soec.resourceRef
- # - spec.resourceRefs
- # - spec.requirementRef
- # - spec.writeConnectionSecretToRef
- # - spec.reclaimPolicy
- # - status.conditions
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- parameters:
- type: object
- properties:
- version:
- description: MySQL engine version
- type: string
- enum: ["5.6", "5.7"]
- storageGB:
- type: integer
- location:
- description: Geographic location of this MySQL server.
- type: string
- required:
- - version
- - storageGB
- - location
- required:
- - parameters
-```
-
-Refer to the Kubernetes documentation on [structural schemas] for full details
-on how to configure the `openAPIV3Schema` for your composite resource.
-
-`kubectl describe` can be used to confirm that a new composite infrastructure
-resource was successfully defined. Note the `Established` condition and events,
-which indicate the process was successful.
-
-```console
-$ kubectl describe infrastructuredefinition mysqlinstances.example.org
-
-Name: mysqlinstances.example.org
-Namespace:
-Labels:
-Annotations: API Version: apiextensions.crossplane.io/v1alpha1
-Kind: InfrastructureDefinition
-Metadata:
- Creation Timestamp: 2020-05-15T05:30:44Z
- Finalizers:
- finalizer.apiextensions.crossplane.io
- published.apiextensions.crossplane.io
- Generation: 1
- Resource Version: 1418120
- Self Link: /apis/apiextensions.crossplane.io/v1alpha1/infrastructuredefinitions/mysqlinstances.example.org
- UID: f8fedfaf-4dfd-4b8a-8228-6af0f4abd7a0
-Spec:
- Connection Secret Keys:
- username
- password
- hostname
- port
- Default Composition Ref:
- Name: example-azure
- Crd Spec Template:
- Group: example.org
- Names:
- Kind: MySQLInstance
- List Kind: MySQLInstanceList
- Plural: mysqlinstances
- Singular: mysqlinstance
- Validation:
- openAPIV3Schema:
- Properties:
- Spec:
- Parameters:
- Properties:
- Location:
- Description: Geographic location of this MySQL server.
- Type: string
- Storage GB:
- Type: integer
- Version:
- Description: MySQL engine version
- Enum:
- 5.6
- 5.7
- Type: string
- Required:
- version
- storageGB
- location
- Type: object
- Required:
- parameters
- Type: object
- Type: object
- Version: v1alpha1
-Status:
- Conditions:
- Last Transition Time: 2020-05-15T05:30:45Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
- Last Transition Time: 2020-05-15T05:30:45Z
- Reason: Created CRD and started controller
- Status: True
- Type: Established
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal ApplyInfrastructureDefinition 4m10s apiextensions/infrastructuredefinition.apiextensions.crossplane.io waiting for CustomResourceDefinition to be established
- Normal RenderCustomResourceDefinition 55s (x8 over 4m10s) apiextensions/infrastructuredefinition.apiextensions.crossplane.io Rendered CustomResourceDefinition
- Normal ApplyInfrastructureDefinition 55s (x7 over 4m9s) apiextensions/infrastructuredefinition.apiextensions.crossplane.io Applied CustomResourceDefinition and (re)started composite controller
-```
-
-### Specify How Your Resource May Be Composed
-
-Once a new kind of infrastructure resource is defined Crossplane must be
-instructed how to reconcile that kind of infrastructure resource. This is done
-by authoring a `Composition`.
-
-A `Composition`:
-
-* Declares one kind of composite infrastructure resource that it satisfies.
-* Specifies a "base" configuration for one or more infrastructure resources.
-* Specifies "patches" that overlay configuration values from an instance of the
- composite infrastructure resource onto each "base".
-
-Multiple compositions may satisfy a particular kind of composite infrastructure
-resource, and the author of a composite resource (or resource requirement) may
-select which composition will be used. This allows an infrastructure operator to
-offer their application operators a choice between multiple opinionated classes
-of infrastructure, allowing them to explicitly specify only some configuration.
-An infrastructure operator may offer their application operators the choice
-between an "Azure" and a "GCP" composition when creating a `MySQLInstance` for
-example, Or they may offer a choice between a "production" and a "staging"
-`MySQLInstance` composition. They can also offer a default composition in case
-application operators do not supply a composition selector or enforce a specific
-composition in order to override the composition choice of users for all instances.
-In all cases, the application operator may configure any value supported by the
-composite infrastructure resource's schema, with all other values being deferred
-to the composition.
-
-> Note that per [Current Limitations] it is not currently possible to specify a
-> default or an enforced composition for a particular kind of infrastructure
-> resource, but these options will be added in a future release of Crossplane.
-> In the meantime composite resource and/or resource requirement authors must
-> specify a composition for their resource to use.
-
-The below `Composition` satisfies the `MySQLInstance` defined in the previous
-section by composing an Azure SQL server, firewall rule, and resource group:
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: Composition
-metadata:
- name: example-azure
- labels:
- purpose: example
- provider: azure
-spec:
- # This Composition declares that it satisfies the MySQLInstance composite
- # resource defined above - i.e. it patches "from" a MySQLInstance.
- from:
- apiVersion: example.org/v1alpha1
- kind: MySQLInstance
- # This Composition reconciles an instance of a MySQLInstance by patching from
- # the MySQLInstance "to" new instances of the infrastructure resources below.
- # These resources may be the managed resources of an infrastructure provider
- # such as provider-azure, or other composite infrastructure resources.
- to:
- # A MySQLInstance that uses this Composition will be composed of an Azure
- # ResourceGroup. The "base" for this ResourceGroup specifies the base
- # configuration that may be extended or mutated by the patches below.
- - base:
- apiVersion: azure.crossplane.io/v1alpha3
- kind: ResourceGroup
- spec:
- reclaimPolicy: Delete
- providerRef:
- name: example
- # Patches copy or "overlay" the value of a field path within the composite
- # resource (the MySQLInstance) to a field path within the composed resource
- # (the ResourceGroup). In the below example any labels and annotations will
- # be propagated from the MySQLInstance to the ResourceGroup, as will the
- # location.
- patches:
- - fromFieldPath: "metadata.labels"
- toFieldPath: "metadata.labels"
- - fromFieldPath: "metadata.annotations"
- toFieldPath: "metadata.annotations"
- - fromFieldPath: "spec.parameters.location"
- toFieldPath: "spec.location"
- # Sometimes it is necessary to "transform" the value from the composite
- # resource into a value suitable for the composed resource, for example an
- # Azure based composition may represent geographical locations differently
- # from a GCP based composition that satisfies the same composite resource.
- # This can be done by providing an optional array of transforms, such as
- # the below that will transform the MySQLInstance spec.parameters.location
- # value "us-west" into the ResourceGroup spec.location value "West US".
- transforms:
- - type: map
- map:
- us-west: West US
- us-east: East US
- au-east: Australia East
- # A MySQLInstance that uses this Composition will also be composed of an
- # Azure MySQLServer.
- - base:
- apiVersion: database.azure.crossplane.io/v1beta1
- kind: MySQLServer
- spec:
- forProvider:
- # When this MySQLServer is created it must specify a ResourceGroup in
- # which it will exist. The below resourceGroupNameSelector corresponds
- # to the spec.forProvider.resourceGroupName field of the MySQLServer.
- # It selects a ResourceGroup with a matching controller reference.
- # Two resources that are part of the same composite resource will have
- # matching controller references, so this MySQLServer will always
- # select the ResourceGroup above. If this Composition included more
- # than one ResourceGroup they could be differentiated by matchLabels.
- resourceGroupNameSelector:
- matchControllerRef: true
- administratorLogin: notadmin
- sslEnforcement: Disabled
- sku:
- tier: GeneralPurpose
- capacity: 8
- family: Gen5
- storageProfile:
- backupRetentionDays: 7
- geoRedundantBackup: Disabled
- providerRef:
- name: example
- writeConnectionSecretToRef:
- namespace: crossplane-system
- reclaimPolicy: Delete
- patches:
- - fromFieldPath: "metadata.labels"
- toFieldPath: "metadata.labels"
- - fromFieldPath: "metadata.annotations"
- toFieldPath: "metadata.annotations"
- - fromFieldPath: "metadata.uid"
- toFieldPath: "spec.writeConnectionSecretToRef.name"
- transforms:
- # Transform the value from the MySQLInstance using Go string formatting.
- # This can be used to prefix or suffix a string, or to convert a number
- # to a string. See https://golang.org/pkg/fmt/ for more detail.
- - type: string
- string:
- fmt: "%s-mysqlserver"
- - fromFieldPath: "spec.parameters.version"
- toFieldPath: "spec.forProvider.version"
- - fromFieldPath: "spec.parameters.location"
- toFieldPath: "spec.forProvider.location"
- transforms:
- - type: map
- map:
- us-west: West US
- us-east: East US
- au-east: Australia East
- - fromFieldPath: "spec.parameters.storageGB"
- toFieldPath: "spec.forProvider.storageProfile.storageMB"
- # Transform the value from the MySQLInstance by multiplying it by 1024 to
- # convert Gigabytes to Megabytes.
- transforms:
- - type: math
- math:
- multiply: 1024
- # In addition to a base and patches, this composed MySQLServer declares that
- # it can fulfil the connectionSecretKeys contract required by the definition
- # of the MySQLInstance. This MySQLServer writes a connection secret with a
- # username, password, and endpoint that may be used to connect to it. These
- # connection details will also be exposed via the composite resource's
- # connection secret. Exactly one composed resource must provide each secret
- # key, but different composed resources may provide different keys.
- connectionDetails:
- - fromConnectionSecretKey: username
- - fromConnectionSecretKey: password
- # The name of the required MySQLInstance connection secret key can be
- # supplied if it is different from the connection secret key exposed by
- # the MySQLServer.
- - name: hostname
- fromConnectionSecretKey: endpoint
- # In some cases it may be desirable to inject a fixed connection secret
- # value, for example to expose fixed, non-sensitive connection details
- # like standard ports that are not published to the composed resource's
- # connection secret.
- - name: port
- value: "3306"
- # A MySQLInstance that uses this Composition will also be composed of an
- # Azure MySQLServerFirewallRule.
- - base:
- apiVersion: database.azure.crossplane.io/v1alpha3
- kind: MySQLServerFirewallRule
- spec:
- forProvider:
- resourceGroupNameSelector:
- matchControllerRef: true
- serverNameSelector:
- matchControllerRef: true
- properties:
- startIpAddress: 10.10.0.0
- endIpAddress: 10.10.255.254
- virtualNetworkSubnetIdSelector:
- name: sample-subnet
- providerRef:
- name: example
- reclaimPolicy: Delete
- patches:
- - fromFieldPath: "metadata.labels"
- toFieldPath: "metadata.labels"
- - fromFieldPath: "metadata.annotations"
- toFieldPath: "metadata.annotations"
- # Some composite resources may be "dynamically provisioned" - i.e. provisioned
- # on-demand to satisfy an application's requirement for infrastructure. The
- # writeConnectionSecretsToNamespace and reclaimPolicy fields configure default
- # values used when dynamically provisioning a composite resource; they are
- # explained in more detail below.
- writeConnectionSecretsToNamespace: crossplane-system
- reclaimPolicy: Delete
-```
-
-Field paths reference a field within a Kubernetes object via a simple string.
-API conventions describe the syntax as "standard JavaScript syntax for accessing
-that field, assuming the JSON object was transformed into a JavaScript object,
-without the leading dot, such as metadata.name". Array indices are specified via
-square braces while object fields may be specified via a period or via square
-braces.Kubernetes field paths do not support advanced features of JSON paths,
-such as `@`, `$`, or `*`. For example given the below `Pod`:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: example-pod
- annotations:
- example.org/a: example-annotation
-spec:
- containers:
- - name: example-container
- image: example:latest
- command: [example]
- args: ["--debug", "--example"]
-```
-
-* `metadata.name` would contain "example-pod"
-* `metadata.annotations['example.org/a']` would contain "example-annotation"
-* `spec.containers[0].name` would contain "example-container"
-* `spec.containers[0].args[1]` would contain "--example"
-
-> Note that Compositions provide _intentionally_ limited functionality when
-> compared to powerful templating and composition tools like Helm or Kustomize.
-> This allows a Composition to be a schemafied Kubernetes-native resource that
-> can be stored in and validated by the Kubernetes API server at authoring time
-> rather than invocation time.
-
-### Publish Your Infrastructure Resource
-
-An infrastructure operator may choose to publish any defined kind of composite
-infrastructure resource to their application operators. Doing so is optional -
-a kind of resource that is defined but not published may still be created at the
-cluster scope, but application operators may not create a namespaced requirement
-for that kind of resource.
-
-Infrastructure is published by an `InfrastructurePublication`:
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: InfrastructurePublication
-metadata:
- # InfrastructurePublications must use the same name as the
- # InfrastructureDefinition that defines the resource they publish.
- name: mysqlinstances.example.org
-spec:
- infrastructureDefinitionRef:
- name: mysqlinstances.example.org
-```
-
-`kubectl describe` can be used to confirm that a composite infrastructure
-resource was successfully published. Note the `Established` condition and
-events, which indicate the process was successful.
-
-```console
-$ kubectl describe infrastructurepublication mysqlinstances.example.org
-
-Name: mysqlinstances.example.org
-Namespace:
-Labels:
-Annotations: API Version: apiextensions.crossplane.io/v1alpha1
-Kind: InfrastructurePublication
-Metadata:
- Creation Timestamp: 2020-05-15T05:30:44Z
- Finalizers:
- published.apiextensions.crossplane.io
- Generation: 1
- Resource Version: 1418122
- Self Link: /apis/apiextensions.crossplane.io/v1alpha1/infrastructurepublications/mysqlinstances.example.org
- UID: 534c5151-2adc-4b4b-9248-fa30740e6b32
-Spec:
- Infrastructure Definition Ref:
- Name: mysqlinstances.example.or
-Status:
- Conditions:
- Last Transition Time: 2020-05-15T05:30:46Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
- Last Transition Time: 2020-05-15T05:30:46Z
- Reason: Created CRD and started controller
- Status: True
- Type: Established
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal ApplyInfrastructurePublication 7m35s apiextensions/infrastructurepublication.apiextensions.crossplane.io waiting for CustomResourceDefinition to be established
- Normal GetInfrastructureDefinition 7m32s (x7 over 7m36s) apiextensions/infrastructurepublication.apiextensions.crossplane.io Got published InfrastructureDefinition
- Normal RenderCustomResourceDefinition 7m32s (x7 over 7m36s) apiextensions/infrastructurepublication.apiextensions.crossplane.io Rendered CustomResourceDefinition
- Normal ApplyInfrastructurePublication 7m32s (x5 over 7m34s) apiextensions/infrastructurepublication.apiextensions.crossplane.io Applied CustomResourceDefinition and (re)started requirement controller
-```
-
-### Permit Crossplane to Reconcile Your Infrastructure Resource
-
-Typically Crossplane runs using a service account that does not have access to
-reconcile arbitrary kinds of resource. A `ClusterRole` can grant Crossplane
-permission to reconcile your newly defined and published resource:
-
-```yaml
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: mysqlinstances.example.org
- labels:
- rbac.crossplane.io/aggregate-to-crossplane: "true"
-rules:
-- apiGroups:
- - example.org
- resources:
- - mysqlinstances
- - mysqlinstances/status
- - mysqlinstancerequirements
- - mysqlinstancerequirements/status
- verbs:
- - "*"
-```
-
-## Using Infrastructure
-
-![Infrastructure Composition Provisioning]
-
-Crossplane offers several ways for both infrastructure operators and application
-operators to use the composite infrastructure they've defined and published:
-
-1. Only infrastructure operators can create or manage infrastructure of a kind
- that is not published to application operators.
-1. Infrastructure operators can create infrastructure of a published kind. This
- allows an application operator to create a requirement that specifically
- requires the resource the infrastructure operator created.
-1. Application operators can create a requirement for infrastructure of a kind
- that has been published, and it will be provisioned on-demand.
-
-Options one and two are frequently referred to as "static provisioning", while
-option three is known as "dynamic provisioning".
-
-> Note that infrastructure operator focused Crossplane concepts are cluster
-> scoped - they exist outside any namespace. Crossplane assumes infrastructure
-> operators will have similar RBAC permissions to cluster administrators, and
-> will thus be permitted to manage cluster scoped resources. Application
-> operator focused Crossplane concepts are namespaced. Crossplane assumes
-> application operators will be permitted access to the namespace(s) in which
-> their applications run, and not to cluster scoped resources.
-
-### Creating and Managing Composite Infrastructure
-
-An infrastructure operator may wish to author a composite resource of a kind
-that is published - i.e. a resource kind that has an `InfrastructurePublication`
-as well as an `InfrastructureDefinition` - so that an application operator may
-later author a requirement for that exact resource. This pattern is useful for
-infrastructure resources that may take several minutes to provision - the
-infrastructure operator can keep a pool of resources available in advance in
-order to ensure application requirements may be instantly satisfied.
-
-In some cases an infrastructure operator may wish to use Crossplane to model
-composite infrastructure that they do not wish to allow application operators to
-provision. Consider a `VPCNetwork` composite resource that creates an AWS VPC
-network with an internet gateway, route table, and several subnets. Defining
-this resource as a composite allows the infrastructure operator to easily reuse
-their configuration, but it does not make sense in their organisation to allow
-application operators to create "supporting infrastructure" like a VPC network.
-
-In both of the above scenarios the infrastructure operator may statically
-provision a composite resource; i.e. author it directly rather than via its
-corresponding requirement. The `MySQLInstance` composite infrastructure resource
-defined above could be authored as follows:
-
-```yaml
-apiVersion: example.org/v1alpha1
-kind: MySQLInstance
-metadata:
- # Composite resources are cluster scoped, so there's no need for a namespace.
- name: example
-spec:
- # The schema of the spec.parameters object is defined by the earlier example
- # of an InfrastructureDefinition. The location, storageGB, and version fields
- # are patched onto the ResourceGroup, MySQLServer, and MySQLServerFirewallRule
- # that this MySQLInstance composes.
- parameters:
- location: au-east
- storageGB: 20
- version: "5.7"
- # Support for a compositionRef is automatically injected into the schema of
- # all defined composite infrastructure resources. This allows the resource
- # author to explicitly reference a Composition that this composite resource
- # should use - in this case the earlier example-azure Composition. Note that
- # it is also possible to select a composition by labels - see the below
- # MySQLInstanceRequirement for an example of this approach.
- compositionRef:
- name: example-azure
- # Support for a writeConnectionSecretToRef is automatically injected into the
- # schema of all defined composite infrastructure resources. This allows the
- # resource to write a connection secret containing any details required to
- # connect to it - in this case the hostname, username, and password. Composite
- # resource authors may omit this reference if they do not need or wish to
- # write these details.
- writeConnectionSecretToRef:
- namespace: infra-secrets
- name: example-mysqlinstance
- # Support for a reclaimPolicy is automatically injected into the schema of all
- # defined composite infrastructure resources. The reclaim policy applies only
- # to published kinds of infrastructure - it controls whether the resource is
- # deleted or retained when its corresponding Requirement is deleted. If an
- # application authored a MySQLInstanceRequirement for this MySQLInstance then
- # later deleted their MySQLInstanceRequirement this MySQLInstance and all of
- # the resources it composes would be deleted. If the policy were instead set
- # to 'Retain' the MySQLInstance would be retained, for example to allow an
- # infrastructure operator to perform manual cleanup.
- reclaimPolicy: Delete
-```
-
-Any updates to the `MySQLInstance` composite infrastructure resource will be
-immediately reconciled with the resources it composes. For example if more
-storage were needed an update to the `spec.parameters.storageGB` field would
-immediately be propagated to the `spec.forProvider.storageProfile.storageMB`
-field of the composed `MySQLServer` due to the relationship established between
-these two fields by the patches configured in the `example-azure` `Composition`.
-
-`kubectl describe` may be used to examine a composite infrastructure resource.
-Note the `Synced` and `Ready` conditions below. The former indicates that
-Crossplane is successfully reconciling the composite resource by updating the
-composed resources. The latter indicates that all composed resources are also
-indicating that they are in condition `Ready`, and therefore the composite
-resource should be online and ready to use. More detail about the health and
-configuration of the composite resource can be determined by describing each
-composite resource. The kinds and names of each composed resource are exposed as
-"Resource Refs" - for example `kubectl describe mysqlserver example-zrpgr` will
-describe the detailed state of the composed Azure `MySQLServer`.
-
-```console
-$ kubectl describe mysqlinstance.example.org
-
-Name: example
-Namespace:
-Labels:
-Annotations: API Version: example.org/v1alpha1
-Kind: MySQLInstance
-Metadata:
- Creation Timestamp: 2020-05-15T06:53:16Z
- Generation: 4
- Resource Version: 1425809
- Self Link: /apis/example.org/v1alpha1/mysqlinstances/example
- UID: f654dd52-fe0e-47c8-aa9b-235c77505674
-Spec:
- Composition Ref:
- Name: example-azure
- Parameters:
- Location: au-east
- Storage GB: 20
- Version: 5.7
- Reclaim Policy: Delete
- Resource Refs:
- API Version: azure.crossplane.io/v1alpha3
- Kind: ResourceGroup
- Name: example-wspmk
- UID: 4909ab46-95ef-4ba7-8f7a-e1d9ee1a6b23
- API Version: database.azure.crossplane.io/v1beta1
- Kind: MySQLServer
- Name: example-zrpgr
- UID: 3afb903e-32db-4834-a6e7-31249212dca0
- API Version: database.azure.crossplane.io/v1alpha3
- Kind: MySQLServerFirewallRule
- Name: example-h4zjn
- UID: 602c8412-7c33-4338-a3af-78166c17b1a0
- Write Connection Secret To Ref:
- Name: example-mysqlinstance
- Namespace: infra-secrets
-Status:
- Conditions:
- Last Transition Time: 2020-05-15T06:56:46Z
- Reason: Resource is available for use
- Status: True
- Type: Ready
- Last Transition Time: 2020-05-15T06:53:16Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal SelectComposition 10s (x7 over 3m40s) composite/mysqlinstances.example.org Successfully selected composition
- Normal PublishConnectionSecret 10s (x7 over 3m40s) composite/mysqlinstances.example.org Successfully published connection details
- Normal ComposeResources 10s (x7 over 3m40s) composite/mysqlinstances.example.org Successfully composed resources
-```
-
-### Creating an Infrastructure Requirement
-
-Infrastructure requirements represent an application's requirement for a defined
-kind of infrastructure, for example the above `MySQLInstance`. Requirements are
-a proxy for the kind of resource they require, allowing application operators to
-provision and consume infrastructure. An infrastructure requirement may require
-pre-existing, statically provisioned infrastructure or it may dynamically
-provision infrastructure on-demand. A requirement for a defined kind of
-composite infrastructure resource is always suffixed with `Requirement`. A
-requirement for a composite infrastructure resource of kind `MySQLInstance` is,
-for example, of kind `MySQLInstanceRequirement`.
-
-The below requirement explicitly requires the `MySQLInstance` authored in the
-previous example:
-
-```yaml
-# The MySQLInstanceRequirement always has the same API group and version as the
-# resource it requires. Its kind is always suffixed with Requirement.
-apiVersion: example.org/v1alpha1
-kind: MySQLInstanceRequirement
-metadata:
- # Infrastructure requirements are namespaced.
- namespace: default
- name: example
-spec:
- # The schema of the spec.parameters object is defined by the earlier example
- # of an InfrastructureDefinition. The location, storageGB, and version fields
- # are patched onto the ResourceGroup, MySQLServer, and MySQLServerFirewallRule
- # composed by the required MySQLInstance.
- parameters:
- location: au-east
- storageGB: 20
- version: "5.7"
- # Support for a resourceRef is automatically injected into the schema of all
- # published infrastructure requirement resources. The resourceRef specifies
- # the explicit MySQLInstance that is required.
- resourceRef:
- name: example
- # Support for a writeConnectionSecretToRef is automatically injected into the
- # schema of all published infrastructure requirement resources. This allows
- # the resource to write a connection secret containing any details required to
- # connect to it - in this case the hostname, username, and password.
- writeConnectionSecretToRef:
- name: example-mysqlinstance
-```
-
-A requirement may omit the `resourceRef` and instead include a `compositionRef`
-(as in the previous `MySQLInstance` example) or a `compositionSelector` in order
-to trigger dynamic provisioning. A requirement that does not include a reference
-to an existing composite infrastructure resource will have a suitable composite
-resource provisioned on demand:
-
-```yaml
-apiVersion: example.org/v1alpha1
-kind: MySQLInstanceRequirement
-metadata:
- namespace: default
- name: example
-spec:
- parameters:
- location: au-east
- storageGB: 20
- version: "5.7"
- # Support for a compositionSelector is automatically injected into the schema
- # of all published infrastructure requirement resources. This selector selects
- # the example-azure composition by its labels.
- compositionSelector:
- matchLabels:
- purpose: example
- provider: azure
- writeConnectionSecretToRef:
- name: example-mysqlinstance
-```
-
-> Note that compositionSelector labels can form a shared language between the
-> infrastructure operators who define compositions and the application operators
-> who require composite resources. Compositions could be labelled by zone, size,
-> or purpose in order to allow application operators to request a class of
-> composite resource by describing their needs such as "east coast, production".
-
-Like composite resources, requirements can be examined using `kubectl describe`.
-The `Synced` and `Ready` conditions have the same meaning as the `MySQLInstance`
-above. The "Resource Ref" indicates the name of the composite resource that was
-either explicitly required, or in the case of the below requirement dynamically
-provisioned.
-
-```console
-$ kubectl describe mysqlinstancerequirement.example.org example
-
-Name: example
-Namespace: default
-Labels:
-Annotations: API Version: example.org/v1alpha1
-Kind: MySQLInstanceRequirement
-Metadata:
- Creation Timestamp: 2020-05-15T07:08:11Z
- Finalizers:
- finalizer.apiextensions.crossplane.io
- Generation: 3
- Resource Version: 1428420
- Self Link: /apis/example.org/v1alpha1/namespaces/default/mysqlinstancerequirements/example
- UID: d87e9580-9d2e-41a7-a198-a39851815840
-Spec:
- Composition Selector:
- Match Labels:
- Provider: azure
- Purpose: example
- Parameters:
- Location: au-east
- Storage GB: 20
- Version: 5.7
- Resource Ref:
- Name: default-example-8t4tb
- Write Connection Secret To Ref:
- Name: example-mysqlinstance
-Status:
- Conditions:
- Last Transition Time: 2020-05-15T07:26:49Z
- Reason: Resource is available for use
- Status: True
- Type: Ready
- Last Transition Time: 2020-05-15T07:08:11Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal ConfigureCompositeResource 8m23s requirement/mysqlinstances.example.org Successfully configured composite resource
- Normal BindCompositeResource 8m23s (x7 over 8m23s) requirement/mysqlinstances.example.org Composite resource is not yet ready
- Normal BindCompositeResource 4m53s (x4 over 23m) requirement/mysqlinstances.example.org Successfully bound composite resource
- Normal PropagateConnectionSecret 4m53s (x4 over 23m) requirement/mysqlinstances.example.org Successfully propagated connection details from composite resource
-```
-
-## Current Limitations
-
-Defining and publishing composite infrastructure resources is an experimental
-feature of Crossplane. At present the below functionality is planned but not yet
-implemented:
-
-* Updates to a composite infrastructure resource are immediately applied to the
- resources it composes, but updates to a requirement are not yet applied to the
- composite resource that was allocated to satisfy the requirement. In a future
- release of Crossplane updating a requirement will update its allocated
- composite infrastructure resource.
-* A composite infrastructure resource (or dynamically provisioned requirement)
- must specify a composition reference or selector. In a future Crossplane
- release it will be possible to configure a default composition for resources
- that provide no information about what composition they desire, and to
- configure a single composition that will be enforced for all resources.
-* Only three transforms are currently supported - string format, multiplication,
- and map. Crossplane intends to limit the set of supported transforms, and will
- add more as clear use cases appear.
-* Compositions are mutable, and updating a composition causes all composite
- resources that use that composition to be updated accordingly. A future
- release of Crossplane may alter this behaviour.
-* Composite resources that are retained when the requirement they were allocated
- to is deleted become available for allocation to another requirement. This may
- not be the desired behaviour, for example if the application that previously
- required the composite infrastructure resource wrote sensitive data to it. A
- future release of Crossplane may alter the reclaim policy options.
-
-[Current Limitations]: #current-limitations
-[Infrastructure Composition Concepts]: composition-concepts.png
-[structural schemas]: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#specifying-a-structural-schema
-[Infrastructure Composition Provisioning]: composition-provisioning.png
diff --git a/docs/v0.12/introduction/crossplane-concepts.png b/docs/v0.12/introduction/crossplane-concepts.png
deleted file mode 100644
index 436d65cd..00000000
Binary files a/docs/v0.12/introduction/crossplane-concepts.png and /dev/null differ
diff --git a/docs/v0.12/introduction/managed-resources.md b/docs/v0.12/introduction/managed-resources.md
deleted file mode 100644
index 2cd3a21c..00000000
--- a/docs/v0.12/introduction/managed-resources.md
+++ /dev/null
@@ -1,261 +0,0 @@
----
-title: Managed Resources
-toc: true
-weight: 102
-indent: true
----
-
-# Managed Resources
-
-## Overview
-
-Managed resources are the Crossplane representation of the cloud [provider][provider]
-resources and they are considered primitive low level custom resources that can
-be used directly to provision external cloud resources for an application or as
-part of an infrastructure composition.
-
-For example, `RDSInstance` in AWS Provider corresponds to an actual RDS Instance
-in AWS. There is a one-to-one relationship and the changes on managed resources are
-reflected directly on the corresponding resource in the provider.
-
-You can browse [API Reference][api-reference] to discover all available managed resources.
-
-## Syntax
-
-Crossplane API conventions extend the Kubernetes API conventions for the schema
-of Crossplane managed resources. Following is an example of `RDSInstance`:
-
-```yaml
-apiVersion: database.aws.crossplane.io/v1beta1
-kind: RDSInstance
-metadata:
- name: foodb
-spec:
- forProvider:
- dbInstanceClass: db.t2.small
- masterUsername: root
- allocatedStorage: 20
- engine: mysql
- writeConnectionSecretToRef:
- name: mysql-secret
- namespace: crossplane-system
- providerRef:
- name: mycreds
- reclaimPolicy: Delete
-```
-
-In Kubernetes, `spec` top field represents the desired state of the user.
-Crossplane adheres to that and has its own conventions about how the fields under
-`spec` should look like.
-
-* `writeConnectionSecretToRef`: A reference to the secret that you want this
- managed resource to write its connection secret that you'd be able to mount
- to your pods in the same namespace. For `RDSInstance`, this secret would contain
- `endpoint`, `username` and `password`.
-
-* `providerRef`: Reference to the `Provider` resource that will provide information
- regarding authentication of Crossplane to the provider. `Provider` resources
- refer to `Secret` and potentially contain other information regarding authentication.
-
-* `reclaimPolicy`: Enum to specify whether the actual cloud resource should be
- deleted when this managed resource is deleted in Kubernetes API server. Possible
- values are `Delete` and `Retain`.
-
-* `forProvider`: While the rest of the fields relate to how Crossplane should
- behave, the fields under `forProvider` are solely used to configure the actual
- external resource. In most of the cases, the field names correspond to the what
- exists in provider's API Reference.
-
- The objects under `forProvider` field can get huge depending on the provider
- API. For example, GCP `ServiceAccount` has only a few fields while GCP `CloudSQLInstance`
- has over 100 fields that you can configure.
-
-### Versioning
-
-Crossplane closely follows the [Kubernetes API versioning conventions][api-versioning]
-for the CRDs that it deploys. In short, for `vXbeta` and `vX` versions, you can
-expect that either automatic migration or instructions for manual migration will
-be provided when a new version of that CRD schema is released.
-
-### Grouping
-
-In general, managed resources are high fidelity resources meaning they will provide
-parameters and behaviors that are provided by the external resource API. This applies
-to grouping of resources, too. For example, `RDSInstance` appears under `database`
-API group, so, its `APIVersion` and `Kind` look like the following:
-
-```yaml
-apiVersion: database.aws.crossplane.io/v1beta1
-kind: RDSInstance
-```
-
-## Behavior
-
-As a general rule, managed resource controllers try not to make any decision
-that is not specified by the user in the desired state since managed resources
-are the lowest level primitives that operate directly on the cloud provider APIs.
-
-### Continuous Reconciliation
-
-Crossplane providers continuously reconcile the managed resource to achieve the
-desired state. The parameters under `spec` are considered the one and only source
-of truth for the external resource. This means that if someone changed a
-configuration in the UI of the provider, like AWS Console, Crossplane will change
-it back to what's given under `spec`.
-
-#### Immutable Properties
-
-There are configuration parameters in external resources that cloud providers do not
-allow to be changed. If the corresponding field in the managed resource is changed
-by the user, Crossplane submits the new desired state to the provider and returns
-the error, if any. For example, in AWS, you cannot change the region of
-an `RDSInstance`.
-
-Some infrastructure tools such as Terraform delete and recreate the resource
-to accommodate those changes but Crossplane does not take that route. Unless
-the managed resource is deleted and its `reclaimPolicy` is `Delete`, its controller
-never deletes the external resource in the provider.
-
-> Immutable fields are marked as `immutable` in Crossplane codebase
-but Kubernetes does not yet have immutable field notation in CRDs.
-
-### External Name
-
-By default the name of the managed resource is used as the name of the external
-cloud resource that will show up in your cloud console.
-To specify a different external name, Crossplane has a special annotation to
-represent the name of the external resource. For example, I would like to
-have a `CloudSQLInstance` with an external name that is different than its
-managed resource name:
-
-```yaml
-apiVersion: database.gcp.crossplane.io/v1beta1
-kind: CloudSQLInstance
-metadata:
- name: foodb
- annotations:
- crossplane.io/external-name: my-special-db
-spec:
- ...
-```
-
-When you create this managed resource, you will see that the name of `CloudSQLInstance`
-in GCP console will be `my-special-db`.
-
-If the annotation is not given, Crossplane will fill it with the name of the managed
-resource by default. In cases where provider doesn't allow you to name the resource,
-like AWS VPC, the controller creates the resource and sets external annotation
-to be the name that the cloud provider chose. So, you would see something like
-`vpc-28dsnh3` as the value of `crossplane.io/external-name` annotation of your
-AWS `VPC` resource even if you added your own custom external name during creation.
-
-### Late Initialization
-
-For some of the optional fields, users rely on the default that the cloud provider
-chooses for them. Since Crossplane treats the managed resource as the source of
-the truth, values of those fields need to exist in `spec` of the managed resource.
-So, in each reconciliation, Crossplane will fill the value of a field that is
-left empty by the user but is assigned a value by the provider. For example,
-there could be two fields like `region` and `availabilityZone` and you might want
-to give only `region` and leave the availability zone to be chosen by the cloud
-provider. In that case, if the provider assigns an availability zone, Crossplane
-gets that value and fills `availabilityZone`. Note that if the field is already
-filled, the controller won't override its value.
-
-### Deletion
-
-When a deletion request is made for a managed resource, its controller starts the
-deletion process immediately. However, the managed resource is kept in the Kubernetes
-API (via a finalizer) until the controller confirms the external resource in the
-cloud is gone. So you can be sure that if the managed resource is deleted, then
-the external cloud resource is also deleted. Any errors that happen during
-deletion will be added to the `status` of the managed resource, so you can
-troubleshoot any issues.
-
-## Dependencies
-
-In many cases, an external resource refers to another one for a specific configuration.
-For example, you could want your Azure Kubernetes cluster in a specific
-Virtual Network. External resources have specific fields for these relations, however,
-they usually require the information to be supplied in different formats. In Azure
-MySQL, you might be required to enter only the name of the Virtual Network while in
-Azure Kubernetes, it could be required to enter a string in a specific format
-that includes other information such as resource group name.
-
-In Crossplane, users have 3 fields to refer to another resource. Here is an example
-from Azure MySQL managed resource referring to a Azure Resource Group:
-
-```yaml
-spec:
- forProvider:
- resourceGroupName: foo-res-group
- resourceGroupNameRef:
- name: resourcegroup
- resourceGroupNameSelector:
- matchLabels:
- app: prod
-```
-
-In this example, the user provided only a set of labels to select a `ResourceGroup`
-managed resource that already exists in the cluster via `resourceGroupNameSelector`.
-Then after a specific `ResourceGroup` is selected, `resourceGroupNameRef` is filled
-with the name of that `ResourceGroup` managed resource. Then in the last step,
-Crossplane fills the actual `resourceGroupName` field with whatever format Azure
-accepts it. Once a dependency is resolved, the controller never changes it.
-
-Users are able to specify any of these three fields:
- - Selector to select via labels
- - Reference to point to a determined managed resource
- - Actual value that will be submitted to the provider
-
-It's important to note that in case a reference exists, the managed resource does
-not create the external resource until the referenced object is ready. In this
-example, creation call of Azure MySQL Server will not be made until referenced
-`ResourceGroup` has its `status.condition` named `Ready` to be true.
-
-## Importing Existing Resources
-
-If you have some resources that are already provisioned in the cloud provider,
-you can import them as managed resources and let Crossplane manage them. What you
-need to do is to enter the name of the external resource as well as the required
-fields on the managed resource. For example, let's say I have a GCP Network
-provisioned from GCP console and I would like to migrate it to Crossplane. Here
-is the YAML that I need to create:
-
-```yaml
-apiVersion: compute.gcp.crossplane.io/v1beta1
-kind: Network
-metadata:
- name: foo-network
- annotation:
- crossplane.io/external-name: existing-network
-spec:
- providerRef:
- name: gcp-creds
-```
-
-Crossplane will check whether a GCP Network called `existing-network` exists, and
-if it does, then the optional fields under `forProvider` will be filled with the
-values that are fetched from the provider.
-
-Note that if a resource has required fields, you must fill those fields or the
-creation of the managed resource will be rejected. So, in those cases, you will
-need to enter the name of the resource as well as the required fields as indicated
-in the [API Reference][api-reference] documentation.
-
-## Backup and Restore
-
-Crossplane adheres to Kubernetes conventions as much as possible and one of the
-advantages we gain is backup & restore ability with tools that work with native
-Kubernetes types, like [Verero][velero].
-
-If you'd like to backup and restore manually, you can simply export them and save
-YAMLs in your file system. When you reload them, as we've discovered in import
-section, their `crosssplane.io/external-name` annotation and required fields are
-there and those are enough to import a resource. The tool you're using needs to
-store `annotations` and `spec` fields, which most tools do including Velero.
-
-[api-versioning]: https://kubernetes.io/docs/reference/using-api/api-overview/#api-versioning
-[velero]: https://velero.io/
-[api-reference]: api-docs/overview.md
-[provider]: provider.md
\ No newline at end of file
diff --git a/docs/v0.12/introduction/overview.md b/docs/v0.12/introduction/overview.md
deleted file mode 100644
index cfcf500a..00000000
--- a/docs/v0.12/introduction/overview.md
+++ /dev/null
@@ -1,133 +0,0 @@
----
-title: Introduction
-toc: true
-weight: 100
----
-
-# Overview
-
-Crossplane introduces multiple building blocks that enable you to provision,
-publish, and consume infrastructure using the Kubernetes API. These individual
-concepts work together to allow for powerful separation of concern between
-different personas in an organization, meaning that each member of a team
-interacts with Crossplane at an appropriate level of abstraction.
-
-![Crossplane Concepts]
-
-The diagram above illustrates a common workflow using most of Crossplane's
-functionality.
-
-An infrastructure operator...
-1. Installs Crossplane and one or more [providers] (in this case
- [provider-azure]) as [packages]. This enables provisioning of external
- infrastructure from the Kubernetes cluster.
-2. Creates an `InfrastructureDefinition` to define a new type of resource (in
- this case a `MySQLInstance`). Crossplane creates a cluster-scoped CRD of kind
- `MySQLInstance` in response.
-3. Creates an `InfrastructurePublication` to make provisioning a `MySQLInstance`
- possible at the namespace scope. Crossplane creates a namespace-scoped CRD of
- kind `MySQLInstanceRequirement` in response.
-4. Creates a `Composition` that instructs Crossplane how to render one or more
- infrastructure primitives installed by providers in response to the creation
- of a `MySQLInstance` or `MySQLInstanceRequirement`. In this case the
- `Composition` specifies that Azure `MySQLServer` and `MySQLFirewallRule`
- [managed resources] should be created.
-
-An application developer...
-1. Creates an [OAM] `Component` for their service that specifies that they wish
- to be run as an OAM `ContainerizedWorkload`.
-2. Creates an OAM `Component` for their MySQL database that can be satisfied by
- the published `MySQLInstanceRequirement` type.
-
-An application operator...
-1. Creates an OAM `ApplicationConfiguration`, which is comprised of the two
- `Component` types that were defined by the application developer, and a
- `ManualScalerTrait` trait to modify the replicas in the
- `ContainerizedWorkload`. In response, Crossplane translates the OAM types
- into Kubernetes-native types, in this case a `Deployment` and `Service` for
- the `ContainerizedWorkload` component, and a `MySQLServer` and
- `MySQLFirewallRule` for the `MySQLInstanceRequirement` component.
-2. Crossplane provisions the external infrastructure and makes the connection
- information available to the application, allowing it to connect to and
- consume the MySQL database on Azure.
-
-The concepts used in this workflow are explained in greater detail below and in
-their individual documentation.
-
-## Packages
-
-Packages allow Crossplane to be extended to include new functionality. This
-typically looks like bundling a set of Kubernetes [CRDs] and [controllers] that
-represent and manage external infrastructure (i.e. a provider), then installing
-them into a cluster where Crossplane is running. Crossplane handles making sure
-any new CRDs do not conflict with existing ones, as well as manages the RBAC and
-security of new packages. Packages are not strictly required to be providers,
-but it is the most common use-case for packages at this time.
-
-## Providers
-
-Providers are packages that enable Crossplane to provision infrastructure on an
-external service. They bring CRDs (i.e. managed resources) that map one-to-one
-to external infrastructure resources, as well as controllers to manage the
-life-cycle of those resources. You can read more about providers, including how
-to install and configure them, in the [providers documentation].
-
-## Managed Resources
-
-Managed resources are Kubernetes custom resources that represent infrastructure
-primitives. Managed resources with an API version of `v1beta1` or higher support
-every field that the cloud provider does for the given resource. You can find
-the Managed Resources and their API specifications for each provider on
-[doc.crds.dev] and learn more in the [managed resource documentation].
-
-## Composition
-
-Composition refers the machinery that allows you to bundle managed resources
-into higher-level infrastructure units, using only the Kubernetes API. New
-infrastructure units are defined using the `InfrastructureDefinition`,
-`InfrastructurePublication`, and `Composition` types, which result in the
-creation of new CRDs in a cluster. Creating instances of these new CRDs result
-in the creation of one or more managed resources. You can learn more about all
-of these concepts in the [composition documentation].
-
-## OAM
-
-Crossplane supports application management as the Kubernetes implementation of
-the [Open Application Model]. As such, Crossplane currently implements the
-following OAM API types as Kubernetes custom resources.
-
-* `WorkloadDefinition`: defines the kind of components that an application
- developer can use in an application, along with the component's schema.
- * Crossplane also implements the core `ContainerizedWorkload` type.
- Infrastructure owners may define any resource as a workload type by
- referencing it in a `WorkloadDefinition`.
-* `Component`: describe functional units that may be instantiated as part of a
- larger distributed application. For example, each micro-service in an
- application is described as a `Component`.
-* `Trait`: a discretionary runtime overlay that augments a component workload
- type with additional features. It represents an opportunity for those in the
- application operator role to make specific decisions about the configuration
- of components, without having to involve the developer.
- * Crossplane also implements the core `ManualScalerTrait` type.
-* `ApplicationConfiguration`: includes one or more component instances, each
- represented by a component definition that defines how an instance of a
- component spec should be deployed.
-
-For more information, take a look at the [OAM documentation].
-
-
-
-[Crossplane Concepts]: crossplane-concepts.png
-[providers]: #providers
-[provider-azure]: https://github.com/crossplane/provider-azure
-[packages]: #packages
-[managed resources]: #managed-resources
-[OAM]: #oam
-[CRDs]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[controllers]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-controllers
-[providers documentation]: providers.md
-[doc.crds.dev]: https://doc.crds.dev
-[managed resources documentation]: managed-resources.md
-[composition documentation]: composition.md
-[Open Application Model]: https://oam.dev/
-[OAM documentation]: oam.md
diff --git a/docs/v0.12/introduction/providers.md b/docs/v0.12/introduction/providers.md
deleted file mode 100644
index 61ecce9b..00000000
--- a/docs/v0.12/introduction/providers.md
+++ /dev/null
@@ -1,129 +0,0 @@
----
-title: Providers
-toc: true
-weight: 101
-indent: true
----
-
-# Providers
-
-Providers extend Crossplane to enable infrastructure resource provisioning.
-In order to provision a resource, a Custom Resource Definition(CRD)
-needs to be registered in your Kubernetes cluster and its controller should
-be watching the Custom Resources those CRDs define. Provider packages
-contain many Custom Resource Definitions and their controllers.
-
-Here is the list of current providers:
-
-### AWS Provider
-* [GitHub][provider-aws]
-* [API Reference][aws-reference]
-
-### GCP Provider
-* [GitHub][provider-gcp]
-* [API Reference][gcp-reference]
-
-### Azure Provider
-* [GitHub][provider-azure]
-* [API Reference][azure-reference]
-
-### Rook Provider
-* [GitHub][provider-rook]
-* [API Reference][rook-reference]
-
-### Alibaba Cloud Provider
-* [GitHub][provider-alibaba]
-* [API Reference][alibaba-reference]
-
-## Installing Providers
-
-The core Crossplane controller can install provider controllers and CRDs for you
-through its own provider packaging mechanism, which is triggered by the application
-of a `ClusterPackageInstall` resource. For example, in order to request
-installation of the `provider-gcp` package, apply the following resource to the
-cluster where Crossplane is running:
-
-```yaml
-apiVersion: packages.crossplane.io/v1alpha1
-kind: ClusterPackageInstall
-metadata:
- name: provider-gcp
- namespace: crossplane-system
-spec:
- package: "crossplane/provider-gcp:master"
-```
-
-The field `spec.package` is where you refer to the container image of the
-provider. Crossplane Package Manager will unpack that container, register
-CRDs and set up necessary RBAC rules and then start the controllers.
-
-There are a few other ways to to trigger the installation of provider
-packages:
-
-* As part of Crossplane Helm chart by adding the following
- statement to your `helm install` command: `--set clusterPackages.gcp.deploy=true`
- It will install the default version hard-coded in that release of Crossplane
- Helm chart but if you'd like to specif an exact version, you can add:
- `--set clusterPackages.gcp.version=master`.
-* Using [Crossplane kubectl plugin][crossplane-cli]:
- `kubectl crossplane package install --cluster -n crossplane-system 'crossplane/provider-gcp:master' provider-gcp`
-
-You can uninstall a provider by deleting the `ClusterPackageInstall` resource
-you've created.
-
-## Configuring Providers
-
-In order to authenticate with the external provider API, the provider controllers
-need to have access to credentials. It could be an IAM User for AWS, a Service
-Account for GCP or a Service Principal for Azure. Every provider has a type called
-`Provider` that has information about how to authenticate to the provider API.
-An example `Provider` resource for Azure looks like the following:
-
-```yaml
-apiVersion: azure.crossplane.io/v1alpha3
-kind: Provider
-metadata:
- name: prod-acc
-spec:
- credentialsSecretRef:
- namespace: crossplane-system
- name: azure-prod-creds
- key: credentials
-```
-
-You can see that there is a reference to a key in a specific `Secret`. The value
-of that key should contain the credentials that the controller will use. The
-documentation of each provider should give you an idea of how that credentials
-blob should look like. See [Getting Started][getting-started] guide for more details.
-
-The following is an example usage of Azure `Provider`, referenced by a `MySQLServer`:
-
-```yaml
-apiVersion: database.azure.crossplane.io/v1beta1
-kind: MySQLServer
-metadata:
- name: prod-sql
-spec:
- providerRef: prod-acc
- ...
-```
-
-The Azure provider controller will use that provider for this instance of `MySQLServer`.
-Since every resource has its own reference to a `Provider`, you can have multiple
-`Provider` resources in your cluster referenced by different resources.
-
-
-
-
-[provider-aws]: https://github.com/crossplane/provider-aws
-[aws-reference]: https://doc.crds.dev/github.com/crossplane/provider-aws
-[provider-gcp]: https://github.com/crossplane/provider-gcp
-[gcp-reference]: https://doc.crds.dev/github.com/crossplane/provider-gcp
-[provider-azure]: https://github.com/crossplane/provider-azure
-[azure-reference]: https://doc.crds.dev/github.com/crossplane/provider-azure
-[provider-rook]: https://github.com/crossplane/provider-rook
-[rook-reference]: https://doc.crds.dev/github.com/crossplane/provider-rook
-[provider-alibaba]: https://github.com/crossplane/provider-alibaba
-[alibaba-reference]: https://doc.crds.dev/github.com/crossplane/provider-alibaba
-[getting-started]: ../getting-started/install-configure.md
-[crossplane-cli]: https://github.com/crossplane/crossplane-cli
diff --git a/docs/v0.12/media/arch.png b/docs/v0.12/media/arch.png
deleted file mode 100644
index 8205e62e..00000000
Binary files a/docs/v0.12/media/arch.png and /dev/null differ
diff --git a/docs/v0.12/media/banner.png b/docs/v0.12/media/banner.png
deleted file mode 100644
index 0a495e1d..00000000
Binary files a/docs/v0.12/media/banner.png and /dev/null differ
diff --git a/docs/v0.12/media/crossplane-overview.png b/docs/v0.12/media/crossplane-overview.png
deleted file mode 100644
index 87c25a89..00000000
Binary files a/docs/v0.12/media/crossplane-overview.png and /dev/null differ
diff --git a/docs/v0.12/media/logo.svg b/docs/v0.12/media/logo.svg
deleted file mode 100644
index 3af90369..00000000
--- a/docs/v0.12/media/logo.svg
+++ /dev/null
@@ -1,310 +0,0 @@
-
-
-
diff --git a/docs/v0.12/reference/configure.md b/docs/v0.12/reference/configure.md
deleted file mode 100644
index 45c4934c..00000000
--- a/docs/v0.12/reference/configure.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Configure
-toc: true
-weight: 302
-indent: true
----
-
-# Configure Your Cloud Provider Account
-
-In order for Crossplane to be able to manage resources in a specific cloud
-provider, you will need to create an account for Crossplane to use. Use the
-links below for cloud-specific instructions to create an account that can be
-used throughout the guides:
-
-* [Google Cloud Platform (GCP) Service Account]
-* [Microsoft Azure Service Principal]
-* [Amazon Web Services (AWS) IAM User]
-
-Once you have configured your cloud provider account, you can get started
-provisioning resources!
-
-
-
-[Google Cloud Platform (GCP) Service Account]: ../cloud-providers/gcp/gcp-provider.md
-[Microsoft Azure Service Principal]: ../cloud-providers/azure/azure-provider.md
-[Amazon Web Services (AWS) IAM User]: ../cloud-providers/aws/aws-provider.md
diff --git a/docs/v0.12/reference/install.md b/docs/v0.12/reference/install.md
deleted file mode 100644
index 7c4d61c3..00000000
--- a/docs/v0.12/reference/install.md
+++ /dev/null
@@ -1,347 +0,0 @@
----
-title: Install
-toc: true
-weight: 301
-indent: true
----
-
-# Install Crossplane
-
-Crossplane can be easily installed into any existing Kubernetes cluster using
-the regularly published Helm chart. The Helm chart contains all the custom
-resources and controllers needed to deploy and configure Crossplane.
-
-## Pre-requisites
-
-* [Kubernetes cluster]
- * For example [Minikube], minimum version `v0.28+`
-* [Helm], minimum version `v2.12.0+`.
- * For Helm 2, make sure Tiller is initialized with sufficient permissions to
- work on `crossplane-system` namespace.
-
-## Installation
-
-Helm charts for Crossplane are currently published to the `alpha` and `master`
-channels. In the future, `beta` and `stable` will also be available.
-
-### Alpha
-
-The alpha channel is the most recent release of Crossplane that is considered
-ready for testing by the community.
-
-Install with Helm 2:
-
-```console
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-Install with Helm 3:
-
-If your Kubernetes version is lower than 1.15 and you'd like to install
-Crossplane via Helm 3, you'll need Helm v3.1.0+ that has the flag
-`--disable-openapi-validation`.
-
-```console
-kubectl create namespace crossplane-system
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-
-# Kubernetes 1.15 and newer versions
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane
-
-# Kubernetes 1.14 and older versions
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane --disable-openapi-validation
-```
-
-### Master
-
-The `master` channel contains the latest commits, with all automated tests
-passing. `master` is subject to instability, incompatibility, and features may
-be added or removed without much prior notice. It is recommended to use one of
-the more stable channels, but if you want the absolute newest Crossplane
-installed, then you can use the `master` channel.
-
-To install the Helm chart from master, you will need to pass the specific
-version returned by the `search` command:
-
-Install with Helm 2:
-
-```console
-helm repo add crossplane-master https://charts.crossplane.io/master/
-helm search crossplane-master
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version
-```
-
-For example:
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version 0.0.0-249.637ccf9
-```
-
-Install with Helm 3:
-
-If your Kubernetes version is lower than 1.15 and you'd like to install
-Crossplane via Helm 3, you'll need Helm v3.1.0+.
-
-```console
-kubectl create namespace crossplane-system
-helm repo add crossplane-master https://charts.crossplane.io/master/
-helm search repo crossplane-master --devel
-
-# Kubernetes 1.15 and newer versions
-helm install crossplane --namespace crossplane-system crossplane-master/crossplane --version --devel
-
-# Kubernetes 1.14 and older versions
-helm install crossplane --namespace crossplane-system crossplane-master/crossplane --version --devel --disable-openapi-validation
-```
-
-## Installing Infrastructure Providers
-
-You can add additional functionality to Crossplane's control plane by installing
-`providers`. For example, each supported cloud provider has its own
-corresponding Crossplane `provider` that contains all the functionality for that
-particular cloud. After a cloud provider's infrastructure `provider` is
-installed, you will be able to provision and manage resources within that cloud
-from Crossplane.
-
-### Installation with Helm
-
-You can include deployment of additional infrastructure providers into your helm
-installation by setting `clusterPackages..deploy` to `true`.
-
-For example, the following will install `master` version of the GCP package.
-
-Using Helm 2:
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version --set clusterPackages.gcp.deploy=true --set clusterPackages.gcp.version=master
-```
-
-Using Helm 3:
-
-```console
-kubectl create namespace crossplane-system
-helm install crossplane --namespace crossplane-system crossplane-master/crossplane --version --set clusterPackages.gcp.deploy=true --set clusterPackages.gcp.version=master --devel
-```
-
-See [helm configuration parameters](#configuration) for supported packages and
-parameters.
-
-### Manual Installation
-
-After Crossplane has been installed, it is possible to extend Crossplane's
-functionality by installing Crossplane providers.
-
-#### GCP Provider
-
-To get started with Google Cloud Platform (GCP), create a file named
-`provider-gcp.yaml` with the following content:
-
-```yaml
-apiVersion: packages.crossplane.io/v1alpha1
-kind: ClusterPackageInstall
-metadata:
- name: provider-gcp
- namespace: crossplane-system
-spec:
- package: "crossplane/provider-gcp:v0.11.0"
-```
-
-Then you can install the GCP provider into Crossplane in the `gcp` namespace
-with the following command:
-
-```console
-kubectl apply -f provider-gcp.yaml
-```
-
-#### AWS Provider
-
-To get started with Amazon Web Services (AWS), create a file named
-`provider-aws.yaml` with the following content:
-
-```yaml
-apiVersion: packages.crossplane.io/v1alpha1
-kind: ClusterPackageInstall
-metadata:
- name: provider-aws
- namespace: crossplane-system
-spec:
- package: "crossplane/provider-aws:v0.11.1"
-```
-
-Then you can install the AWS provider into Crossplane in the `aws` namespace
-with the following command:
-
-```console
-kubectl apply -f provider-aws.yaml
-```
-
-#### Azure Provider
-
-To get started with Microsoft Azure, create a file named `provider-azure.yaml`
-with the following content:
-
-```yaml
-apiVersion: packages.crossplane.io/v1alpha1
-kind: ClusterPackageInstall
-metadata:
- name: provider-azure
- namespace: crossplane-system
-spec:
- package: "crossplane/provider-azure:v0.11.0"
-```
-
-Then you can install the Azure provider into Crossplane in the `azure` namespace
-with the following command:
-
-```console
-kubectl apply -f provider-azure.yaml
-```
-
-#### Rook Provider
-
-To get started with Rook, create a file named `provider-rook.yaml` with the
-following content:
-
-```yaml
-apiVersion: packages.crossplane.io/v1alpha1
-kind: ClusterPackageInstall
-metadata:
- name: provider-rook
- namespace: crossplane-system
-spec:
- package: "crossplane/provider-rook:v0.7.0"
-```
-
-Then you can install the Rook provider into Crossplane in the `rook` namespace
-with the following command:
-
-```console
-kubectl apply -f provider-rook.yaml
-```
-
-### Uninstalling Infrastructure Providers
-
-The infrastructure can be uninstalled simply by deleting the provider resources
-from the cluster with a command similar to what's shown below. **Note** that
-this will also **delete** any resources that Crossplane has provisioned in the
-cloud provider if their `ReclaimPolicy` is set to `Delete`.
-
-After you have ensured that you are completely done with all your cloud provider
-resources, you can then run one of the commands below, depending on which cloud
-provider you are removing, to remove its provider from Crossplane:
-
-#### Uninstalling GCP
-
-```console
-kubectl delete -f provider-gcp.yaml
-```
-
-#### Uninstalling AWS
-
-```console
-kubectl delete -f provider-aws.yaml
-```
-
-#### Uninstalling Azure
-
-```console
-kubectl delete -f provider-azure.yaml
-```
-
-#### Uninstalling Rook
-
-```console
-kubectl delete -f provider-rook.yaml
-```
-
-## Uninstalling the Chart
-
-To uninstall/delete the `crossplane` deployment:
-
-```console
-helm delete --purge crossplane
-```
-
-That command removes all Kubernetes components associated with Crossplane,
-including all the custom resources and controllers.
-
-## Configuration
-
-The following tables lists the configurable parameters of the Crossplane chart
-and their default values.
-
-| Parameter | Description | Default |
-| -------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------ |
-| `image.repository` | Image | `crossplane/crossplane` |
-| `image.tag` | Image tag | `master` |
-| `image.pullPolicy` | Image pull policy | `Always` |
-| `imagePullSecrets` | Names of image pull secrets to use | `dockerhub` |
-| `replicas` | The number of replicas to run for the Crossplane operator | `1` |
-| `deploymentStrategy` | The deployment strategy for the Crossplane operator | `RollingUpdate` |
-| `clusterPackages.aws.deploy` | Deploy AWS package | `false`
-| `clusterPackages.aws.version` | AWS provider version to deploy | ``
-| `clusterPackages.gcp.deploy` | Deploy GCP package | `false`
-| `clusterPackages.gcp.version` | GCP provider version to deploy | ``
-| `clusterPackages.azure.deploy` | Deploy Azure package | `false`
-| `clusterPackages.azure.version` | Azure provider version to deploy | ``
-| `clusterPackages.rook.deploy` | Deploy Rook package | `false`
-| `clusterPackages.rook.version` | Rook provider version to deploy | ``
-| `personas.deploy` | Install roles and bindings for Crossplane user personas | `true`
-| `templateStacks.enabled` | Enable experimental template stacks support | `true`
-| `templateStacks.controllerImage` | Template Stack controller image | `crossplane/templating-controller:v0.2.1`
-| `priorityClassName ` | Priority class name for crossplane and package manager pods | `""`
-| `resourcesCrossplane.limits.cpu` | CPU resource limits for Crossplane | `100m`
-| `resourcesCrossplane.limits.memory` | Memory resource limits for Crossplane | `512Mi`
-| `resourcesCrossplane.requests.cpu` | CPU resource requests for Crossplane | `100m`
-| `resourcesCrossplane.requests.memory` | Memory resource requests for Crossplane | `256Mi`
-| `resourcesPackageManager.limits.cpu` | CPU resource limits for PackageManager | `100m`
-| `resourcesPackageManager.limits.memory` | Memory resource limits for PackageManager | `512Mi`
-| `resourcesPackageManager.requests.cpu` | CPU resource requests for PackageManager | `100m`
-| `resourcesPackageManager.requests.memory` | Memory resource requests for PackageManager | `256Mi`
-| `forceImagePullPolicy` | Force the named ImagePullPolicy on Package install and containers | `""`
-| `insecureAllowAllApigroups` | Enable core Kubernetes API group permissions for Packages. When enabled, Packages may declare dependency on core Kubernetes API types.) | `false` |
-| `insecurePassFullDeployment` | Enable packages to pass their full deployment, including security context. When omitted, Package controller deployments will have existing pod security context fields (excluding `fsGroup`) removed and `runAsNonRoot` set to `true`. All containers will have existing security context fields removed and replaced by `false` values for `privileged` and `allowPrivilegeEscalation` and `true` value for `runAsNonRoot`. | `false` |
-| `insecureInstallJob` | Enable package install jobs to run as root. When omitted, Package install jobs will have existing pod security context fields removed and `runAsNonRoot` set to `true`. All containers will have existing security context fields removed and replaced by `false` values for `privileged` and `allowPrivilegeEscalation` and `true` value for `runAsNonRoot`. | `false` |
-
-### Command Line
-
-You can pass the settings with helm command line parameters. Specify each
-parameter using the `--set key=value[,key=value]` argument to `helm install`.
-For example, the following command will install Crossplane with an image pull
-policy of `IfNotPresent`.
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane --set image.pullPolicy=IfNotPresent
-```
-
-### Settings File
-
-Alternatively, a yaml file that specifies the values for the above parameters
-(`values.yaml`) can be provided while installing the chart.
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane -f values.yaml
-```
-
-Here are the sample settings to get you started.
-
-```yaml
-replicas: 1
-
-deploymentStrategy: RollingUpdate
-
-image:
- repository: crossplane/crossplane
- tag: master
- pullPolicy: Always
-
-imagePullSecrets:
-- dockerhub
-```
-
-
-
-[Kubernetes cluster]: https://kubernetes.io/docs/setup/
-[Minikube]: https://kubernetes.io/docs/tasks/tools/install-minikube/
-[Helm]: https://docs.helm.sh/using_helm/
diff --git a/docs/v0.12/reference/learn_more.md b/docs/v0.12/reference/learn_more.md
deleted file mode 100644
index 40d23292..00000000
--- a/docs/v0.12/reference/learn_more.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: Learn More
-toc: true
-weight: 304
-indent: true
----
-
-# Learn More
-
-If you have any questions, please drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us]!
-
-***Learn more about using Crossplane***
- - [GitLab deploys into multiple clouds from kubectl using Crossplane](https://about.gitlab.com/2019/05/20/gitlab-first-deployed-kubernetes-api-to-multiple-clouds/)
- - [CNCF Talks & Community Presentations](https://www.youtube.com/playlist?list=PL510POnNVaaZJj9OG6PbgsZvgYbhwJRyE)
- - [Software Engineering Daily - Intro Podcast](https://softwareengineeringdaily.com/2019/01/02/crossplane-multicloud-control-plane-with-bassam-tabbara/)
- - [Crossplane Architecture](https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit?usp=sharing)
- - [Latest Design Docs](https://github.com/crossplane/crossplane/tree/master/design)
- - [Roadmap](https://github.com/crossplane/crossplane/blob/master/ROADMAP.md)
-
-***Writing Kubernetes controllers to extend Crossplane***
- - [Keep the Space Shuttle Flying: Writing Robust Operators](https://www.youtube.com/watch?v=uf97lOApOv8)
- - [Best practices for building Kubernetes Operators](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)
- - [Programming Kubernetes Book](https://www.oreilly.com/library/view/programming-kubernetes/9781492047094/)
- - [Crossplane Reconciler Patterns](https://github.com/crossplane/crossplane/blob/master/design/design-doc-reconciler-patterns.md)
- - [Contributor Guide](https://github.com/crossplane/crossplane/blob/master/CONTRIBUTING.md)
-
-***Join the growing Crossplane community and get involved!***
-- Join our [Community Slack](https://slack.crossplane.io/)!
-- Submit an issue on [GitHub](https://github.com/crossplane/crossplane)
-- Attend our bi-weekly [Community Meeting](https://github.com/crossplane/crossplane#community-meeting)
-- Join our bi-weekly live stream: [The Binding Status](https://github.com/crossplane/tbs)
-- Subscribe to our [YouTube Channel](https://www.youtube.com/channel/UC19FgzMBMqBro361HbE46Fw)
-- Drop us a note on Twitter: [@crossplane_io](https://twitter.com/crossplane_io)
-- Email us: [info@crossplane.io](mailto:info@crossplane.io)
-
-
-
-[join-crossplane-slack]: https://slack.crossplane.io
-[contact-us]: https://github.com/crossplane/crossplane#contact
diff --git a/docs/v0.12/reference/overview.md b/docs/v0.12/reference/overview.md
deleted file mode 100644
index 3376f8c9..00000000
--- a/docs/v0.12/reference/overview.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Reference
-toc: true
-weight: 300
----
-
-# Overview
-
-The reference documentation includes answers to frequently asked questions, information about similar projects, and links to resources that can help you learn more about Crossplane and Kubernetes. If you have additional information that you think would be valuable for the community, please feel free to [open a pull request]() and add it.
-
-1. [Install]
-1. [Configure]
-1. [Troubleshoot]
-1. [Learn More]
-
-
-
-[Install]: install.md
-[Configure]: configure.md
-[Troubleshoot]: troubleshoot.md
-[Learn More]: learn_more.md
\ No newline at end of file
diff --git a/docs/v0.12/reference/troubleshoot.md b/docs/v0.12/reference/troubleshoot.md
deleted file mode 100644
index 44857359..00000000
--- a/docs/v0.12/reference/troubleshoot.md
+++ /dev/null
@@ -1,262 +0,0 @@
----
-title: Troubleshoot
-toc: true
-weight: 303
-indent: true
----
-
-# Troubleshooting
-
-* [Using the trace command]
-* [Resource Status and Conditions]
-* [Crossplane Logs]
-* [Pausing Crossplane]
-* [Deleting a Resource Hangs]
-* [Host-Aware Resource Debugging]
-
-## Using the trace command
-
-The [Crossplane CLI] trace command provides a holistic view for a particular
-object and related ones to ease debugging and troubleshooting process. It finds
-the relevant Crossplane resources for a given one and provides detailed
-information as well as an overview indicating what could be wrong.
-
-Usage:
-```
-kubectl crossplane trace TYPE[.GROUP] NAME [-n| --namespace NAMESPACE] [--kubeconfig KUBECONFIG] [-o| --outputFormat dot]
-```
-
-Examples:
-```
-# Trace a KubernetesApplication
-kubectl crossplane trace KubernetesApplication wordpress-app-83f04457-0b1b-4532-9691-f55cf6c0da6e -n app-project1-dev
-
-# Trace a MySQLInstance
-kubectl crossplane trace MySQLInstance wordpress-mysql-83f04457-0b1b-4532-9691-f55cf6c0da6e -n app-project1-dev
-```
-
-For more information, see [the trace command documentation].
-
-## Resource Status and Conditions
-
-Most Crossplane resources have a `status` section that can represent the current
-state of that particular resource. Running `kubectl describe` against a
-Crossplane resource will frequently give insightful information about its
-condition. For example, to determine the status of a MySQLInstance resource
-claim, run:
-
-```shell
-kubectl -n app-project1-dev describe mysqlinstance mysql-claim
-```
-
-This should produce output that includes:
-
-```console
-Status:
- Conditions:
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Managed claim is waiting for managed resource to become bindable
- Status: False
- Type: Ready
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Successfully reconciled managed resource
- Status: True
- Type: Synced
-```
-
-Most Crossplane resources set exactly two condition types; `Ready` and `Synced`.
-`Ready` represents the availability of the resource itself - whether it is
-creating, deleting, available, unavailable, binding, etc. `Synced` represents
-the success of the most recent attempt to 'reconcile' the _desired_ state of the
-resource with its _actual_ state. The `Synced` condition is the first place you
-should look when a Crossplane resource is not behaving as expected.
-
-## Crossplane Logs
-
-The next place to look to get more information or investigate a failure would be
-in the Crossplane pod logs, which should be running in the `crossplane-system`
-namespace. To get the current Crossplane logs, run the following:
-
-```shell
-kubectl -n crossplane-system logs -lapp=crossplane
-```
-
-Remember that much of Crossplane's functionality is provided by Stacks. You can
-use `kubectl logs` to view Stack logs too, though Stacks may not run in the
-`crossplane-system` namespace.
-
-## Pausing Crossplane
-
-Sometimes, for example when you encounter a bug. it can be useful to pause
-Crossplane if you want to stop it from actively attempting to manage your
-resources. To pause Crossplane without deleting all of its resources, run the
-following command to simply scale down its deployment:
-
-```bash
-kubectl -n crossplane-system scale --replicas=0 deployment/crossplane
-```
-
-Once you have been able to rectify the problem or smooth things out, you can
-unpause Crossplane simply by scaling its deployment back up:
-
-```bash
-kubectl -n crossplane-system scale --replicas=1 deployment/crossplane
-```
-
-Remember that much of Crossplane's functionality is provided by Stacks. You can
-use `kubectl scale` to pause Stack pods too, though Stacks may not run in the
-`crossplane-system` namespace.
-
-## Deleting a Resource Hangs
-
-The resources that Crossplane manages will automatically be cleaned up so as not
-to leave anything running behind. This is accomplished by using finalizers, but
-in certain scenarios the finalizer can prevent the Kubernetes object from
-getting deleted.
-
-To deal with this, we essentially want to patch the object to remove its
-finalizer, which will then allow it to be deleted completely. Note that this
-won't necessarily delete the external resource that Crossplane was managing, so
-you will want to go to your cloud provider's console and look there for any
-lingering resources to clean up.
-
-In general, a finalizer can be removed from an object with this command:
-
-```console
-kubectl patch -p '{"metadata":{"finalizers": []}}' --type=merge
-```
-
-For example, for a Workload object (`workloads.compute.crossplane.io`) named
-`test-workload`, you can remove its finalizer with:
-
-```console
-kubectl patch workloads.compute.crossplane.io test-workload -p '{"metadata":{"finalizers": []}}' --type=merge
-```
-
-## Host-Aware Resource Debugging
-
-Stack resources (including the Stack, service accounts, deployments, and jobs)
-are usually easy to identify by name. These resource names are based on the name
-used in the StackInstall or Stack resource.
-
-### Resource Location
-
-In a host-aware configuration, these resources may be divided between the host
-and the tenant.
-
-The host, which runs the Stack controller, does not need (or get) the CRDs used
-by the Stack controller. The Stack controller connects to the tenant Kubernetes
-API to watch the owned types of the Stack (which is why the CRDs are only
-installed on the Tenant).
-
-Kind | Name | Place
----- | ----- | ------
-pod | crossplane | Host (ns: tenantFoo-system)
-pod | stack-manager | Host (ns: tenantFoo-system)
-job | (stack installjob) | Host (ns: tenantFoo-controllers)
-pod | (stack controller) | Host (ns: tenantFoo-controllers)
-
-Kind | Name | Place
----- | ----- | ------
-crd | Stack, SI, CSI | Tenant
-Stack | wordpress | Tenant
-StackInstall | wordpress | Tenant
-crd | KubernetesEngine, MysqlInstance, ... | Tenant
-crd | GKEInstance, CloudSQLInstance, ... | Tenant
-(rbac) | (stack controller) | Tenant
-(rbac) | (workspace owner, crossplane-admin) | Tenant
-(rbac) | (stack:namespace:1.2.3:admin) | Tenant
-crd | WordpressInstance | Tenant
-WordpressInstance | wp-instance | Tenant
-KubernetesApplication | wp-instance | Tenant
-
-Kind | Name | Place
----- | ----- | ------
-pod | wp-instance (from KubernetesAplication) | New Cluster
-
-### Name Truncation
-
-In some cases, the full name of a Stack resource, which could be up to 253
-characters long, can not be represented in the created resources. For example,
-jobs and deployment names may not exceed 63 characters because these names are
-turned into resource label values which impose a 63 character limit. Stack
-created resources whose names would otherwise not be permitted in the Kubernetes
-API will be truncated with a unique suffix.
-
-When running the Stack Manager in host-aware mode, tenant stack resources
-created in the host controller namespace generally reuse the Stack names:
-"{tenant namespace}.{tenant name}". In order to avoid the name length
-restrictions, these resources may be truncated at either or both of the
-namespace segment or over the entire name. In these cases resource labels,
-owner references, and annotations should be consulted to identify the
-responsible Stack.
-
-* [Relationship Labels]
-* [Owner References]
-* Annotations: `tenant.crossplane.io/{singular}-name` and
- `tenant.crossplane.io/{singular}-namespace` (_singular_ may be `stackinstall`,
- `clusterstackinstall` or `stack`)
-
-#### Example
-
-Long resource names may be present on the tenant.
-
-```console
-$ name=stack-with-a-really-long-resource-name-so-long-that-it-will-be-truncated
-$ ns=this-is-just-a-really-long-namespace-name-at-the-character-max
-$ kubectl create ns $ns
-$ kubectl crossplane stack install --namespace $ns crossplane/sample-stack-wordpress:0.1.1 $name
-```
-
-When used as host resource names, the stack namespace and stack are concatenated
- to form host names, as well as labels. These resource names and label values
- must be truncated to fit the 63 character limit on label values.
-
-```console
-$ kubectl --context=crossplane-host -n tenant-controllers get job -o yaml
-apiVersion: v1
-items:
-- apiVersion: batch/v1
- kind: Job
- metadata:
- annotations:
- tenant.crossplane.io/stackinstall-name: stack-with-a-really-long-resource-name-so-long-that-it-will-be-truncated
- tenant.crossplane.io/stackinstall-namespace: this-is-just-a-really-long-namespace-name-at-the-character-max
- creationTimestamp: "2020-03-20T17:06:25Z"
- labels:
- core.crossplane.io/parent-group: stacks.crossplane.io
- core.crossplane.io/parent-kind: StackInstall
- core.crossplane.io/parent-name: stack-with-a-really-long-resource-name-so-long-that-it-wi-alqdw
- core.crossplane.io/parent-namespace: this-is-just-a-really-long-namespace-name-at-the-character-max
- core.crossplane.io/parent-uid: 596705e4-a28e-47c9-a907-d2732f07a85e
- core.crossplane.io/parent-version: v1alpha1
- name: this-is-just-a-really-long-namespace-name-at-the-characte-egoav
- namespace: tenant-controllers
- spec:
- backoffLimit: 0
- completions: 1
- parallelism: 1
- selector:
- matchLabels:
- controller-uid: 8f290bf2-8c91-494a-a76b-27c2ccb9e0a8
- template:
- metadata:
- creationTimestamp: null
- labels:
- controller-uid: 8f290bf2-8c91-494a-a76b-27c2ccb9e0a8
- job-name: this-is-just-a-really-long-namespace-name-at-the-characte-egoav
- ...
-```
-
-
-
-[Using the trace command]: #using-the-trace-command
-[Resource Status and Conditions]: #resource-status-and-conditions
-[Crossplane Logs]: #crossplane-logs
-[Pausing Crossplane]: #pausing-crossplane
-[Deleting a Resource Hangs]: #deleting-a-resource-hangs
-[Host-Aware Resource Debugging]: #host-aware-resource-debugging
-[Crossplane CLI]: https://github.com/crossplane/crossplane-cli
-[the trace command documentation]: https://github.com/crossplane/crossplane-cli/tree/master/docs/trace-command.md
-[Relationship Labels]: https://github.com/crossplane/crossplane/blob/master/design/one-pager-stack-relationship-labels.md
-[Owner References]: https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents
diff --git a/docs/v0.12/release/release-process.md b/docs/v0.12/release/release-process.md
deleted file mode 100644
index 215a59ea..00000000
--- a/docs/v0.12/release/release-process.md
+++ /dev/null
@@ -1,485 +0,0 @@
-# Release Process
-
-This document is meant to be a complete end-to-end guide for how to release new
-versions of software for Crossplane and its related projects.
-
-## tl;dr Process Overview
-
-All the details are available in the sections below, but we'll start this guide
-with a very high level sequential overview for how to run the release process.
-
-1. **feature freeze**: Merge all completed features into master branches of all
- repos to begin "feature freeze" period
-1. **API docs/user guides**: Regenerate API docs and update all user guides with
- current content for scenarios included in the release
-1. **release crossplane-runtime**: Tag and release a new version of
- crossplane-runtime using the GitHub UI.
-1. **pin crossplane dependencies**: Update the go modules of core crossplane in
- master to depend on the newly released version of crossplane-runtime.
-1. **pre-release tag crossplane**: Run tag pipeline to tag the start of
- pre-releases in master in the crossplane repo
-1. **branch crossplane**: Create a new release branch using the GitHub UI for
- the crossplane repo
-1. **crossplane release branch prep**: In Crossplane's release branch, update
- all examples, docs, and integration tests to update references and versions,
- including the yet to be released versions of providers and stacks.
-1. **tag**: Run the tag pipeline to tag Crossplane's release branch with an
- official semver
-1. **release providers**: Run the release process for each **provider** that we
- maintain
- 1. **pin dependencies**: Update the go modules of each provider repo to
- depend on the new version of crossplane and crossplane-runtime.
- 1. **pre-release tag**: Run tag pipeline to tag the start of pre-releases in
- **master** of each provider repo
- 1. **branch**: Create a new release branch using the GitHub UI for the
- provider repo
- 1. **release branch prep**: In the release branch, update all examples,
- docs, and integration tests to update references and versions
- 1. **test** Test builds from the release branch, fix any critical bugs that
- are found
- 1. **tag**: Run the tag pipeline to tag the release branch with an official
- semver
- 1. **build/publish**: Run build pipeline to publish build with official
- semver
-1. **release template stacks**: Run the release process for each **template
- stack** that we maintain. Note that the process for template stacks is
- slightly different from the stack release process.
- 1. **test** Test builds from the release branch (typically `master`), fix
- any critical bugs that are found
- 1. **version**: Update all version information in the docs, as appropriate
- 1. **tag**: Run the tag pipeline to tag the release branch with an official
- semver
- 1. **build/publish**: Run the publish pipeline to publish build with
- official semver
-1. **build/publish**: Run build pipeline to publish Crossplane build from
- release branch with official semver
-1. **verify**: Verify all artifacts have been published successfully, perform
- sanity testing
-1. **promote**: Run promote pipelines on all repos to promote releases to
- desired channel(s)
-1. **release notes**: Publish well authored and complete release notes on GitHub
-1. **announce**: Announce the release on Twitter, Slack, etc.
-
-## Detailed Process
-
-This section will walk through the release process in more fine grained and
-prescriptive detail.
-
-### Scope
-
-This document will cover the release process for all of the repositories that
-the Crossplane team maintains and publishes regular versioned artifacts from.
-This set of repositories covers both core Crossplane and the set of Providers,
-Stacks, and Apps that Crossplane currently maintains:
-
-* [`crossplane`](https://github.com/crossplane/crossplane)
-* [`provider-gcp`](https://github.com/crossplane/provider-gcp)
-* [`provider-aws`](https://github.com/crossplane/provider-aws)
-* [`provider-azure`](https://github.com/crossplane/provider-azure)
-* [`provider-rook`](https://github.com/crossplane/provider-rook)
-* [`stack-minimal-gcp`](https://github.com/crossplane/stack-minimal-gcp)
-* [`stack-minimal-aws`](https://github.com/crossplane/stack-minimal-aws)
-* [`stack-minimal-azure`](https://github.com/crossplane/stack-minimal-azure)
-* [`app-wordpress`](https://github.com/crossplane/app-wordpress)
-
-The release process for Providers is almost identical to that of core Crossplane
-because they use the same [shared build
-logic](https://github.com/upbound/build/). The steps in this guide will apply
-to all repositories listed above unless otherwise mentioned.
-
-### Feature Freeze
-
-Feature freeze should be performed on all repos. In order to start the feature
-freeze period, the following conditions should be met:
-
-* All expected features should be
- ["complete"](https://github.com/crossplane/crossplane/blob/master/design/one-pager-definition-of-done.md)
- and merged into master. This includes user guides, examples, API documentation
- via [crossdocs](https://github.com/negz/crossdocs/), and test updates.
-* All issues in the
- [milestone](https://github.com/crossplane/crossplane/milestones) should be
- closed
-* Sanity testing has been performed on `master`
-
-After these conditions are met, the feature freeze begins by creating the RC tag
-and the release branch.
-
-### Pin Dependencies
-
-It is a best practice to release Crossplane projects with "pinned" dependencies
-to specific versions of other upstream Crossplane projects. For example, after
-crossplane-runtime has been released, we want to update the main Crossplane repo
-to use that specific released version.
-
-To update a dependency to a specific version, simply edit the `go.mod` file to
-point to the desired version, then run `go mod tidy`.
-
-### Pre-release Tag
-
-The next step is to create the pre-release tag for the `HEAD` commit in
-`master`. This tag serves as an indication of when the release was branched
-from master and is also important for generating future versions of `master`
-builds since that [versioning
-process](https://github.com/upbound/build/blob/master/makelib/common.mk#L182-L196)
-is based on `git describe --tags`.
-
-> **NOTE:** The `tag` pipeline does not yet support additional (pre-release)
-tags in the version number, such as `v0.5.0-rc`.
-[#330](https://github.com/crossplane/crossplane/issues/330) will be resolved
-when this functionality is available. In the meantime, **manually tagging and
-pushing to the repo is required**. Ignore the steps below about running the
-pipeline because the pipeline won't work.
-
-To accomplish this, run the `tag` pipeline for each repo on the `master` branch.
-You will be prompted to enter the `version` for the tag and the `commit` hash to
-tag. It's possible to leave the `commit` field blank to default to tagging
-`HEAD`.
-
-Since this tag will essentially be the start of pre-releases working towards the
-**next** version, the `version` should be the **next** release number, plus a
-trailing tag to indicate it is a pre-release. The current convention is to use
-`*-rc`. For example, when we are releasing the `v0.9.0` release and we are
-ready for master to start working towards the **next** release of `v0.10.0`, we
-would make the tag `v0.10.0-rc`
-
-After the tag pipeline has succeeded, verify in the [GitHub
-UI](https://github.com/crossplane/crossplane/tags) that the tag was successfully
-applied to the correct commit.
-
-### Create Release Branch
-
-Creating the release branch can be done within the [GitHub
-UI](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-and-deleting-branches-within-your-repository).
-Basically, you just use the branch selector drop down and type in the name of
-the new release branch, e.g. `release-0.5`. Release branch names always follow
-the convention of `release-[minor-semver]`.
-
-If this is the first ever release branch being created in a repo (uncommon), you
-should also set up branch protection rules for the `release-*` pattern. You can
-find existing examples in the [Crossplane repo
-settings](https://github.com/crossplane/crossplane/settings/branches).
-
-At this point, the `HEAD` commit in the release branch will be our release
-candidate. The build pipeline will automatically be started due to the create
-branch event, so we can start to perform testing on this build. Note that it
-should be the exact same as what is currently in `master` since they are using
-the same commit and have the same tag. Also note that this is not the official
-release build since we have not made the official release tag yet (e.g.
-`v0.5.0`).
-
-The `master` branch can now be opened for new features since we have a safe
-release branch to continue bug fixes and improvements for the release itself.
-Essentially, `master` is free to now diverge from the release branch.
-
-### Release Branch Prep
-
-In the core Crossplane repository, we need to update the release branch docs and
-examples to point to the new versions that we will be releasing soon.
-
-* Documentation, such as [Installation
- instructions](https://github.com/crossplane/crossplane/blob/release-0.9/docs/install.md#installing-infrastructure-providers),
- and
- [Stack](https://github.com/crossplane/crossplane/blob/release-0.9/docs/stack.md)
- and
- [App](https://github.com/crossplane/crossplane/blob/release-0.9/docs/app.md)
- guides.
- * searching for `:master` will help a lot here
-* Examples, such as [`StackInstall` yaml
- files](https://github.com/crossplane/crossplane/tree/release-0.9/cluster/examples/provider)
-* [Helm chart
- defaults](https://github.com/crossplane/crossplane/blob/release-0.9/cluster/charts/crossplane/values.yaml.tmpl),
- ensure all `values.yaml.tmpl` files are updated.
- * provider versions
- * `templating-controller` version (if a new version is available and ready)
-
-#### Bug Fixes in Release Branch
-
-During our testing of the release candidate, we may find issues or bugs that we
-triage and decide we want to fix before the release goes out. In order to fix a
-bug in the release branch, the following process is recommended:
-
-1. Make the bug fix into `master` first through the normal PR process
- 1. If the applicable code has already been removed from `master` then simply
- fix the bug directly in the release branch by opening a PR directly
- against the release branch
-1. Backport the fix by performing a cherry-pick of the fix's commit hash
- (**not** the merge commit) from `master` into the release branch. For
- example, to backport a fix from master to `v0.5.0`, something like the
- following should be used:
-
- ```console
- git fetch --all
- git checkout -b release-0.5 upstream/release-0.5
- git cherry-pick -x
- ```
-
-1. Open a PR with the cherry-pick commit targeting the release-branch
-
-After all bugs have been fixed and backported to the release branch, we can move
-on to tagging the final release commit.
-
-### Tag Core Crossplane
-
-Similar to running the `tag` pipelines for each stack, now it's time to run the
-[`tag`
-pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fcrossplane%2Fcrossplane-tag/branches)
-for core Crossplane. In fact, the [instructions](#stack-tag-pipeline) are
-exactly the same:
-
-Run the tag pipeline by clicking the Run button in the Jenkins UI in the correct
-release branch's row. You will be prompted for the version you are tagging,
-e.g., `v0.5.0` as well as the commit hash. The hash is optional and if you leave
-it blank it will default to `HEAD` of the branch, which is what you want.
-
-> **Note:** The first time you run a pipeline on a new branch, you won't get
-> prompted for the values to input. The build will quickly fail and then you can
-> run (not replay) it a second time to be prompted. This is a Jenkins bug that
-> is tracked by [#41929](https://issues.jenkins-ci.org/browse/JENKINS-41929) and
-> has been open for almost 3 years, so don't hold your breath.
-
-### Draft Release Notes
-
-We're getting close to starting the official release, so you should take this
-opportunity to draft up the release notes. You can create a [new release draft
-here](https://github.com/crossplane/crossplane/releases/new). Make sure you
-select "This is a pre-release" and hit "Save draft" when you are ready to share
-and collect feedback. Do **not** hit "Publish release" yet.
-
-You can see and follow the template and structure from [previous
-releases](https://github.com/crossplane/crossplane/releases).
-
-### Provider Release Process
-
-This section will walk through how to release the Providers and does not
-directly apply to core Crossplane.
-
-#### Pin Provider Dependencies
-
-Similar to core crossplane, each provider should have its crossplane related
-dependencies pinned to the versions that we are releasing. In the **master**
-branch of each provider repo, update the `crossplane` and `crossplane-runtime`
-dependencies to the versions we are releasing.
-
-Simply edit `go.mod` with the new versions, then run `go mod tidy`.
-
-The providers also depend on `crossplane-tools`, but that currently does not
-have official releases, so in practice should be using the latest from master.
-
-#### Provider Pre-release tag
-
-Follow the same steps that we did for core crossplane to tag the **master**
-branch of each provider repo with a pre-release tag for the **next** version.
-
-These steps can be found in the [pre-release tag section](#pre-release-tag).
-
-#### Create Provider Release Branches
-
-Now create a release branch for each of the provider repos using the GitHub UI.
-The steps are the same as what we did to [create the release
-branch](#create-release-branch) for core crossplane.
-
-#### Provider Release Branch Prep
-
-In the **release branch** for each provider, you should update the version tags
-and metadata in:
-
-* `integration_tests.sh` - `STACK_IMAGE`
-* `ClusterStackInstall` sample and example yaml files
-* `*.resource.yaml` - docs links in markdown
- * Not all of these `*.resource.yaml` files have links that need to be updated,
- they are infrequent and inconsistent
-
-Searching for `:master` will be a big help here.
-
-#### Provider Tag, Build, and Publish
-
-Now that the Providers are all tested and their version metadata has been
-updated, it's time to tag the release branch with the official version tag. You
-can do this by running the `tag` pipeline on the release branch of each
-Provider:
-
-* [`provider-gcp` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-gcp-pipelines%2Fprovider-gcp-tag/branches)
-* [`provider-aws` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-aws-pipelines%2Fprovider-aws-tag/branches/)
-* [`provider-azure` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-azure-pipelines%2Fprovider-azure-tag/branches/)
-* [`provider-rook` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-rook-pipelines%2Fprovider-rook-tag/branches/)
-
-* Run the `tag` pipeline on the release branch
-* Enter the version and commit hash (leave blank for `HEAD`)
-* The first time you run on a new release branch, you won't be prompted and the
- build will fail, just run (not replay) a second time
-
-After the tag pipeline has been run and the release branch has been tagged, you
-can run the normal build pipeline on the release branch. This will kick off the
-official release build and upon success, all release artifacts will be
-officially published.
-
-After the release build succeeds, verify that the correctly versioned Provider
-images have been pushed to Docker Hub.
-
-### Template Stack Release Process
-
-The Template Stacks we maintain are slightly different from the controller-based
-stacks that we maintain. Their processes are similar but a little simpler. This
-section will walk through how to release the Template Stacks themselves, and
-does not directly apply to core Crossplane.
-
-For Template Stacks, we do not use release branches unless we need to make a
-patch release. In the future we may need a more robust branching strategy, but
-for now we are not using branches because it is simpler.
-
-Note that Template Stacks **do not** require any code changes to update their
-version. A slight exception to this is for their `behavior.yaml` files, which
-should have the `controllerImage` field updated if a new version of the
-`templating-controller` is available and ready.
-
-### Template Stack Tag And Publish Pipeline
-
-Here is the list of all template stacks:
-
-* [`stack-minimal-gcp`](https://github.com/crossplane/stack-minimal-gcp)
-* [`stack-minimal-aws`](https://github.com/crossplane/stack-minimal-aws)
-* [`stack-minimal-azure`](https://github.com/crossplane/stack-minimal-azure)
-* [`app-wordpress`](https://github.com/crossplane/app-wordpress)
-
-Each one should be released as part of a complete release, using the
-instructions below. To read even more about the template stack release process,
-see [the release section of this
-document](https://github.com/crossplane/cicd/blob/master/docs/pipelines.md#how-do-i-cut-a-release)
-
-Note that there's also the
-[`templating-controller`](https://github.com/crossplane/templating-controller),
-which supports template stacks. It is possible that it **may** need to be
-released as well, but typically is released independently from Crossplane.
-
-#### Tag the Template Stack
-
-Once a template stack is tested and ready for cutting a semver release, we will
-want to tag the repository with the new release version. In most cases, to get
-the version, take a look at the most recent tag in the repo, and increment the
-minor version. For example, if the most recent tag was `v0.2.0`, the new tag
-should be `v0.3.0`.
-
-Run the template stack's tag job on Jenkins, against the `master` branch. Enter
-in the new tag to use. If the current release candidate is not the head of
-`master`, enter in the commit to tag.
-
-You can find the tag pipeline for the individual stack by going to the
-[crossplane org in Jenkins](https://jenkinsci.upbound.io/job/crossplane/),
-finding the folder with the same name as the template stack, and then going to
-the `tag` job group. Then going to the `master` branch job under the group. For
-example, here is [a link to the stack-minimal-gcp tag job for
-master](https://jenkinsci.upbound.io/job/crossplane/job/stack-minimal-gcp/job/tag/job/master/).
-
-> **Note:** The first time you run a pipeline on a new branch, you won't get
-> prompted for the values to input and the build will fail. See details in the
-> [tagging core crossplane section](#tag-core-crossplane).
-
-#### Publish the Template Stack
-
-After the tag pipeline has been run and the repository has been tagged, you can
-run the `publish` job for the template stack. For example, here's a [link to the
-stack-minimal-gcp publish
-job](https://jenkinsci.upbound.io/job/crossplane/job/stack-minimal-gcp/job/publish/job/master/).
-This will kick off the official release build and upon success, all release
-artifacts will be officially published. This should also be run from the
-`master` branch in most cases. Or, if a release branch was used, from the
-release branch. The tag parameter should be used, and the tag for the current
-release should be used. For example, if the new tag we created was `v0.3.0`, we
-would want to provide `v0.3.0` for the `publish` job.
-
-#### Verify the Template Stack was Published
-
-After the publish build succeeds, verify that the correctly versioned template
-stack images have been pushed to Docker Hub.
-
-### Template Stack Patch Releases
-
-To do a patch release with a template stack, create a release branch from the
-minor version tag on the `master` branch, if a release branch doesn't already
-exist. Then, the regular tagging and publishing process for template stacks can
-be followed, incrementing the patch version to get the new release tag.
-
-### Build and Release Core Crossplane
-
-After the providers, stacks, and apps have all been released, ensure the [normal
-build
-pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fcrossplane%2Fbuild/branches)
-is run on the release branch for core crossplane. This will be the official
-release build with an official version number and all of its release artifacts
-will be published.
-
-After the pipeline runs successfully, you should verify that all artifacts have
-been published to:
-
-* [Docker Hub](https://hub.docker.com/repository/docker/crossplane/crossplane)
-* [S3 releases bucket](https://releases.crossplane.io/)
-* [Helm chart repository](https://charts.crossplane.io/)
-* [Docs website](https://crossplane.io/docs/latest)
-
-### Promotion
-
-If everything looks good with the official versioned release that we just
-published, we can go ahead and run the `promote` pipeline for the core
-crossplane and provider repos. This is a very quick pipeline that doesn't
-rebuild anything, it simply makes metadata changes to the published release to
-also include the release in the channel of your choice.
-
-Currently, we only support the `master` and `alpha` channels.
-
-For the core crossplane and each provider repo, run the `promote` pipeline on
-the release branch and input the version you would like to promote (e.g.
-`v0.5.0`) and the channel you'd like to promote it to. The first time you run
-this pipeline on a new release branch, you will not be prompted for values, so
-the pipeline will fail. Just run (not replay) it a second time to be prompted.
-
-* Run `promote` pipeline for `master` channel
-* Run `promote` pipeline for `alpha` channel
-
-After the `promote` pipelines have succeeded, verify on DockerHub and the Helm
-chart repository that the release has been promoted to the right channels.
-
-### Publish Release Notes
-
-Now that the release has been published and verified, you can publish the
-[release notes](https://github.com/crossplane/crossplane/releases) that you
-drafted earlier. After incorporating all feedback, you can now click on the
-"Publish release" button.
-
-This will send an email notification with the release notes to all watchers of
-the repo.
-
-### Announce Release
-
-We have completed the entire release, so it's now time to announce it to the
-world. Using the [@crossplane_io](https://twitter.com/crossplane_io) Twitter
-account, tweet about the new release and blog. You'll see examples from the
-previous releases, such as this tweet for
-[v0.4](https://twitter.com/crossplane_io/status/1189307636350705664).
-
-Post a link to this tweet on the Slack #announcements channel, then copy a link
-to that and post it in the #general channel.
-
-### Patch Releases
-
-We also have the ability to run patch releases to update previous releases that
-have already been published. These patch releases are always run from the last
-release branch, we do **not** create a new release branch for a patch release.
-
-The basic flow is **very** similar to a normal release, but with a few less
-steps. Please refer to details for each step in the sections above.
-
-* Fix any bugs in `master` first and then `cherry-pick -x` to the release branch
- * If `master` has already removed the relevant code then make your fix
- directly in the release branch
-* After all testing on the release branch look good and any docs/examples/tests
- have been updated with the new version number, run the `tag` pipeline on the
- release branch with the new patch version (e.g. `v0.5.1`)
-* Run the normal build pipeline on the release branch to build and publish the
- release
-* Publish release notes
-* Run promote pipeline to promote the patch release to the `master` and `alpha`
- channels
diff --git a/docs/v0.12/snippets/provision/alibaba.yaml b/docs/v0.12/snippets/provision/alibaba.yaml
deleted file mode 100644
index 125a45c6..00000000
--- a/docs/v0.12/snippets/provision/alibaba.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-apiVersion: database.alibaba.crossplane.io/v1alpha1
-kind: RDSInstance
-metadata:
- name: rdspostgresql
-spec:
- forProvider:
- engine: PostgreSQL
- engineVersion: "9.4"
- dbInstanceClass: rds.pg.s1.small
- dbInstanceStorageInGB: 20
- securityIPList: "0.0.0.0/0"
- masterUsername: "test123"
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: alibaba-rdspostgresql-conn
- providerRef:
- name: alibaba-provider
- reclaimPolicy: Delete
diff --git a/docs/v0.12/snippets/provision/aws.yaml b/docs/v0.12/snippets/provision/aws.yaml
deleted file mode 100644
index 8473eef5..00000000
--- a/docs/v0.12/snippets/provision/aws.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-apiVersion: database.aws.crossplane.io/v1beta1
-kind: RDSInstance
-metadata:
- name: rdspostgresql
-spec:
- forProvider:
- dbInstanceClass: db.t2.small
- masterUsername: masteruser
- allocatedStorage: 20
- engine: postgres
- engineVersion: "9.6"
- skipFinalSnapshotBeforeDeletion: true
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: aws-rdspostgresql-conn
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
diff --git a/docs/v0.12/snippets/provision/azure.yaml b/docs/v0.12/snippets/provision/azure.yaml
deleted file mode 100644
index d8302e2b..00000000
--- a/docs/v0.12/snippets/provision/azure.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
-apiVersion: azure.crossplane.io/v1alpha3
-kind: ResourceGroup
-metadata:
- name: sqlserverpostgresql-rg
-spec:
- location: West US 2
- reclaimPolicy: Delete
- providerRef:
- name: azure-provider
----
-apiVersion: database.azure.crossplane.io/v1beta1
-kind: PostgreSQLServer
-metadata:
- name: sqlserverpostgresql
-spec:
- forProvider:
- administratorLogin: myadmin
- resourceGroupNameRef:
- name: sqlserverpostgresql-rg
- location: West US 2
- sslEnforcement: Disabled
- version: "9.6"
- sku:
- tier: GeneralPurpose
- capacity: 2
- family: Gen5
- storageProfile:
- storageMB: 20480
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: sqlserverpostgresql-conn
- providerRef:
- name: azure-provider
- reclaimPolicy: Delete
diff --git a/docs/v0.12/snippets/provision/gcp.yaml b/docs/v0.12/snippets/provision/gcp.yaml
deleted file mode 100644
index 9c53acec..00000000
--- a/docs/v0.12/snippets/provision/gcp.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-apiVersion: database.gcp.crossplane.io/v1beta1
-kind: CloudSQLInstance
-metadata:
- name: cloudsqlpostgresql
-spec:
- forProvider:
- databaseVersion: POSTGRES_9_6
- region: us-central1
- settings:
- tier: db-custom-1-3840
- dataDiskType: PD_SSD
- dataDiskSizeGb: 10
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: cloudsqlpostgresql-conn
- providerRef:
- name: gcp-provider
- reclaimPolicy: Delete
diff --git a/docs/v0.12/snippets/publish/clusterrole.yaml b/docs/v0.12/snippets/publish/clusterrole.yaml
deleted file mode 100644
index 1b391c56..00000000
--- a/docs/v0.12/snippets/publish/clusterrole.yaml
+++ /dev/null
@@ -1,16 +0,0 @@
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: postgresqlinstances.database.example.org
- labels:
- rbac.crossplane.io/aggregate-to-crossplane: "true"
-rules:
-- apiGroups:
- - database.example.org
- resources:
- - postgresqlinstances
- - postgresqlinstances/status
- - postgresqlinstancerequirements
- - postgresqlinstancerequirements/status
- verbs:
- - "*"
diff --git a/docs/v0.12/snippets/publish/composition-alibaba.yaml b/docs/v0.12/snippets/publish/composition-alibaba.yaml
deleted file mode 100644
index 62aa42d3..00000000
--- a/docs/v0.12/snippets/publish/composition-alibaba.yaml
+++ /dev/null
@@ -1,44 +0,0 @@
----
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: Composition
-metadata:
- name: postgresqlinstances.alibaba.database.example.org
- labels:
- provider: alibaba
- guide: quickstart
-spec:
- writeConnectionSecretsToNamespace: crossplane-system
- reclaimPolicy: Delete
- from:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstance
- to:
- - base:
- apiVersion: database.alibaba.crossplane.io/v1alpha1
- kind: RDSInstance
- spec:
- forProvider:
- engine: PostgreSQL
- engineVersion: "9.4"
- dbInstanceClass: rds.pg.s1.small
- securityIPList: "0.0.0.0/0"
- masterUsername: "myuser"
- writeConnectionSecretToRef:
- namespace: crossplane-system
- providerRef:
- name: alibaba-provider
- reclaimPolicy: Delete
- patches:
- - fromFieldPath: "metadata.uid"
- toFieldPath: "spec.writeConnectionSecretToRef.name"
- transforms:
- - type: string
- string:
- fmt: "%s-postgresql"
- - fromFieldPath: "spec.parameters.storageGB"
- toFieldPath: "spec.forProvider.dbInstanceStorageInGB"
- connectionDetails:
- - fromConnectionSecretKey: username
- - fromConnectionSecretKey: password
- - fromConnectionSecretKey: endpoint
- - fromConnectionSecretKey: port
\ No newline at end of file
diff --git a/docs/v0.12/snippets/publish/composition-aws-with-vpc.yaml b/docs/v0.12/snippets/publish/composition-aws-with-vpc.yaml
deleted file mode 100644
index d1c9a044..00000000
--- a/docs/v0.12/snippets/publish/composition-aws-with-vpc.yaml
+++ /dev/null
@@ -1,163 +0,0 @@
----
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: Composition
-metadata:
- name: vpcpostgresqlinstances.aws.database.example.org
- labels:
- provider: aws
- guide: quickstart
- vpc: new
-spec:
- writeConnectionSecretsToNamespace: crossplane-system
- reclaimPolicy: Delete
- from:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstance
- to:
- - base:
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: VPC
- spec:
- cidrBlock: 192.168.0.0/16
- enableDnsSupport: true
- enableDnsHostNames: true
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: Subnet
- metadata:
- labels:
- zone: us-west-2a
- spec:
- cidrBlock: 192.168.64.0/18
- vpcIdSelector:
- matchControllerRef: true
- availabilityZone: us-west-2a
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: Subnet
- metadata:
- labels:
- zone: us-west-2b
- spec:
- cidrBlock: 192.168.128.0/18
- vpcIdSelector:
- matchControllerRef: true
- availabilityZone: us-west-2b
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: Subnet
- metadata:
- labels:
- zone: us-west-2c
- spec:
- cidrBlock: 192.168.192.0/18
- vpcIdSelector:
- matchControllerRef: true
- availabilityZone: us-west-2c
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: database.aws.crossplane.io/v1beta1
- kind: DBSubnetGroup
- spec:
- forProvider:
- description: An excellent formation of subnetworks.
- subnetIdSelector:
- matchControllerRef: true
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: InternetGateway
- spec:
- vpcIdSelector:
- matchControllerRef: true
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: RouteTable
- spec:
- vpcIdSelector:
- matchControllerRef: true
- routes:
- - destinationCidrBlock: 0.0.0.0/0
- gatewayIdSelector:
- matchControllerRef: true
- associations:
- - subnetIdSelector:
- matchLabels:
- zone: us-west-2a
- - subnetIdSelector:
- matchLabels:
- zone: us-west-2b
- - subnetIdSelector:
- matchLabels:
- zone: us-west-2c
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: SecurityGroup
- spec:
- vpcIdSelector:
- matchControllerRef: true
- groupName: crossplane-getting-started
- description: Allow access to PostgreSQL
- ingress:
- - fromPort: 5432
- toPort: 5432
- protocol: tcp
- cidrBlocks:
- - cidrIp: 0.0.0.0/0
- description: Everywhere
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- - base:
- apiVersion: database.aws.crossplane.io/v1beta1
- kind: RDSInstance
- spec:
- forProvider:
- dbSubnetGroupNameSelector:
- matchControllerRef: true
- vpcSecurityGroupIDSelector:
- matchControllerRef: true
- dbInstanceClass: db.t2.small
- masterUsername: masteruser
- engine: postgres
- engineVersion: "9.6"
- skipFinalSnapshotBeforeDeletion: true
- publiclyAccessible: true
- writeConnectionSecretToRef:
- namespace: crossplane-system
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- patches:
- - fromFieldPath: "metadata.uid"
- toFieldPath: "spec.writeConnectionSecretToRef.name"
- transforms:
- - type: string
- string:
- fmt: "%s-postgresql"
- - fromFieldPath: "spec.parameters.storageGB"
- toFieldPath: "spec.forProvider.allocatedStorage"
- connectionDetails:
- - fromConnectionSecretKey: username
- - fromConnectionSecretKey: password
- - fromConnectionSecretKey: endpoint
- - fromConnectionSecretKey: port
diff --git a/docs/v0.12/snippets/publish/composition-aws.yaml b/docs/v0.12/snippets/publish/composition-aws.yaml
deleted file mode 100644
index 8db4f332..00000000
--- a/docs/v0.12/snippets/publish/composition-aws.yaml
+++ /dev/null
@@ -1,46 +0,0 @@
----
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: Composition
-metadata:
- name: postgresqlinstances.aws.database.example.org
- labels:
- provider: aws
- guide: quickstart
- vpc: default
-spec:
- writeConnectionSecretsToNamespace: crossplane-system
- reclaimPolicy: Delete
- from:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstance
- to:
- - base:
- apiVersion: database.aws.crossplane.io/v1beta1
- kind: RDSInstance
- spec:
- forProvider:
- dbInstanceClass: db.t2.small
- masterUsername: masteruser
- engine: postgres
- engineVersion: "9.6"
- skipFinalSnapshotBeforeDeletion: true
- publiclyAccessible: true
- writeConnectionSecretToRef:
- namespace: crossplane-system
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- patches:
- - fromFieldPath: "metadata.uid"
- toFieldPath: "spec.writeConnectionSecretToRef.name"
- transforms:
- - type: string
- string:
- fmt: "%s-postgresql"
- - fromFieldPath: "spec.parameters.storageGB"
- toFieldPath: "spec.forProvider.allocatedStorage"
- connectionDetails:
- - fromConnectionSecretKey: username
- - fromConnectionSecretKey: password
- - fromConnectionSecretKey: endpoint
- - fromConnectionSecretKey: port
\ No newline at end of file
diff --git a/docs/v0.12/snippets/publish/composition-azure.yaml b/docs/v0.12/snippets/publish/composition-azure.yaml
deleted file mode 100644
index 435fd40a..00000000
--- a/docs/v0.12/snippets/publish/composition-azure.yaml
+++ /dev/null
@@ -1,77 +0,0 @@
----
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: Composition
-metadata:
- name: postgresqlinstances.azure.database.example.org
- labels:
- provider: azure
- guide: quickstart
-spec:
- writeConnectionSecretsToNamespace: crossplane-system
- reclaimPolicy: Delete
- from:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstance
- to:
- - base:
- apiVersion: azure.crossplane.io/v1alpha3
- kind: ResourceGroup
- spec:
- location: West US 2
- reclaimPolicy: Delete
- providerRef:
- name: azure-provider
- - base:
- apiVersion: database.azure.crossplane.io/v1beta1
- kind: PostgreSQLServer
- spec:
- forProvider:
- administratorLogin: myadmin
- resourceGroupNameSelector:
- matchControllerRef: true
- location: West US 2
- sslEnforcement: Disabled
- version: "9.6"
- sku:
- tier: GeneralPurpose
- capacity: 2
- family: Gen5
- writeConnectionSecretToRef:
- namespace: crossplane-system
- providerRef:
- name: azure-provider
- reclaimPolicy: Delete
- patches:
- - fromFieldPath: "metadata.uid"
- toFieldPath: "spec.writeConnectionSecretToRef.name"
- transforms:
- - type: string
- string:
- fmt: "%s-postgresql"
- - fromFieldPath: "spec.parameters.storageGB"
- toFieldPath: "spec.forProvider.storageProfile.storageMB"
- transforms:
- - type: math
- math:
- multiply: 1024
- connectionDetails:
- - fromConnectionSecretKey: username
- - fromConnectionSecretKey: password
- - fromConnectionSecretKey: endpoint
- - name: port
- value: "5432"
- - base:
- apiVersion: database.azure.crossplane.io/v1alpha3
- kind: PostgreSQLServerFirewallRule
- spec:
- forProvider:
- serverNameSelector:
- matchControllerRef: true
- resourceGroupNameSelector:
- matchControllerRef: true
- properties:
- startIpAddress: 0.0.0.0
- endIpAddress: 255.255.255.254
- reclaimPolicy: Delete
- providerRef:
- name: azure-provider
diff --git a/docs/v0.12/snippets/publish/composition-gcp.yaml b/docs/v0.12/snippets/publish/composition-gcp.yaml
deleted file mode 100644
index bf937168..00000000
--- a/docs/v0.12/snippets/publish/composition-gcp.yaml
+++ /dev/null
@@ -1,49 +0,0 @@
----
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: Composition
-metadata:
- name: postgresqlinstances.gcp.database.example.org
- labels:
- provider: gcp
- guide: quickstart
-spec:
- writeConnectionSecretsToNamespace: crossplane-system
- reclaimPolicy: Delete
- from:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstance
- to:
- - base:
- apiVersion: database.gcp.crossplane.io/v1beta1
- kind: CloudSQLInstance
- spec:
- forProvider:
- databaseVersion: POSTGRES_9_6
- region: us-central1
- settings:
- tier: db-custom-1-3840
- dataDiskType: PD_SSD
- ipConfiguration:
- ipv4Enabled: true
- authorizedNetworks:
- - value: "0.0.0.0/0"
- writeConnectionSecretToRef:
- namespace: crossplane-system
- providerRef:
- name: gcp-provider
- reclaimPolicy: Delete
- patches:
- - fromFieldPath: "metadata.uid"
- toFieldPath: "spec.writeConnectionSecretToRef.name"
- transforms:
- - type: string
- string:
- fmt: "%s-postgresql"
- - fromFieldPath: "spec.parameters.storageGB"
- toFieldPath: "spec.forProvider.settings.dataDiskSizeGb"
- connectionDetails:
- - fromConnectionSecretKey: username
- - fromConnectionSecretKey: password
- - fromConnectionSecretKey: endpoint
- - name: port
- value: "5432"
\ No newline at end of file
diff --git a/docs/v0.12/snippets/publish/definition.yaml b/docs/v0.12/snippets/publish/definition.yaml
deleted file mode 100644
index d3126e9e..00000000
--- a/docs/v0.12/snippets/publish/definition.yaml
+++ /dev/null
@@ -1,35 +0,0 @@
----
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: InfrastructureDefinition
-metadata:
- name: postgresqlinstances.database.example.org
-spec:
- connectionSecretKeys:
- - username
- - password
- - endpoint
- - port
- crdSpecTemplate:
- group: database.example.org
- version: v1alpha1
- names:
- kind: PostgreSQLInstance
- listKind: PostgreSQLInstanceList
- plural: postgresqlinstances
- singular: postgresqlinstance
- validation:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- parameters:
- type: object
- properties:
- storageGB:
- type: integer
- required:
- - storageGB
- required:
- - parameters
\ No newline at end of file
diff --git a/docs/v0.12/snippets/publish/pod.yaml b/docs/v0.12/snippets/publish/pod.yaml
deleted file mode 100644
index 0b65ecef..00000000
--- a/docs/v0.12/snippets/publish/pod.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
- name: see-db
- namespace: default
-spec:
- containers:
- - name: see-db
- image: postgres:9.6
- command: ['psql']
- args: ['-c', 'SELECT current_database();']
- env:
- - name: PGDATABASE
- value: postgres
- - name: PGHOST
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: endpoint
- - name: PGUSER
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: username
- - name: PGPASSWORD
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: password
- - name: PGPORT
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: port
diff --git a/docs/v0.12/snippets/publish/publication.yaml b/docs/v0.12/snippets/publish/publication.yaml
deleted file mode 100644
index 064ef9f6..00000000
--- a/docs/v0.12/snippets/publish/publication.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
----
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: InfrastructurePublication
-metadata:
- name: postgresqlinstances.database.example.org
-spec:
- infrastructureDefinitionRef:
- name: postgresqlinstances.database.example.org
\ No newline at end of file
diff --git a/docs/v0.12/snippets/publish/requirement-alibaba.yaml b/docs/v0.12/snippets/publish/requirement-alibaba.yaml
deleted file mode 100644
index 8428da04..00000000
--- a/docs/v0.12/snippets/publish/requirement-alibaba.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstanceRequirement
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: alibaba
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.12/snippets/publish/requirement-aws.yaml b/docs/v0.12/snippets/publish/requirement-aws.yaml
deleted file mode 100644
index 6d4cc00d..00000000
--- a/docs/v0.12/snippets/publish/requirement-aws.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstanceRequirement
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: aws
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.12/snippets/publish/requirement-azure.yaml b/docs/v0.12/snippets/publish/requirement-azure.yaml
deleted file mode 100644
index d850307b..00000000
--- a/docs/v0.12/snippets/publish/requirement-azure.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstanceRequirement
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: azure
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.12/snippets/publish/requirement-gcp.yaml b/docs/v0.12/snippets/publish/requirement-gcp.yaml
deleted file mode 100644
index 9bc3bc92..00000000
--- a/docs/v0.12/snippets/publish/requirement-gcp.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstanceRequirement
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: gcp
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.12/snippets/run/appconfig.yaml b/docs/v0.12/snippets/run/appconfig.yaml
deleted file mode 100644
index 9bfca5d8..00000000
--- a/docs/v0.12/snippets/run/appconfig.yaml
+++ /dev/null
@@ -1,59 +0,0 @@
----
-apiVersion: core.oam.dev/v1alpha2
-kind: ApplicationConfiguration
-metadata:
- name: service-tracker
-spec:
- components:
- - componentName: data-api-database
- parameterValues:
- - name: database-secret
- value: tracker-database-secret
- - componentName: data-api
- parameterValues:
- - name: database-secret
- value: tracker-database-secret
- - componentName: flights-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: flights-api
- spec:
- replicaCount: 2
- - componentName: quakes-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: quakes-api
- spec:
- replicaCount: 2
- - componentName: weather-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: weather-api
- spec:
- replicaCount: 2
- - componentName: service-tracker-ui
- parameterValues:
- - name: flights-uri
- value: "http://flights-api.default.svc.cluster.local:3003/"
- - name: weather-uri
- value: "http://weather-api.default.svc.cluster.local:3015/"
- - name: quakes-uri
- value: "http://quakes-api.default.svc.cluster.local:3012/"
diff --git a/docs/v0.12/snippets/run/components.yaml b/docs/v0.12/snippets/run/components.yaml
deleted file mode 100644
index 51ade0c9..00000000
--- a/docs/v0.12/snippets/run/components.yaml
+++ /dev/null
@@ -1,197 +0,0 @@
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: data-api-database
-spec:
- workload:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstanceRequirement
- metadata:
- name: app-postgresql
- spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- guide: quickstart
- parameters:
- - name: database-secret
- description: Secret to which to write PostgreSQL database connection details.
- required: true
- fieldPaths:
- - spec.writeConnectionSecretToRef.name
- - name: database-provider
- description: |
- Cloud provider that should be used to create a PostgreSQL database.
- Either alibaba, aws, azure, or gcp.
- fieldPaths:
- - spec.compositionSelector.matchLabels.provider
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: data-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: data-api
- spec:
- containers:
- - name: data-api
- image: artursouza/rudr-data-api:0.50
- env:
- - name: DATABASE_USER
- fromSecret:
- key: username
- - name: DATABASE_PASSWORD
- fromSecret:
- key: password
- - name: DATABASE_HOSTNAME
- fromSecret:
- key: endpoint
- - name: DATABASE_PORT
- fromSecret:
- key: port
- - name: DATABASE_NAME
- value: postgres
- - name: DATABASE_DRIVER
- value: postgresql
- ports:
- - name: http
- containerPort: 3009
- protocol: TCP
- livenessProbe:
- exec:
- command: [wget, -q, http://127.0.0.1:3009/status, -O, /dev/null, -S]
- parameters:
- - name: database-secret
- description: Secret from which to read PostgreSQL connection details.
- required: true
- fieldPaths:
- - spec.containers[0].env[0].fromSecret.name
- - spec.containers[0].env[1].fromSecret.name
- - spec.containers[0].env[2].fromSecret.name
- - spec.containers[0].env[3].fromSecret.name
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: flights-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: flights-api
- spec:
- containers:
- - name: flights-api
- image: sonofjorel/rudr-flights-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3003
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: quakes-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: quakes-api
- spec:
- containers:
- - name: quakes-api
- image: sonofjorel/rudr-quakes-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3012
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: service-tracker-ui
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: web-ui
- spec:
- containers:
- - name: service-tracker-ui
- image: sonofjorel/rudr-web-ui:0.49
- env:
- - name: FLIGHT_API_ROOT
- - name: WEATHER_API_ROOT
- - name: QUAKES_API_ROOT
- ports:
- - name: http
- containerPort: 8080
- protocol: TCP
- parameters:
- - name: flights-uri
- description: URI at which the flights service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
- - name: weather-uri
- description: URI at which the weather service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[1].value
- - name: quakes-uri
- description: URI at which the quakes service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[2].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: weather-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: weather-api
- spec:
- containers:
- - name: weather-api
- image: sonofjorel/rudr-weather-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3015
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
\ No newline at end of file
diff --git a/docs/v0.12/snippets/run/definitions.yaml b/docs/v0.12/snippets/run/definitions.yaml
deleted file mode 100644
index ef19bc8a..00000000
--- a/docs/v0.12/snippets/run/definitions.yaml
+++ /dev/null
@@ -1,24 +0,0 @@
----
-apiVersion: core.oam.dev/v1alpha2
-kind: WorkloadDefinition
-metadata:
- name: containerizedworkloads.core.oam.dev
-spec:
- definitionRef:
- name: containerizedworkloads.core.oam.dev
----
-apiVersion: core.oam.dev/v1alpha2
-kind: TraitDefinition
-metadata:
- name: manualscalertraits.core.oam.dev
-spec:
- definitionRef:
- name: manualscalertraits.core.oam.dev
----
-apiVersion: core.oam.dev/v1alpha2
-kind: WorkloadDefinition
-metadata:
- name: postgresqlinstancerequirements.database.example.org
-spec:
- definitionRef:
- name: postgresqlinstancerequirements.database.example.org
diff --git a/docs/v0.13/README.md b/docs/v0.13/README.md
deleted file mode 100644
index cea6b1dc..00000000
--- a/docs/v0.13/README.md
+++ /dev/null
@@ -1,66 +0,0 @@
-# Overview
-
-
-
-Crossplane is an open source Kubernetes add-on that extends any cluster with
-the ability to provision and manage cloud infrastructure, services, and
-applications using kubectl, GitOps, or any tool that works with the Kubernetes
-API.
-
-With Crossplane you can:
-
-* **Provision & manage cloud infrastructure with kubectl**
- * [Install Crossplane] to provision and manage cloud infrastructure and
- services from any Kubernetes cluster.
- * Provision infrastructure primitives from any provider ([GCP], [AWS],
- [Azure], [Alibaba], on-prem) and use them alongside existing application
- configurations.
- * Version, manage, and deploy with your favorite tools and workflows that
- you’re using with your clusters today.
-
-* **Publish custom infrastructure resources for your applications to use**
- * Define, compose, and publish your own [infrastructure resources] with
- declarative YAML, resulting in your own infrastructure CRDs being added to
- the Kubernetes API for applications to use.
- * Hide infrastructure complexity and include policy guardrails, so
- applications can easily and safely consume the infrastructure they need,
- using any tool that works with the Kubernetes API.
- * Consume infrastructure resources alongside any Kubernetes application to
- provision and manage the cloud services they need with Crossplane as an
- add-on to any Kubernetes cluster.
-
-* **Deploy applications using a team-centric approach with OAM**
- * Define cloud native applications and the infrastructure they require with
- the Open Application Model ([OAM]).
- * Collaborate with a team-centric approach with a strong separation of
- concerns.
- * Deploy application configurations from app delivery pipelines or GitOps
- workflows, using the proven Kubernetes declarative model.
-
-Separation of concerns is core to Crossplane’s approach to infrastructure and
-application management, so team members can deliver value by focusing on what
-they know best. Crossplane's team-centric approach reflects individuals often
-specializing in the following roles:
-
-* **Infrastructure Operators** - provide infrastructure and services for apps
- to consume
-* **Application Developers** - build application components independent of
- infrastructure
-* **Application Operators** - compose, deploy, and run application
- configurations
-
-## Getting Started
-
-[Install Crossplane] into any Kubernetes cluster to get started.
-
-
-
-[Install Crossplane]: getting-started/install-configure.md
-[Custom Resource Definitions]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[reconciling]: https://kubernetes.io/docs/concepts/architecture/controller/
-[GCP]: https://github.com/crossplane/provider-gcp
-[AWS]: https://github.com/crossplane/provider-aws
-[Azure]: https://github.com/crossplane/provider-azure
-[Alibaba]: https://github.com/crossplane/provider-alibaba
-[infrastructure resources]: https://blog.crossplane.io/crossplane-v0-10-compose-and-publish-your-own-infrastructure-crds-velero-backup-restore-compatibility-and-more/
-[OAM]: https://oam.dev/
diff --git a/docs/v0.13/api-docs/crossplane.md b/docs/v0.13/api-docs/crossplane.md
deleted file mode 100644
index dfdc06b1..00000000
--- a/docs/v0.13/api-docs/crossplane.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: crossplane
-toc: true
-weight: 401
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/crossplane
----
diff --git a/docs/v0.13/api-docs/oam-kubernetes-runtime.md b/docs/v0.13/api-docs/oam-kubernetes-runtime.md
deleted file mode 100644
index 2a5026cc..00000000
--- a/docs/v0.13/api-docs/oam-kubernetes-runtime.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: oam-kubernetes-runtime
-toc: true
-weight: 408
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/oam-kubernetes-runtime
----
diff --git a/docs/v0.13/api-docs/overview.md b/docs/v0.13/api-docs/overview.md
deleted file mode 100644
index e9a92c48..00000000
--- a/docs/v0.13/api-docs/overview.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: API Documentation
-toc: true
-weight: 400
----
-
-# API Documentation
-
-The Crossplane ecosystem contains many CRDs that map to API types represented by
-external infrastructure providers. The documentation for these CRDs are
-auto-generated on [doc.crds.dev]. To find the CRDs available for providers
-maintained by the Crossplane organization, you can search for the Github URL, or
-append it in the [doc.crds.dev] URL path.
-
-For instance, to find the CRDs available for [provider-azure], you would go to:
-
-[doc.crds.dev/github.com/crossplane/provider/azure]
-
-By default, you will be served the latest CRDs on the `master` branch for the
-repository. If you prefer to see the CRDs for a specific version, you can append
-the git tag for the release:
-
-[doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0]
-
-Crossplane repositories that are not providers but do publish CRDs are also
-served on [doc.crds.dev]. For instance, the [crossplane/crossplane] repository.
-
-Bugs and feature requests for API documentation should be [opened as issues] on
-the open source [doc.crds.dev repo].
-
-
-
-[doc.crds.dev]: https://doc.crds.dev/
-[provider-azure]: https://github.com/crossplane/provider-azure
-[doc.crds.dev/github.com/crossplane/provider/azure]: https://doc.crds.dev/github.com/crossplane/provider-azure
-[doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0]: https://doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0
-[crossplane/crossplane]: https://doc.crds.dev/github.com/crossplane/crossplane
-[opened as issues]: https://github.com/crdsdev/doc/issues/new
-[doc.crds.dev repo]: https://github.com/crdsdev/doc
diff --git a/docs/v0.13/api-docs/provider-alibaba.md b/docs/v0.13/api-docs/provider-alibaba.md
deleted file mode 100644
index 099c6f43..00000000
--- a/docs/v0.13/api-docs/provider-alibaba.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-alibaba
-toc: true
-weight: 402
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-alibaba
----
diff --git a/docs/v0.13/api-docs/provider-aws.md b/docs/v0.13/api-docs/provider-aws.md
deleted file mode 100644
index b2e74e53..00000000
--- a/docs/v0.13/api-docs/provider-aws.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-aws
-toc: true
-weight: 403
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-aws
----
diff --git a/docs/v0.13/api-docs/provider-azure.md b/docs/v0.13/api-docs/provider-azure.md
deleted file mode 100644
index 955b3d22..00000000
--- a/docs/v0.13/api-docs/provider-azure.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-azure
-toc: true
-weight: 404
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-azure
----
diff --git a/docs/v0.13/api-docs/provider-gcp.md b/docs/v0.13/api-docs/provider-gcp.md
deleted file mode 100644
index 6e49c9b4..00000000
--- a/docs/v0.13/api-docs/provider-gcp.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-gcp
-toc: true
-weight: 405
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-gcp
----
diff --git a/docs/v0.13/api-docs/provider-helm.md b/docs/v0.13/api-docs/provider-helm.md
deleted file mode 100644
index a52f2f21..00000000
--- a/docs/v0.13/api-docs/provider-helm.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-helm
-toc: true
-weight: 407
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane-contrib/provider-helm
----
diff --git a/docs/v0.13/api-docs/provider-rook.md b/docs/v0.13/api-docs/provider-rook.md
deleted file mode 100644
index e84e2c36..00000000
--- a/docs/v0.13/api-docs/provider-rook.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-rook
-toc: true
-weight: 406
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-rook
----
diff --git a/docs/v0.13/cloud-providers/aws/aws-provider.md b/docs/v0.13/cloud-providers/aws/aws-provider.md
deleted file mode 100644
index cbb6b339..00000000
--- a/docs/v0.13/cloud-providers/aws/aws-provider.md
+++ /dev/null
@@ -1,143 +0,0 @@
-# Adding Amazon Web Services (AWS) to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your AWS
-account to be ready for integration with Crossplane. This will be done by adding
-an AWS `ProviderConfig` resource type, which enables Crossplane to communicate with an
-AWS account.
-
-## Requirements
-
-Prior to adding AWS to Crossplane, following steps need to be taken
-
-- Crossplane is installed in a k8s cluster
-- AWS Stack is installed in the same cluster
-- `kubectl` is configured to communicate with the same cluster
-
-## Step 1: Configure `aws` CLI
-
-Crossplane uses [AWS security credentials], and stores them as a [secret] which
-is managed by an AWS `ProviderConfig` instance. In addition, the AWS default region is
-also used for targeting a specific region. Crossplane requires to have [`aws`
-command line tool] [installed] and [configured]. Once installed, the credentials
-and configuration will reside in `~/.aws/credentials` and `~/.aws/config`
-respectively.
-
-## Step 2: Setup `aws` Provider
-
-Run `setup.sh` to read `aws` credentials and region, and create an `aws
-provider` instance in Crossplane:
-
-```bash
-curl -O https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/configure/aws/providerconfig.yaml
-curl -O https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/configure/aws/setup.sh
-./setup.sh [--profile aws_profile]
-```
-
-The `--profile` switch is optional and specifies the [aws named profile] that
-was set in Step 1. If not provided, the `default` profile will be selected.
-
-Once the script is successfully executed, Crossplane will use the specified aws
-account and region in the given named profile to create subsequent AWS managed
-resources.
-
-You can confirm the existence of the AWS `ProviderConfig` by running:
-
-```bash
-kubectl get providerconfig default
-```
-
-## Optional: Setup AWS Provider Manually
-
-An AWS [user][aws user] with `Administrative` privileges is needed to enable
-Crossplane to create the required resources. Once the user is provisioned, an
-[Access Key][] needs to be created so the user can have API access.
-
-Using the set of [access key credentials][AWS security credentials] for the user
-with the right access, we need to [install][install-aws] [`aws cli`][aws command
-line tool], and then [configure][aws-cli-configure] it.
-
-When the AWS cli is configured, the credentials and configuration will be in
-`~/.aws/credentials` and `~/.aws/config` respectively. These will be consumed in
-the next step.
-
-When configuring the AWS cli, the user credentials could be configured under a
-specific [AWS named profile][], or under `default`. Without loss of generality,
-in this guide let's assume that the credentials are configured under the
-`aws_profile` profile (which could also be `default`). We'll use this profile to
-setup cloud provider in the next section.
-
-Crossplane uses the AWS user credentials that were configured in the previous
-step to create resources in AWS. These credentials will be stored as a
-[secret][kubernetes secret] in Kubernetes, and will be used by an AWS
-`ProviderConfig` instance. The default AWS region is also pulled from the cli
-configuration, and added to the AWS provider.
-
-To store the credentials as a secret, run:
-
-```bash
-# retrieve profile's credentials, save it under 'default' profile, and base64 encode it
-BASE64ENCODED_AWS_ACCOUNT_CREDS=$(echo -e "[default]\naws_access_key_id = $(aws configure get aws_access_key_id --profile $aws_profile)\naws_secret_access_key = $(aws configure get aws_secret_access_key --profile $aws_profile)" | base64 | tr -d "\n")
-```
-
-Next, we'll need to create an AWS provider configuration:
-
-```bash
-cat > provider.yaml <
-
-[`aws` command line tool]: https://aws.amazon.com/cli/
-[AWS SDK for GO]: https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/setting-up.html
-[installed]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html
-[configured]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html
-[AWS security credentials]: https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html
-[secret]:https://kubernetes.io/docs/concepts/configuration/secret/
-[aws named profile]: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html
-[aws user]: https://docs.aws.amazon.com/mediapackage/latest/ug/setting-up-create-iam-user.html
-[Access Key]: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
-[AWS security credentials]: https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html
-[aws command line tool]: https://aws.amazon.com/cli/
-[install-aws]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html
-[aws-cli-configure]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html
-[kubernetes secret]: https://kubernetes.io/docs/concepts/configuration/secret/
-[AWS named profile]: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html
diff --git a/docs/v0.13/cloud-providers/azure/azure-provider.md b/docs/v0.13/cloud-providers/azure/azure-provider.md
deleted file mode 100644
index e1a69fce..00000000
--- a/docs/v0.13/cloud-providers/azure/azure-provider.md
+++ /dev/null
@@ -1,129 +0,0 @@
-# Adding Microsoft Azure to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your Azure
-account to be ready for integration with Crossplane. The general steps we will
-take are summarized below:
-
-* Create a new service principal (account) that Crossplane will use to create
- and manage Azure resources
-* Add the required permissions to the account
-* Consent to the permissions using an administrator account
-
-## Preparing your Microsoft Azure Account
-
-In order to manage resources in Azure, you must provide credentials for a Azure
-service principal that Crossplane can use to authenticate. This assumes that you
-have already [set up the Azure CLI
-client](https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli?view=azure-cli-latest)
-with your credentials.
-
-Create a JSON file that contains all the information needed to connect and
-authenticate to Azure:
-
-```bash
-# create service principal with Owner role
-az ad sp create-for-rbac --sdk-auth --role Owner > crossplane-azure-provider-key.json
-```
-
-Take note of the `clientID` value from the JSON file that we just created, and
-save it to an environment variable:
-
-```bash
-export AZURE_CLIENT_ID=
-```
-
-Now add the required permissions to the service principal that will allow it to
-manage the necessary resources in Azure:
-
-```bash
-# add required Azure Active Directory permissions
-az ad app permission add --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --api-permissions 1cda74f2-2616-4834-b122-5cb1b07f8a59=Role 78c8a3c8-a07e-4b9e-af1b-b5ccab50a175=Role
-
-# grant (activate) the permissions
-az ad app permission grant --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --expires never
-```
-
-You might see an error similar to the following, but that is OK, the permissions
-should have gone through still:
-
-```console
-Operation failed with status: 'Conflict'. Details: 409 Client Error: Conflict for url: https://graph.windows.net/e7985bc4-a3b3-4f37-b9d2-fa256023b1ae/oauth2PermissionGrants?api-version=1.6
-```
-
-Finally, you need to grant admin permissions on the Azure Active Directory to
-the service principal because it will need to create other service principals
-for your `AKSCluster`:
-
-```bash
-# grant admin consent to the service princinpal you created
-az ad app permission admin-consent --id "${AZURE_CLIENT_ID}"
-```
-
-Note: You might need `Global Administrator` role to `Grant admin consent for
-Default Directory`. Please contact the administrator of your Azure subscription.
-To check your role, go to `Azure Active Directory` -> `Roles and
-administrators`. You can find your role(s) by clicking on `Your Role (Preview)`
-
-After these steps are completed, you should have the following file on your
-local filesystem:
-
-* `crossplane-azure-provider-key.json`
-
-## Setup Azure Provider
-
-Before creating any resources, we need to create and configure an Azure cloud
-provider resource in Crossplane, which stores the cloud account information in
-it. All the requests from Crossplane to Azure Cloud will use the credentials
-attached to this provider resource. The following command assumes that you have
-a `crossplane-azure-provider-key.json` file that belongs to the account you’d
-like Crossplane to use.
-
-```bash
-BASE64ENCODED_AZURE_ACCOUNT_CREDS=$(base64 crossplane-azure-provider-key.json | tr -d "\n")
-```
-
-Now we’ll create our `Secret` that contains the credential and `ProviderConfig`
-resource that refers to that secret:
-
-```bash
-cat > provider.yaml < provider.yaml <
-[templating-controller]: https://github.com/crossplane/templating-controller
-[stack-gcp-sample]: https://github.com/crossplane/stack-gcp-sample
-[stack-aws-sample]: https://github.com/crossplane/stack-aws-sample
-[stack-azure-sample]: https://github.com/crossplane/stack-azure-sample
-[app-wordpress]: https://github.com/crossplane/app-wordpress
-[Wordpress Quickstart Guide]: https://github.com/crossplane/app-wordpress/blob/master/docs/quickstart.md
-[packaging an app]: experimental/packaging_an_app.md
diff --git a/docs/v0.13/contributing/experimental/packaging_an_app.md b/docs/v0.13/contributing/experimental/packaging_an_app.md
deleted file mode 100644
index 38cdbc71..00000000
--- a/docs/v0.13/contributing/experimental/packaging_an_app.md
+++ /dev/null
@@ -1,198 +0,0 @@
----
-title: Packaging an Application
-toc: false
-weight: 2000
-indent: true
----
-
-# Packaging an Application
-
-In the quick start guide, we demonstrated how Wordpress can be installed as a
-Crossplane `Application`. Now we want to learn more about how to package any
-application in a similar fashion. The good news is that we can use common
-Kubernetes configuration tools, such as [Helm] and [Kustomize], which you may
-already be familiar with.
-
-## Setting up a Repository
-
-The required components of an application repository are minimal. For example,
-the required components of the [Wordpress application] we deployed in the quick
-start are the following:
-
-```
-├── Dockerfile
-├── .registry
-│ ├── app.yaml
-│ ├── behavior.yaml
-│ ├── icon.svg
-│ └── resources
-│ ├── wordpress.apps.crossplane.io_wordpressinstances.crd.yaml
-│ ├── wordpressinstance.icon.svg
-│ ├── wordpressinstance.resource.yaml
-│ └── wordpressinstance.ui-schema.yaml
-├── helm-chart
-│ ├── Chart.yaml
-│ ├── templates
-│ │ ├── app.yaml
-│ │ ├── cluster.yaml
-│ │ └── database.yaml
-│ └── values.yaml
-```
-
-Let's take a look at each component in-depth.
-
-### Dockerfile
-
-The Dockerfile is only responsible for copying the configuration directory
-(`helm-chart/` in this case) and the `.registry` directory. You can likely use a
-very similar Dockerfile across all of your applications:
-
-```Dockerfile
-FROM alpine:3.7
-WORKDIR /
-COPY helm-chart /helm-chart
-COPY .registry /.registry
-```
-
-### .registry
-
-The `.registry` directory informs Crossplane how to install your application. It
-consists of the following:
-
-**app.yaml** `[required]`
-
-The `app.yaml` file is responsible for defining the metadata for an application,
-such as name, version, and required permissions. The Wordpress `app.yaml` is a
-good reference for available fields:
-
-```yaml
-# Human readable title of application.
-title: Wordpress
-
-overviewShort: Cloud portable Wordpress deployments behind managed Kubernetes and SQL services are demonstrated in this Crossplane Stack.
-
-overview: |-
- This Wordpress application uses a simple controller that uses Crossplane to orchestrate managed SQL services and managed Kubernetes clusters which are then used to run a Wordpress deployment.
- A simple Custom Resource Definition (CRD) is provided allowing for instances of this Crossplane managed Wordpress Application to be provisioned with a few lines of yaml.
- The Sample Wordpress Application is intended for demonstration purposes and should not be used to deploy production instances of Wordpress.
-
-# Markdown description of this entry
-readme: |-
- ### Create wordpresses
- Before wordpresses will provision, the Crossplane control cluster must
- be configured to connect to a provider (e.g. GCP, Azure, AWS).
- Once a provider is configured, starting the process of creating a
- Wordpress Application instance is easy.
-
- cat <.icon.svg`: an image to be displayed for your application CRD
-- `.resource.yaml`: a description of your application CRD
-- `.ui-schema.yaml`: the configurable fields on your CRD that you
- wish to be displayed in a UI
-
-Crossplane will take these files and apply them as [annotations] on the
-installed application. They can then be parsed by a user interface.
-
-### Configuration Directory
-
-The configuration directory contains the actual manifests for deploying your
-application. In the case of Wordpress, this includes a `KubernetesApplication`
-(`helm-chart/templates/app.yaml`), a `KubernetesCluster` claim
-(`helm-chart/templates/cluster.yaml`), and a `MySQLInstance` claim
-(`helm-chart/templates/database.yaml`). The configuration tool for the manifests
-in the directory should match the `engine` field in your
-`.registry/behavior.yaml`. The options for engines at this time are `helm3` and
-`kustomize`. Crossplane will pass values from the `spec` of the application's
-CRD as variables in the manifests. For instance, the `provisionPolicy` field in
-the `spec` of the `WordpressInstance` CRD will be passed to the Helm chart
-defined in the `helm-chart/` directory.
-
-
-
-[Helm]: https://helm.sh/
-[Kustomize]: https://kustomize.io/
-[Wordpress application]: https://github.com/crossplane/app-wordpress
-[CustomResourceDefinition]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[controller-tools]: https://github.com/kubernetes-sigs/controller-tools
-[annotations]: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
diff --git a/docs/v0.13/contributing/observability_developer_guide.md b/docs/v0.13/contributing/observability_developer_guide.md
deleted file mode 100644
index 9741512f..00000000
--- a/docs/v0.13/contributing/observability_developer_guide.md
+++ /dev/null
@@ -1,200 +0,0 @@
----
-title: Observability Developer Guide
-toc: true
-weight: 1002
-indent: true
----
-
-# Observability Developer Guide
-
-## Introduction
-
-Observability is crucial to Crossplane users; both those operating Crossplane
-and those using Crossplane to operate their infrastructure. Crossplane currently
-approaches observability via Kubernetes events and structured logs. Timeseries
-metrics are desired but [not yet implemented].
-
-## Goals
-
-In short, a non-admin user and an admin user should both be able to debug any
-issues only by inspecting logs and events. There should be no need to rebuild
-the Crossplane binary or to reach out to a Crossplane developer.
-
-A user should be able to:
-
-* Debug an issue without rebuilding the Crossplane binary
-* Understand an issue without contacting a cluster admin
-* Ask a cluster admin to check the logs for more details about the reason the
- issue happened, if the details are not part of the error message
-
-A cluster admin should be able to:
-
-* Debug an issue without rebuilding the Crossplane binary
-* Debug an issue only by looking at the logs
-* Debug an issue without needing to contact a Crossplane developer
-
-## Error reporting in the logs
-
-Error reporting in the logs is mostly intended for consumption by Crossplane
-cluster admins. A cluster admin should be able to debug any issue by inspecting
-the logs, without needing to add more logs themselves or contact a Crossplane
-developer. This means that logs should contain:
-
-* Error messages, at either the info or debug level as contextually appropriate
-* Any context leading up to an error, typically at debug level, so that the
- errors can be debugged
-
-## Error reporting as events
-
-Error reporting as Kubernetes events is primarily aimed toward end-users of
-Crossplane who are not cluster admins. Crossplane typically runs as a Kubernetes
-pod, and thus it is unlikely that most users of Crossplane will have access to
-its logs. [Events], on the other hand, are available as top-level Kubernetes
-objects, and show up the objects they relate to when running `kubectl describe`.
-
-Events should be recorded in the following cases:
-
-* A significant operation is taken on a resource
-* The state of a resource is changed
-* An error occurs
-
-The events recorded in these cases can be thought of as forming an event log of
-things that happen for the resources that Crossplane manages. Each event should
-refer back to the relevant controller and resource, and use other fields of the
-Event kind as appropriate.
-
-More details about examples of how to interact with events can be found in the
-guide to [debugging an application cluster].
-
-## Choosing between methods of error reporting
-
-There are many ways to report errors, such as:
-
-* Metrics
-* Events
-* Logging
-* Tracing
-
-It can be confusing to figure out which one is appropriate in a given situation.
-This section will try to offer advice and a mindset that can be used to help
-make this decision.
-
-Let's set the context by listing the different user scenarios where error
-reporting may be consumed. Here are the typical scenarios as we imagine them:
-
-1. A person **using** a system needs to figure out why things aren't working as
- expected, and whether they made a mistake that they can correct.
-2. A person **operating** a service needs to monitor the service's **health**,
- both now and historically.
-3. A person **debugging** a problem which happened in a **live environment**
- (often an **operator** of the system) needs information to figure out what
- happened.
-4. A person **developing** the software wants to **observe** what is happening.
-5. A person **debugging** the software in a **development environment**
- (typically a **developer** of the system) wants to debug a problem (there is
- a lot of overlap between this and the live environment debugging scenario).
-
-The goal is to satisfy the users in all of the scenarios. We'll refer to the
-scenarios by number.
-
-The short version is: we should do whatever satisfies all of the scenarios.
-Logging and events are the recommendations for satisfying the scenarios,
-although they don't cover scenario 2.
-
-The longer version is:
-
-* Scenario 1 is best served by events in the context of Crossplane, since the
- users may not have access to read logs or metrics, and even if they did, it
- would be hard to relate them back to the event the user is trying to
- understand.
-* Scenario 2 is best served by metrics, because they can be aggregated and
- understood as a whole. And because they can be used to track things over time.
-* Scenario 3 is best served by either logging that contains all the information
- about and leading up to the event. Request-tracing systems are also useful for
- this scenario.
-* Scenario 4 is usually logs, maybe at a more verbose level than normal. But it
- could be an attached debugger or some other type of tool. It could also be a
- test suite.
-* Scenario 5 is usually either logs, up to the highest imaginable verbosity, or
- an attached debugging session. If there's a gap in reporting, it could involve
- adding some print statements to get more logging.
-
-As for the question of how to decide whether to log or not, we believe it helps
-to try to visualize which of the scenarios the error or information in question
-will be used for. We recommend starting with reporting as much information as
-possible, but with configurable runtime behavior so that, for example, debugging
-logs don't show up in production normally.
-
-For the question of what constitutes an error, errors should be actionable by a
-human. See the [Dave Cheney article] on this topic for some more discussion.
-
-## In Practice
-
-Crossplane provides two observability libraries as part of crossplane-runtime:
-
-* [`event`] emits Kubernetes events.
-* [`logging`] produces structured logs. Refer to its package documentation for
- additional context on its API choices.
-
-Keep the following in mind when using the above libraries:
-
-* [Do] [not] use package level loggers or event recorders. Instantiate them in
- `main()` and plumb them down to where they're needed.
-* Each [`Reconciler`] implementation should use its own `logging.Logger` and
- `event.Recorder`. Implementations are strongly encouraged to default to using
- `logging.NewNopLogger()` and `event.NewNopRecorder()`, and accept a functional
- loggers and recorder via variadic options. See for example the [managed
- resource reconciler].
-* Each controller should use its name as its event recorder's name, and include
- its name under the `controller` structured logging key. The controllers name
- should be of the form `controllertype/resourcekind`, for example
- `managed/cloudsqlinstance` or `stacks/stackdefinition`. Controller names
- should always be lowercase.
-* Logs and events should typically be emitted by the `Reconcile` method of the
- `Reconciler` implementation; not by functions called by `Reconcile`. Author
- the methods orchestrated by `Reconcile` as if they were a library; prefer
- surfacing useful information for the `Reconciler` to log (for example by
- [wrapping errors]) over plumbing loggers and event recorders down to
- increasingly deeper layers of code.
-* Almost nothing is worth logging at info level. When deciding which logging
- level to use, consider a production deployment of Crossplane reconciling tens
- or hundreds of managed resources. If in doubt, pick debug. You can easily
- increase the log level later if it proves warranted.
-* The above is true even for errors; consider the audience. Is this an error
- only the Crossplane cluster operator can fix? Does it indicate a significant
- degradation of Crossplane's functionality? If so, log it at info. If the error
- pertains to a single Crossplane resource emit an event instead.
-* Always log errors under the structured logging key `error` (e.g.
- `log.Debug("boom!, "error", err)`). Many logging implementations (including
- Crossplane's) add context like stack traces for this key.
-* Emit events liberally; they're rate limited and deduplicated.
-* Follow [API conventions] when emitting events; ensure event reasons are unique
- and `CamelCase`.
-* Consider emitting events and logs when a terminal condition is encountered
- (e.g. `Reconcile` returns) over logging logic flow. i.e. Prefer one log line
- that reads "encountered an error fooing the bar" over two log lines that read
- "about to foo the bar" and "encountered an error". Recall that if the audience
- is a developer debugging Crossplane they will be provided a stack trace with
- file and line context when an error is logged.
-* Consider including the `reconcile.Request`, and the resource's UID and
- resource version (not API version) under the keys `request`, `uid`, and
- `version`. Doing so allows log readers to determine what specific version of a
- resource the log pertains to.
-
-Finally, when in doubt, aim for consistency with existing Crossplane controller
-implementations.
-
-
-
-[not yet implemented]: https://github.com/crossplane/crossplane/issues/314
-[Events]: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#event-v1-core
-[debugging an application cluster]: https://kubernetes.io/docs/tasks/debug-application-cluster/
-[Dave Cheney article]: https://dave.cheney.net/2015/11/05/lets-talk-about-logging
-[`event`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/event
-[`logging`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/logging
-[Do]: https://peter.bourgon.org/go-best-practices-2016/#logging-and-instrumentation
-[not]: https://dave.cheney.net/2017/01/23/the-package-level-logger-anti-pattern
-[`Reconciler`]: https://godoc.org/sigs.k8s.io/controller-runtime/pkg/reconcile#Reconciler
-[managed resource reconciler]: https://github.com/crossplane/crossplane-runtime/blob/a6bb0/pkg/reconciler/managed/reconciler.go#L436
-[wrapping errors]: https://godoc.org/github.com/pkg/errors#Wrap
-[API conventions]: https://github.com/kubernetes/community/blob/09f55c6/contributors/devel/sig-architecture/api-conventions.md#events
diff --git a/docs/v0.13/contributing/overview.md b/docs/v0.13/contributing/overview.md
deleted file mode 100644
index 8d39576f..00000000
--- a/docs/v0.13/contributing/overview.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Contributing
-toc: true
-weight: 1000
----
-
-# Contributing
-
-The following documentation is for developers who wish to contribute to or
-extend Crossplane. Please [open an
-issue](https://github.com/crossplane/crossplane/issues/new) for any additional
-documentation you would like to see in this section.
-
-1. [Provider Development Guide]
-2. [Observability Developer Guide]
-
-# Experimental Projects
-See [experimental] projects.
-
-
-[Provider Development Guide]: provider_development_guide.md
-[Observability Developer Guide]: observability_developer_guide.md
-[experimental]: experimental.md
diff --git a/docs/v0.13/contributing/provider_development_guide.md b/docs/v0.13/contributing/provider_development_guide.md
deleted file mode 100644
index 3520696d..00000000
--- a/docs/v0.13/contributing/provider_development_guide.md
+++ /dev/null
@@ -1,644 +0,0 @@
----
-title: Provider Development Guide
-toc: true
-weight: 1001
-indent: true
----
-
-# Provider Development Guide
-
-Crossplane allows you to manage infrastructure directly from Kubernetes. Each
-infrastructure API resource that Crossplane orchestrates is known as a "managed
-resource". This guide will walk through the process of adding support for a new
-kind of managed resource to a Crossplane Provider.
-
-> You can watch [TBS Episode 18] to follow along the live implementation of GCP PubSub
-managed resource.
-
-## What Makes a Crossplane Infrastructure Resource
-
-Crossplane builds atop Kubernetes's powerful architecture in which declarative
-configuration, known as resources, are continually 'reconciled' with reality by
-one or more controllers. A controller is an endless loop that:
-
-1. Observes the desired state (the declarative configuration resource).
-1. Observes the actual state (the thing said configuration resource represents).
-1. Tries to make the actual state match the desired state.
-
-Typical Crossplane managed infrastructure consists of two configuration
-resources and one controller. The GCP Provider's support for Google Cloud
-Memorystore illustrates this. First, the configuration resources:
-
-1. A [managed resource]. Managed resources are cluster scoped, high-fidelity
- representations of a resource in an external system such as a cloud
- provider's API. Managed resources are _non-portable_ across external systems
- (i.e. cloud providers); they're tightly coupled to the implementation details
- of the external resource they represent. Managed resources are defined by a
- Provider. The GCP Provider's [`CloudMemorystoreInstance`] resource is an
- example of a managed resource.
-1. A provider. Providers enable access to an external system, typically by
- indicating a Kubernetes Secret containing any credentials required to
- authenticate to the system, as well as any other metadata required to
- connect. Providers are cluster scoped, like managed resources and classes.
- The GCP [`ProviderConfig`] is an example of a provider. Note that provider is a
- somewhat overloaded term in the Crossplane ecosystem - it's also used to
- refer to the controller manager for a particular cloud, for example
- `provider-gcp`.
-
-A managed resource is powered by a controller. This controller is responsible
-for taking instances of the aforementioned high-fidelity managed resource kind
-and reconciling them with an external system. The `CloudMemorystoreInstance`
-controller watches for changes to `CloudMemorystoreInstance` resources and calls
-Google's Cloud Memorystore API to create, update, or delete an instance as
-necessary.
-
-Crossplane does not require controllers to be written in any particular
-language. The Kubernetes API server is our API boundary, so any process capable
-of [watching the API server] and updating resources can be a Crossplane
-controller.
-
-## Getting Started
-
-At the time of writing all Crossplane Services controllers are written in Go,
-and built using [crossplane-runtime]. While it is possible to write a controller
-using any language and tooling with a Kubernetes client this set of tools are
-the "[golden path]". They're well supported, broadly used, and provide a shared
-language with the Crossplane community. This guide targets [crossplane-runtime
-v0.9.0]. It assumes the reader is familiar with the Kubernetes [API Conventions]
-and the [kubebuilder book].
-
-## Defining Resource Kinds
-
-Let's assume we want to add Crossplane support for your favourite cloud's
-database-as-a-service. Your favourite cloud brands these instances as "Favourite
-DB instances". Under the hood they're powered by the open source FancySQL
-engine. We'll name the new managed resource kind `FavouriteDBInstance`.
-
-The first step toward implementing a new managed service is to define the code
-level schema of its configuration resources. These are referred to as
-[resources], (resource) [kinds], and [objects] interchangeably. The kubebuilder
-scaffolding is a good starting point for any new Crossplane API kind.
-
-> Note that while Crossplane was originally derived from kubebuilder scaffolds
-> its patterns have diverged somewhat. It is _possible_ to use kubebuilder to
-> scaffold a resource, but the author must be careful to adapt said resource to
-> Crossplane patterns. It may often be quicker to copy and modify a v1beta1 or
-> above resource from the same provider repository, rather than using
-> kubebuilder.
-
-```console
-kubebuilder create api \
- --group example --version v1alpha1 --kind FavouriteDBInstance \
- --resource=true --controller=false --namespaced=false
-```
-
-The above command should produce a scaffold similar to the below example:
-
-```go
-type FavouriteDBInstanceSpec struct {
- // INSERT ADDITIONAL SPEC FIELDS - desired state of infrastructure
- // Important: Run "make" to regenerate code after modifying this file
-}
-
-// FavouriteDBInstanceStatus defines the observed state of FavouriteDBInstance
-type FavouriteDBInstanceStatus struct {
- // INSERT ADDITIONAL STATUS FIELD - define observed state of infrastructure
- // Important: Run "make" to regenerate code after modifying this file
-}
-
-// +kubebuilder:object:root=true
-
-// FavouriteDBInstance is the Schema for the favouritedbinstance API
-// +kubebuilder:resource:scope=Cluster
-type FavouriteDBInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FavouriteDBInstanceeSpec `json:"spec,omitempty"`
- Status FavouriteDBInstanceStatus `json:"status,omitempty"`
-}
-```
-
-Crossplane requires that these newly generated API type scaffolds be extended
-with a set of struct fields, getters, and setters that are standard to all
-Crossplane resource kinds. The getters and setter methods required to satisfy
-crossplane-runtime interfaces are omitted from the below examples for brevity.
-They can be added by hand, but new services are encouraged to use [`angryjet`]
-to generate them automatically using a `//go:generate` comment per the
-[`angryjet` documentation].
-
-Note that in many cases a suitable provider will already exist. Frequently
-adding support for a new managed service requires only the definition of the
-managed resource itself.
-
-### Managed Resource Kinds
-
-Managed resources must:
-
-* Satisfy crossplane-runtime's [`resource.Managed`] interface.
-* Embed a [`ResourceStatus`] struct in their `Status` struct.
-* Embed a [`ResourceSpec`] struct in their `Spec` struct.
-* Embed a `Parameters` struct in their `Spec` struct.
-* Use the `+kubebuilder:subresource:status` [comment marker].
-* Use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-The `Parameters` struct should be a _high fidelity_ representation of the
-writeable fields of the external resource's API. Put otherwise, if your
-favourite cloud represents Favourite DB instances as a JSON object then
-`FavouriteDBParameters` should marshal to a something as close to that JSON
-object as possible while still complying with Kubernetes API conventions.
-
-For example, assume the external API object for Favourite DB instance was:
-
-```json
-{
- "id": 42,
- "name": "mycoolinstance",
- "fanciness_level": 100,
- "version": "2.3",
- "status": "ONLINE",
- "hostname": "cool.fcp.example.org"
-}
-```
-
-Further assume the `id`, `status`, and `hostname` fields were output only, and
-the `version` field was optional. The `FavouriteDBInstance` managed resource
-should look as follows:
-
-```go
-// FavouriteDBInstanceParameters define the desired state of an FavouriteDB
-// instance. Most fields map directly to an Instance:
-// https://favourite.example.org/api/v1/db#Instance
-type FavouriteDBInstanceParameters struct {
-
- // We're still working on a standard for naming external resources. See
- // https://github.com/crossplane/crossplane/issues/624 for context.
-
- // Name of this instance.
- Name string `json:"name"`
-
- // Note that fanciness_level becomes fancinessLevel below. Kubernetes API
- // conventions trump cloud provider fidelity.
-
- // FancinessLevel specifies exactly how fancy this instance is.
- FancinessLevel int `json:"fancinessLevel"`
-
- // Version specifies what version of FancySQL this instance will run.
- // +optional
- Version *string `json:"version,omitempty"`
-}
-
-// A FavouriteDBInstanceSpec defines the desired state of a FavouriteDBInstance.
-type FavouriteDBInstanceSpec struct {
- runtimev1alpha1.ResourceSpec `json:",inline"`
- ForProvider FavouriteDBInstanceParameters `json:"forProvider"`
-}
-
-// A FavouriteDBInstanceStatus represents the observed state of a
-// FavouriteDBInstance.
-type FavouriteDBInstanceStatus struct {
- runtimev1alpha1.ResourceStatus `json:",inline"`
-
- // Note that we add the three "output only" fields here in the status,
- // instead of the parameters. We want this representation to be high
- // fidelity just like the parameters.
-
- // ID of this instance.
- ID int `json:"id,omitempty"`
-
- // Status of this instance.
- Status string `json:"status,omitempty"`
-
- // Hostname of this instance.
- Hostname string `json:"hostname,omitempty"`
-}
-
-// A FavouriteDBInstance is a managed resource that represents a Favourite DB
-// instance.
-// +kubebuilder:subresource:status
-type FavouriteDBInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FavouriteDBInstanceSpec `json:"spec"`
- Status FavouriteDBInstanceStatus `json:"status,omitempty"`
-}
-```
-
-Note that Crossplane uses the GoDoc strings of API kinds to generate user facing
-API documentation. __Document all fields__ and prefer GoDoc that assumes the
-reader is running `kubectl explain`, or reading an API reference, not reading
-the code. Refer to the [Managed Resource API Patterns] one pager for more detail
-on authoring high fidelity managed resources.
-
-### Provider Kinds
-
-You'll typically only need to add a new Provider kind if you're creating an
-infrastructure provider that adds support for a new infrastructure provider.
-
-Providers must:
-
-* Be named exactly `ProviderConfig`.
-* Embed a [`ProviderSpec`] struct in their `Spec` struct.
-* Use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-The Favourite Cloud `ProviderConfig` would look as follows. Note that the cloud to
-which it belongs should be indicated by its API group, i.e. its API Version
-would be `favouritecloud.crossplane.io/v1alpha1` or similar.
-
-```go
-// A ProviderSpec defines the desired state of a Provider.
-type ProviderSpec struct {
- runtimev1alpha1.ProviderSpec `json:",inline"`
-
- // Information required outside of the Secret referenced in the embedded
- // runtimev1alpha1.ProviderSpec that is required to authenticate to the provider.
- // ProjectID is used as an example here.
- ProjectID string `json:"projectID"`
-}
-
-// A Provider configures a Favourite Cloud 'provider', i.e. a connection to a
-// particular Favourite Cloud project using a particular Favourite Cloud service
-// account.
-type Provider struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec ProviderSpec `json:"spec"`
-}
-```
-
-### Finishing Touches
-
-At this point we've defined the managed resource necessary to start
-building controllers. Before moving on to the controllers:
-
-* Add any kubebuilder [comment markers] that may be useful for your resource.
- Comment markers can be used to validate input, or add additional columns to
- the standard `kubectl get` output, among other things.
-* Run `make reviewable` to generate Custom Resource Definitions and additional
- helper methods for your new resource kinds.
-* Make sure any package documentation (i.e. `// Package v1alpha1...` GoDoc,
- including package level comment markers) are in a file named `doc.go`.
- kubebuilder adds them to `groupversion_info.go`, but several code generation
- tools only check `doc.go`.
-
-Finally, add convenience [`GroupVersionKind`] variables for each new resource
-kind. These are typically added to either `register.go` or
-`groupversion_info.go` depending on which version of kubebuilder scaffolded the
-API type:
-
-```go
-// FavouriteDBInstance type metadata.
-var (
- FavouriteDBInstanceKind = reflect.TypeOf(FavouriteDBInstance{}).Name()
- FavouriteDBInstanceKindAPIVersion = FavouriteDBInstanceKind + "." + GroupVersion.String()
- FavouriteDBInstanceGroupVersionKind = GroupVersion.WithKind(FavouriteDBInstanceKind)
-)
-```
-
-Consider opening a draft pull request and asking a Crossplane maintainer for
-review before you start work on the controller!
-
-## Adding Controllers
-
-Crossplane controllers, like those scaffolded by kubebuilder, are built around
-the [controller-runtime] library. controller-runtime flavoured controllers
-encapsulate most of their domain-specific logic in a [`reconcile.Reconciler`]
-implementation. Most Crossplane controllers are one of the three kinds mentioned
-under [What Makes a Crossplane Managed Service]. Each of these controller kinds
-are similar enough across implementations that [crossplane-runtime] provides
-'default' reconcilers. These reconcilers encode what the Crossplane community
-has learned about managing external systems and narrow the problem space from
-reconciling a Kubernetes resource kind with an arbitrary system down to
-Crossplane-specific tasks.
-
-crossplane-runtime provides the following `reconcile.Reconcilers`:
-
-* The [`managed.Reconciler`] reconciles managed resources with external systems
- by instantiating a client of the external API and using it to create, update,
- or delete the external resource as necessary.
-
-Crossplane controllers typically differ sufficiently from those scaffolded by
-kubebuilder that there is little value in using kubebuilder to generate a
-controller scaffold.
-
-### Managed Resource Controllers
-
-Managed resource controllers should use [`managed.NewReconciler`] to wrap a
-managed-resource specific implementation of [`managed.ExternalConnecter`]. Parts
-of `managed.Reconciler`'s behaviour is customisable; refer to the
-[`managed.NewReconciler`] GoDoc for a list of options. The following is an
-example controller for the `FavouriteDBInstance` managed resource we defined
-earlier:
-
-```go
-import (
- "context"
- "fmt"
- "strings"
-
- "github.com/pkg/errors"
- corev1 "k8s.io/api/core/v1"
- "k8s.io/apimachinery/pkg/types"
- ctrl "sigs.k8s.io/controller-runtime"
- "sigs.k8s.io/controller-runtime/pkg/client"
-
- // An API client of the hypothetical FavouriteDB service.
- "github.com/fcp-sdk/v1/services/database"
-
- runtimev1alpha1 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
- "github.com/crossplane/crossplane-runtime/pkg/meta"
- "github.com/crossplane/crossplane-runtime/pkg/resource"
- "github.com/crossplane/crossplane-runtime/pkg/reconciler/managed"
-
- "github.com/crossplane/provider-fcp/apis/database/v1alpha3"
- fcpv1alpha3 "github.com/crossplane/provider-fcp/apis/v1alpha3"
-)
-
-type FavouriteDBInstanceController struct{}
-
-// SetupWithManager instantiates a new controller using a managed.Reconciler
-// configured to reconcile FavouriteDBInstances using an ExternalClient produced by
-// connecter, which satisfies the ExternalConnecter interface.
-func (c *FavouriteDBInstanceController) SetupWithManager(mgr ctrl.Manager) error {
- return ctrl.NewControllerManagedBy(mgr).
- Named(strings.ToLower(fmt.Sprintf("%s.%s", v1alpha3.FavouriteDBInstanceKind, v1alpha3.Group))).
- For(&v1alpha3.FavouriteDBInstance{}).
- Complete(managed.NewReconciler(mgr,
- resource.ManagedKind(v1alpha3.FavouriteDBInstanceGroupVersionKind),
- managed.WithExternalConnecter(&connecter{client: mgr.GetClient()})))
-}
-
-// Connecter satisfies the resource.ExternalConnecter interface.
-type connecter struct{ client client.Client }
-
-// Connect to the supplied resource.Managed (presumed to be a
-// FavouriteDBInstance) by using the Provider it references to create a new
-// database client.
-func (c *connecter) Connect(ctx context.Context, mg resource.Managed) (managed.ExternalClient, error) {
- // Assert that resource.Managed we were passed in fact contains a
- // FavouriteDBInstance. We told NewControllerManagedBy that this was a
- // controller For FavouriteDBInstance, so something would have to go
- // horribly wrong for us to encounter another type.
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return nil, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Get the Provider referenced by the FavouriteDBInstance.
- p := &fcpv1alpha3.Provider{}
- if err := c.client.Get(ctx, meta.NamespacedNameOf(i.Spec.ProviderReference), p); err != nil {
- return nil, errors.Wrap(err, "cannot get Provider")
- }
-
- // Get the Secret referenced by the Provider.
- s := &corev1.Secret{}
- n := types.NamespacedName{Namespace: p.Namespace, Name: p.Spec.Secret.Name}
- if err := c.client.Get(ctx, n, s); err != nil {
- return nil, errors.Wrap(err, "cannot get Provider secret")
- }
-
- // Create and return a new database client using the credentials read from
- // our Provider's Secret.
- client, err := database.NewClient(ctx, s.Data[p.Spec.Secret.Key])
- return &external{client: client}, errors.Wrap(err, "cannot create client")
-}
-
-// External satisfies the resource.ExternalClient interface.
-type external struct{ client database.Client }
-
-// Observe the existing external resource, if any. The managed.Reconciler
-// calls Observe in order to determine whether an external resource needs to be
-// created, updated, or deleted.
-func (e *external) Observe(ctx context.Context, mg resource.Managed) (managed.ExternalObservation, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalObservation{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Use our FavouriteDB API client to get an up to date view of the external
- // resource.
- existing, err := e.client.GetInstance(ctx, i.Spec.Name)
-
- // If we encounter an error indicating the external resource does not exist
- // we want to let the managed.Reconciler know so it can create it.
- if database.IsNotFound(err) {
- return managed.ExternalObservation{ResourceExists: false}, nil
- }
-
- // Any other errors are wrapped (as is good Go practice) and returned to the
- // managed.Reconciler. It will update the "Synced" status condition
- // of the managed resource to reflect that the most recent reconcile failed
- // and ensure the reconcile is reattempted after a brief wait.
- if err != nil {
- return managed.ExternalObservation{}, errors.Wrap(err, "cannot get instance")
- }
-
- // The external resource exists. Copy any output-only fields to their
- // corresponding entries in our status field.
- i.Status.Status = existing.GetStatus()
- i.Status.Hostname = existing.GetHostname()
- i.Status.ID = existing.GetID()
-
- // Update our "Ready" status condition to reflect the status of the external
- // resource. Most managed resources use the below well known reasons that
- // the "Ready" status may be true or false, but managed resource authors
- // are welcome to define and use their own.
- switch i.Status.Status {
- case database.StatusOnline:
- resource.SetBindable(i)
- i.SetConditions(runtimev1alpha1.Available())
- case database.StatusCreating:
- i.SetConditions(runtimev1alpha1.Creating())
- case database.StatusDeleting:
- i.SetConditions(runtimev1alpha1.Deleting())
- }
-
- // Finally, we report what we know about the external resource. In this
- // hypothetical case FancinessLevel is the only field that can be updated
- // after creation time, so the resource does not need to be updated if
- // the actual fanciness level matches our desired fanciness level. Any
- // ConnectionDetails we return will be published to the managed resource's
- // connection secret if it specified one.
- o := managed.ExternalObservation{
- ResourceExists: true,
- ResourceUpToDate: existing.GetFancinessLevel == i.Spec.FancinessLevel,
- ConnectionDetails: managed.ConnectionDetails{
- runtimev1alpha1.ResourceCredentialsSecretUserKey: []byte(existing.GetUsername()),
- runtimev1alpha1.ResourceCredentialsSecretEndpointKey: []byte(existing.GetHostname()),
- },
- }
-
- return o, nil
-}
-
-// Create a new external resource based on the specification of our managed
-// resource. managed.Reconciler only calls Create if Observe reported
-// that the external resource did not exist.
-func (e *external) Create(ctx context.Context, mg resource.Managed) (managed.ExternalCreation, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalCreation{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
- // Indicate that we're about to create the instance. Remember ExternalClient
- // authors can use a bespoke condition reason here in cases where Creating
- // doesn't make sense.
- i.SetConditions(runtimev1alpha1.Creating())
-
- // Create must return any connection details that are set or returned only
- // at creation time. The managed.Reconciler will merge any details
- // with those returned during the Observe phase.
- password := database.GeneratePassword()
- cd := managed.ConnectionDetails{runtimev1alpha1.ResourceCredentialsSecretPasswordKey: []byte(password)}
-
- // Create a new instance.
- new := database.Instance{Name: i.Name, FancinessLevel: i.FancinessLevel, Version: i.Version}
- err := e.client.CreateInstance(ctx, new, password)
-
- // Note that we use resource.Ignore to squash any error that indicates the
- // external resource already exists. Create implementations must not return
- // an error if asked to create a resource that already exists. Real managed
- // resource controllers are advised to avoid unintentially 'adoptign' an
- // existing, unrelated external resource, per
- // https://github.com/crossplane/crossplane-runtime/issues/27
- return managed.ExternalCreation{ConnectionDetails: cd}, errors.Wrap(resource.Ignore(database.IsExists, err), "cannot create instance")
-}
-
-// Update the existing external resource to match the specifications of our
-// managed resource. managed.Reconciler only calls Update if Observe
-// reported that the external resource was not up to date.
-func (e *external) Update(ctx context.Context, mg resource.Managed) (managed.ExternalUpdate, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalUpdate{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Recall that FancinessLevel is the only field that we _can_ update.
- new := database.Instance{Name: i.Name, FancinessLevel: i.FancinessLevel}
- err := e.client.UpdateInstance(ctx, new)
- return managed.ExternalUpdate{}, errors.Wrap(err, "cannot update instance")
-}
-
-// Delete the external resource. managed.Reconciler only calls Delete
-// when a managed resource with the 'Delete' deletion policy (the default) has
-// been deleted.
-func (e *external) Delete(ctx context.Context, mg resource.Managed) error {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return errors.New("managed resource is not a FavouriteDBInstance")
- }
- // Indicate that we're about to delete the instance.
- i.SetConditions(runtimev1alpha1.Deleting())
-
- // Delete the instance.
- err := e.client.DeleteInstance(ctx, i.Spec.Name)
-
- // Note that we use resource.Ignore to squash any error that indicates the
- // external resource does not exist. Delete implementations must not return
- // an error when asked to delete a non-existent external resource.
- return errors.Wrap(resource.Ignore(database.IsNotFound, err), "cannot delete instance")
-}
-```
-
-### Wrapping Up
-
-Once all your controllers are in place you'll want to test them. Note that most
-projects under the [crossplane org] [favor] table driven tests that use Go's
-standard library `testing` package over kubebuilder's Gingko based tests. Please
-do not add or proliferate Gingko based tests.
-
-Finally, don't forget to plumb any newly added resource kinds and controllers up
-to your controller manager. Simple providers may do this for each type within
-within `main()`, but most more complicated providers take an approach in which
-each package exposes an `AddToScheme` (for resource kinds) or `SetupWithManager`
-(for controllers) function that invokes the same function within its child
-packages, resulting in a `main.go` like:
-
-```go
-import (
- "time"
-
- "sigs.k8s.io/controller-runtime/pkg/client/config"
- "sigs.k8s.io/controller-runtime/pkg/manager"
- "sigs.k8s.io/controller-runtime/pkg/manager/signals"
-
- crossplaneapis "github.com/crossplane/crossplane/apis"
-
- fcpapis "github.com/crossplane/provider-fcp/apis"
- "github.com/crossplane/provider-fcp/pkg/controller"
-)
-
-func main() {
- cfg, err := config.GetConfig()
- if err != nil {
- panic(err)
- }
-
- mgr, err := manager.New(cfg, manager.Options{SyncPeriod: 1 * time.Hour})
- if err != nil {
- panic(err)
- }
-
- if err := crossplaneapis.AddToScheme(mgr.GetScheme()); err != nil {
- panic(err)
- }
-
- if err := fcpapis.AddToScheme(mgr.GetScheme()); err != nil {
- panic(err)
- }
-
- if err := controller.SetupWithManager(mgr); err != nil {
- panic(err)
- }
-
- panic(mgr.Start(signals.SetupSignalHandler()))
-}
-```
-
-## In Review
-
-In this guide we walked through the process of defining the resource kinds and
-controllers necessary to build support for new managed infrastructure; possibly
-even a completely new infrastructure provider. Please do not hesitate to [reach
-out] to the Crossplane maintainers and community for help designing and
-implementing support for new managed services. We would highly value any
-feedback you may have about the development process!
-
-
-
-[TBS Episode 18]: https://www.youtube.com/watch?v=rvQ8N0u3rkE&t=7s
-[What Makes a Crossplane Infrastructure Resource]: #what-makes-a-crossplane-infrastructure-resource
-[managed resource]: ../introduction/managed-resources.md
-[`CloudMemorystoreInstance`]: https://github.com/crossplane/provider-gcp/blob/85a6ed3c669a021f1d61be51b2cbe2714b0bc70b/apis/cache/v1beta1/cloudmemorystore_instance_types.go#L184
-[`ProviderConfig`]: https://github.com/crossplane/provider-gcp/blob/be5aaf6/apis/v1beta1/providerconfig_types.go#L39
-[watching the API server]: https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
-[controller-runtime]: https://github.com/kubernetes-sigs/controller-runtime
-[crossplane-runtime]: https://github.com/crossplane/crossplane-runtime/
-[golden path]: https://charity.wtf/2018/12/02/software-sprawl-the-golden-path-and-scaling-teams-with-agency/
-[API Conventions]: https://github.com/kubernetes/community/blob/c6e1e89a/contributors/devel/sig-architecture/api-conventions.md
-[kubebuilder book]: https://book.kubebuilder.io/
-[resources]: https://kubebuilder.io/cronjob-tutorial/gvks.html#kinds-and-resources
-[kinds]: https://kubebuilder.io/cronjob-tutorial/gvks.html#kinds-and-resources
-[objects]: https://kubernetes.io/docs/concepts/#kubernetes-objects
-[comment marker]: https://kubebuilder.io/reference/markers.html
-[comment markers]: https://kubebuilder.io/reference/markers.html
-[`resource.Managed`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/resource#Managed
-[`managed.Reconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#Reconciler
-[`managed.NewReconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#NewReconciler
-[`managed.ExternalConnecter`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalConnecter
-[`managed.ExternalClient`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalClient
-[`ResourceSpec`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ResourceSpec
-[`ResourceStatus`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ResourceStatus
-[`ProviderSpec`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ProviderSpec
-['managed.ExternalConnecter`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalConnecter
-[opening a Crossplane issue]: https://github.com/crossplane/crossplane/issues/new/choose
-[`GroupVersionKind`]: https://godoc.org/k8s.io/apimachinery/pkg/runtime/schema#GroupVersionKind
-[`reconcile.Reconciler`]: https://godoc.org/sigs.k8s.io/controller-runtime/pkg/reconcile#Reconciler
-[favor]: https://github.com/crossplane/crossplane/issues/452
-[reach out]: https://github.com/crossplane/crossplane#get-involved
-[crossplane org]: https://github.com/crossplane
-[`angryjet`]: https://github.com/crossplane/crossplane-tools
-[Managed Resource API Patterns]: ../design/one-pager-managed-resource-api-design.md
-[Crossplane CLI]: https://github.com/crossplane/crossplane-cli#quick-start-stacks
-[`angryjet` documentation]: https://github.com/crossplane/crossplane-tools/blob/master/README.md
diff --git a/docs/v0.13/faqs/faqs.md b/docs/v0.13/faqs/faqs.md
deleted file mode 100644
index d3128cb4..00000000
--- a/docs/v0.13/faqs/faqs.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: FAQ
-toc: true
-weight: 1200
----
-
-# Frequently Asked Questions (FAQs)
-
-### Where did the name Crossplane come from?
-
-Crossplane is the fusing of cross-cloud control plane. We wanted to use a noun
-that refers to the entity responsible for connecting different cloud providers
-and acts as control plane across them. Cross implies “cross-cloud” and “plane”
-brings in “control plane”.
-
-### What's up with popsicle?
-
-We believe in a multi-flavor cloud.
-
-### Related Projects
-See [Related Projects].
-
-[Related Projects]: related_projects.md
diff --git a/docs/v0.13/faqs/related_projects.md b/docs/v0.13/faqs/related_projects.md
deleted file mode 100644
index 87f652fc..00000000
--- a/docs/v0.13/faqs/related_projects.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: Related Projects
-toc: true
-weight: 1201
-indent: true
----
-
-# Related Projects
-
-While there are many projects that address similar issues, none of them
-encapsulate the full use case that Crossplane addresses. This list is not
-exhaustive and is not meant to provide a deep analysis of the following
-projects, but instead to motivate why Crossplane was created.
-
-## Open Service Broker and Service Catalog
-
-The [Open Service Broker] and the [Kubernetes Service Catalog] are able to
-dynamically provision cloud services from Kubernetes. As a result it shares
-similar goals with Crossplane. However, service broker does not have the
-ability to define, compose, and publish your own infrastructure resources to
-the Kubernetes API in a no-code way. Crossplane goes further by enabling
-infrastructure operators to hide infrastructure complexity and include policy
-guardrails, with a team-centric approach and a strong separation of concerns,
-so applications can easily and safely consume the infrastructure they need,
-using any tool that works with the Kubernetes API. Solutions like the [GCP
-implementation of Open Service Broker][GCP OSB] have been deprecated in favor
-of a more Kubernetes-native solution, but one that is Google-specific and
-closed source.
-
-## GCP Config Connector
-
-The [GCP Config Connector] is the GCP replacement for Open Service Broker, and
-implements a set of Kubernetes controllers that are able to provision managed
-services in GCP. It defines a set of CRDs for managed services like CloudSQL,
-and controllers that can provision them via their cloud APIs. It is similar to
-Crossplane in that it can provision managed services in GCP. Crossplane goes
-further by enabling you to provision managed services from any cloud
-provider and the ability to define, compose, and publish your own
-infrastructure resources in a no-code way. Crossplane supports a team-centric
-approach with a strong separation of concerns, that enables applications to
-easily and safely consume the infrastructure they need, using any tool that
-works with the Kubernetes API. GCP Config Connector is closed-source.
-
-## AWS Service Operator
-
-The [AWS Service Operator] is a recent project that implements a set of
-Kubernetes controllers that are able to provision managed services in AWS. It
-defines a set of CRDs for managed services like DynamoDB, and controllers that
-can provision them via AWS CloudFormation. It is similar to Crossplane in that
-it can provision managed services in AWS. Crossplane goes further by
-enabling you to provision managed services from any cloud provider and the
-ability to define, compose, and publish your own infrastructure API types in
-Kubernetes in a no-code way. Crossplane supports a team-centric approach with a
-strong separation of concerns, that enables applications to easily and safely
-consume the infrastructure they need, using any tool that works with the
-Kubernetes API.
-
-## AWS CloudFormation, GCP Deployment Manager, and Others
-
-These products offer a declarative model for deploying and provisioning
-infrastructure in each of the respective cloud providers. They only work for
-one cloud provider, are generally closed source, and offer little or no
-extensibility points, let alone being able to extend the Kubernetes API to
-provide your own infrastructure abstractions in a no-code way. We have
-considered using some of these products as a way to implement resource
-controllers in Crossplane. These projects use an Infrastructure as Code
-approach to management, while Crossplane offers an API-driven control plane.
-
-## Terraform and Pulumi
-
-[Terraform] and [Pulumi] are tools for provisioning infrastructure across cloud
-providers that offer a declarative configuration language with support for
-templating, composability, referential integrity and dependency management.
-Terraform can declaratively manage any compatible API and perform changes when
-the tool is run by a human or in a deployment pipeline. Terraform is an
-Infrastructure as Code tool, while Crossplane offers an API-driven control
-plane.
-
-
-
-[Open Service Broker]: https://www.openservicebrokerapi.org/
-[Kubernetes Service Catalog]: https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/
-[GCP OSB]: https://cloud.google.com/kubernetes-engine/docs/concepts/google-cloud-platform-service-broker
-[GCP Config Connector]: https://cloud.google.com/config-connector/docs/overview
-[AWS Service Operator]: https://github.com/awslabs/aws-service-operator
-[Terraform]: https://www.terraform.io/
-[Pulumi]: https://www.pulumi.com/
diff --git a/docs/v0.13/getting-started/compose-infrastructure.md b/docs/v0.13/getting-started/compose-infrastructure.md
deleted file mode 100644
index 63694a22..00000000
--- a/docs/v0.13/getting-started/compose-infrastructure.md
+++ /dev/null
@@ -1,391 +0,0 @@
----
-title: Compose Infrastructure
-toc: true
-weight: 4
-indent: true
----
-
-# Compose Infrastructure
-
-In the [last section] we learned that Crossplane can be extended by installing
-_providers_, which add support for managed resources. A managed resource is a
-Kubernetes custom resource that offers a high fidelity representation of an
-infrastructure primitive, like an SQL instance or a firewall rule. Crossplane
-goes beyond simply modelling infrastructure primitives as custom resources - it
-enables you to define new custom resources with schemas of your choosing. These
-resources are composed of managed resources, allowing you to define and offer
-resources that group and abstract infrastructure primitives. We call these
-"composite resources" (XRs).
-
-XRs are always cluster scoped - they exist outside of any namespace. This allows
-an XR to represent infrastructure that might be consumed from several different
-namespaces. This is often true for VPC networks - an infrastructure operator may
-wish to define a VPC network XR and an SQL instance XR, only the latter of which
-may be managed by application operators. The application operators are
-restricted to their team's namespace, but their SQL instances should all be
-attached to the VPC network that the infrastructure operator manages. Crossplane
-enables scenarios like this by allowing the infrastructure operator to offer
-their application operators a _composite resource claim_ (XRC). An XRC is a
-namespaced proxy for an XR; the schema of an XRC is identical to that of its
-corresponding XR. When an application operator creates an XRC, a corresponding
-backing XR is created automatically.
-
-We use two special Crossplane resources to define and configure new XRs and
-XRCs:
-
-- A `CompositeResourceDefinition` (XRD) _defines_ a new kind of composite
- resource, including its schema. An XRD may optionally _offer_ a claim.
-- A `Composition` specifies which resources a composite resource will be
- composed of, and how they should be configured. You can create multiple
- `Composition` options for each composite resource.
-
-XRDs and Compositions may be packaged and installed as a _configuration_. A
-configuration is a [package] of composition configuration that can easily be
-installed to Crossplane by creating a declarative `Configuration` resource, or
-by using `kubectl crossplane install configuration`. In the examples below we
-will install a configuration that defines a new `CompositePostgreSQLInstance` XR
-that takes a single `storageGB` parameter, and creates a connection `Secret`
-with keys for `username`, `password`, and `endpoint`. A `Configuration` exists
-for each provider that can satisfy a `PostgreSQLInstance`. Let's get started!
-
-## Configure and Claim Your Infrastructure
-
-We will now install a `Configuration` that:
-
-- Defines a `CompositePostgreSQLInstance` XR.
-- Offers a `PostgreSQLInstance` claim (XRC) for said XR.
-- Creates a `Composition` that can satisfy our XR.
-
-
-
-> Note that this configuration will create an RDS instance using your default
-> VPC, which may or may not allow connections from the internet depending on how
-> it is configured. Select the AWS (New VPC) configuration if you wish to create
-> an RDS instance that will allow traffic from the internet.
-
-```console
-kubectl crossplane install configuration crossplane/getting-started-with-aws:v0.13
-```
-
-
-
-
-> Note that this configuration for AWS also includes several networking managed
-> resources that are required to provision a publicly available PostgreSQL
-> instance. Composition enables scenarios such as this, as well as far more
-> complex ones. See the [composition] documentation for more information.
-
-```console
-kubectl crossplane install configuration crossplane/getting-started-with-aws-with-vpc:v0.13
-```
-
-
-
-Crossplane should now be configured to allow us to create a `PostgreSQLInstance`
-claim! You can make sure your `Configuration` installed successfully by running:
-
-```console
-kubectl describe configuration
-```
-
-Make sure you've [setup] a `ProviderConfig` named `default` for your chosen
-provider, then create your XRC to provision a PostgreSQL instance and all the
-supporting infrastructure (VPCs, firewall rules, resource groups, etc) that it
-may need!
-
-
-
-After creating the `PostgreSQLInstance` Crossplane will begin provisioning a
-database instance on your provider of choice. Once provisioning is complete, you
-should see `READY: True` in the output when you run:
-
-```console
-kubectl get postgresqlinstance my-db
-```
-
-> Note: while waiting for the `PostgreSQLInstance` to become ready, you
-> may want to look at other resources in your cluster. The following commands
-> will allow you to view groups of Crossplane resources:
->
-> - `kubectl get claim`: get all resources of all claim kinds, like `PostgreSQLInstance`.
-> - `kubectl get composite`: get all resources that are of composite kind, like `CompositePostgreSQLInstance`.
-> - `kubectl get managed`: get all resources that represent a unit of external
-> infrastructure.
-> - `kubectl get `: get all resources related to ``.
-> - `kubectl get crossplane`: get all resources related to Crossplane.
-
-Try the following command to watch your provisioned resources become ready:
-
-```console
-kubectl get crossplane -l crossplane.io/claim-name=my-db
-```
-
-Once your `PostgreSQLInstance` is ready, you should see a `Secret` in the `default`
-namespace named `db-conn` that contains keys that we defined in XRD. If they were
-filled by the composition, then they should appear:
-
-```console
-$ kubectl describe secrets db-conn
-Name: db-conn
-Namespace: default
-...
-
-Type: connection.crossplane.io/v1alpha1
-
-Data
-====
-password: 27 bytes
-port: 4 bytes
-username: 25 bytes
-endpoint: 45 bytes
-```
-
-## Consume Your Infrastructure
-
-Because connection secrets are written as a Kubernetes `Secret` they can easily
-be consumed by Kubernetes primitives. The most basic building block in
-Kubernetes is the `Pod`. Let's define a `Pod` that will show that we are able to
-connect to our newly provisioned database.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: see-db
- namespace: default
-spec:
- containers:
- - name: see-db
- image: postgres:9.6
- command: ['psql']
- args: ['-c', 'SELECT current_database();']
- env:
- - name: PGDATABASE
- value: postgres
- - name: PGHOST
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: endpoint
- - name: PGUSER
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: username
- - name: PGPASSWORD
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: password
- - name: PGPORT
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: port
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/compose/pod.yaml
-```
-
-This `Pod` simply connects to a PostgreSQL database and prints its name, so you
-should see the following output (or similar) after creating it if you run
-`kubectl logs see-db`:
-
-```SQL
- current_database
-------------------
- postgres
-(1 row)
-```
-
-## Clean Up
-
-To clean up the `Pod`, run:
-
-```console
-kubectl delete pod see-db
-```
-
-To clean up the infrastructure that was provisioned, you can delete the
-`PostgreSQLInstance` XRC:
-
-```console
-kubectl delete postgresqlinstance my-db
-```
-
-> Don't clean up your `Configuration` just yet if you plan to continue on to the
-> next section of the guide! We'll use them again when we deploy an OAM
-> application.
-
-## Next Steps
-
-Now you have seen how to provision and publish more complex infrastructure
-setups. In the [next section] you will learn how to consume infrastructure
-alongside your [OAM] application manifests.
-
-
-
-[last section]: provision-infrastructure.md
-[composition]: ../introduction/composition.md
-[package]: ../introduction/packages.md
-[setup]: install-configure.md
-[next section]: run-applications.md
-[OAM]: https://oam.dev/
diff --git a/docs/v0.13/getting-started/install-configure.md b/docs/v0.13/getting-started/install-configure.md
deleted file mode 100644
index a2cd6fbd..00000000
--- a/docs/v0.13/getting-started/install-configure.md
+++ /dev/null
@@ -1,394 +0,0 @@
----
-title: Install & Configure
-toc: true
-weight: 2
-indent: true
----
-
-# Install & Configure Crossplane
-
-Crossplane can be easily installed into any existing Kubernetes cluster using
-the regularly published Helm chart. The Helm chart contains all the custom
-resources and controllers needed to deploy and configure Crossplane.
-
-See [Install] and [Configure] docs for installing alternate versions and more
-detailed instructions.
-
-## Get a Kubernetes Cluster
-
-
-For macOS / Linux use the following:
-
-* [Kubernetes cluster]
- * [Kind]
- * [Minikube], minimum version `v0.28+`
- * etc.
-
-* [Helm], minimum version `v3.0.0+`.
-
-
-
-For Windows use the following:
-
-* [Kubernetes cluster]
- * [Kind]
- * [Minikube], minimum version `v0.28+`
- * etc.
-
-* [Helm], minimum version `v3.0.0+`.
-
-
-Use Helm 3 to install the latest official `alpha` release of Crossplane, suitable for community use and testing:
-
-> OAM is available only for 1.16 and later versions of Kubernetes.
-
-```console
-kubectl create namespace crossplane-system
-
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-
-# Kubernetes 1.16 and later versions
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane --set alpha.oam.enabled=true
-```
-
-```console
-# Kubernetes 1.15 and earlier versions
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-
-
-## Check Crossplane Status
-
-```console
-helm list -n crossplane-system
-
-kubectl get all -n crossplane-system
-```
-
-## Install Crossplane CLI
-
-The Crossplane CLI extends `kubectl` with functionality to build, push, and install [Crossplane packages]:
-
-```console
-curl -sL https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/install.sh | sh
-```
-
-## Select Provider
-
-Install and configure a provider for Crossplane to use for infrastructure provisioning:
-
-
-### Install AWS Provider
-
-```console
-kubectl crossplane install provider crossplane/provider-aws:v0.12.0
-```
-
-### Get AWS Account Keyfile
-
-Using an AWS account with permissions to manage RDS databases:
-
-```console
-AWS_PROFILE=default && echo -e "[default]\naws_access_key_id = $(aws configure get aws_access_key_id --profile $AWS_PROFILE)\naws_secret_access_key = $(aws configure get aws_secret_access_key --profile $AWS_PROFILE)" > creds.conf
-```
-
-### Create a Provider Secret
-
-```console
-kubectl create secret generic aws-creds -n crossplane-system --from-file=key=./creds.conf
-```
-
-### Configure the Provider
-
-We will create the following `ProviderConfig` object to configure credentials for AWS
-Provider:
-
-```yaml
-apiVersion: aws.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: default
-spec:
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: aws-creds
- key: key
-```
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/master/docs/snippets/configure/aws/providerconfig.yaml
-```
-
-
-
-
-### Install GCP Provider
-
-```console
-kubectl crossplane install provider crossplane/provider-gcp:v0.12.0
-```
-
-### Get GCP Account Keyfile
-
-```console
-# replace this with your own gcp project id and the name of the service account
-# that will be created.
-PROJECT_ID=my-project
-NEW_SA_NAME=test-service-account-name
-
-# create service account
-SA="${NEW_SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
-gcloud iam service-accounts create $NEW_SA_NAME --project $PROJECT_ID
-
-# enable cloud API
-SERVICE="sqladmin.googleapis.com"
-gcloud services enable $SERVICE --project $PROJECT_ID
-
-# grant access to cloud API
-ROLE="roles/cloudsql.admin"
-gcloud projects add-iam-policy-binding --role="$ROLE" $PROJECT_ID --member "serviceAccount:$SA"
-
-# create service account keyfile
-gcloud iam service-accounts keys create creds.json --project $PROJECT_ID --iam-account $SA
-```
-
-### Create a Provider Secret
-
-```console
-kubectl create secret generic gcp-creds -n crossplane-system --from-file=key=./creds.json
-```
-
-### Configure the Provider
-
-We will create the following `ProviderConfig` object to configure credentials for GCP
-Provider:
-
-```console
-# replace this with your own gcp project id
-PROJECT_ID=my-project
-echo "apiVersion: gcp.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: default
-spec:
- projectID: ${PROJECT_ID}
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: gcp-creds
- key: key" | kubectl apply -f -
-```
-
-
-
-
-### Install Azure Provider
-
-```console
-kubectl crossplane install provider crossplane/provider-azure:v0.12.0
-```
-
-### Get Azure Principal Keyfile
-
-```console
-# create service principal with Owner role
-az ad sp create-for-rbac --sdk-auth --role Owner > "creds.json"
-
-# we need to get the clientId from the json file to add Azure Active Directory
-# permissions.
-if which jq > /dev/null 2>&1; then
- AZURE_CLIENT_ID=$(jq -r ".clientId" < "./creds.json")
-else
- AZURE_CLIENT_ID=$(cat creds.json | grep clientId | cut -c 16-51)
-fi
-
-RW_ALL_APPS=1cda74f2-2616-4834-b122-5cb1b07f8a59
-RW_DIR_DATA=78c8a3c8-a07e-4b9e-af1b-b5ccab50a175
-AAD_GRAPH_API=00000002-0000-0000-c000-000000000000
-
-az ad app permission add --id "${AZURE_CLIENT_ID}" --api ${AAD_GRAPH_API} --api-permissions ${RW_ALL_APPS}=Role ${RW_DIR_DATA}=Role
-az ad app permission grant --id "${AZURE_CLIENT_ID}" --api ${AAD_GRAPH_API} --expires never > /dev/null
-az ad app permission admin-consent --id "${AZURE_CLIENT_ID}"
-```
-
-### Create a Provider Secret
-
-```console
-kubectl create secret generic azure-creds -n crossplane-system --from-file=key=./creds.json
-```
-
-### Configure the Provider
-
-We will create the following `ProviderConfig` object to configure credentials for
-Azure Provider:
-
-```yaml
-apiVersion: azure.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: default
-spec:
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: azure-creds
- key: key
-```
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/master/docs/snippets/configure/azure/providerconfig.yaml
-```
-
-
-
-
-### Install Alibaba Provider
-
-```console
-kubectl crossplane install provider crossplane/provider-alibaba:v0.3.0
-```
-
-### Create a Provider Secret
-
-```console
-# Replace and with your actual key id and key secret.
-kubectl create secret generic alibaba-creds --from-literal=accessKeyId= --from-literal=accessKeySecret= -n crossplane-system
-```
-
-### Configure the Provider
-
-We will create the following `ProviderConfig` object to configure credentials for
-Alibaba Provider:
-
-```yaml
-apiVersion: alibaba.crossplane.io/v1alpha1
-kind: ProviderConfig
-metadata:
- name: default
-spec:
- region: cn-beijing
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: alibaba-creds
- # "key" field does not have any effect right now but it has to be given.
- # See https://github.com/crossplane/crossplane-runtime/issues/215
- key: credentials
-```
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/master/docs/snippets/configure/alibaba/providerconfig.yaml
-```
-
-
-
-
-## Next Steps
-
-Now that you have a provider configured, you can [provision infrastructure].
-
-## More Info
-
-See [Install] and [Configure] docs for installing alternate versions and more
-detailed instructions.
-
-## Uninstall Provider
-
-Let's check whether there are any managed resources before deleting the provider.
-
-```console
-kubectl get managed
-```
-
-If there are any, please delete them first so you don't lose track of them.
-
-```console
-kubectl delete -f provider.yaml
-```
-
-## Uninstall Crossplane
-
-```console
-helm delete crossplane --namespace crossplane-system
-
-kubectl delete namespace crossplane-system
-```
-
-
-
-[provision infrastructure]: provision-infrastructure.md
-[Install]: ../reference/install.md
-[Configure]: ../reference/configure.md
-[Kubernetes cluster]: https://kubernetes.io/docs/setup/
-[Minikube]: https://kubernetes.io/docs/tasks/tools/install-minikube/
-[Helm]: https://docs.helm.sh/using_helm/
-[Kind]: https://kind.sigs.k8s.io/docs/user/quick-start/
-[Crossplane packages]: ../introduction/packages.md
diff --git a/docs/v0.13/getting-started/package-infrastructure.md b/docs/v0.13/getting-started/package-infrastructure.md
deleted file mode 100644
index 80c51b55..00000000
--- a/docs/v0.13/getting-started/package-infrastructure.md
+++ /dev/null
@@ -1,690 +0,0 @@
----
-title: Package Infrastructure
-toc: true
-weight: 6
-indent: true
----
-
-# Package Infrastructure
-
-In a [previous section] we learned that Crossplane can be configured with new
-composite resources (XRs) that are [composed] of other resources, allowing you
-to define and offer resources that group and abstract infrastructure primitives.
-We use two special Crossplane resources to define and configure new XRs and
-XRCs:
-
-- A `CompositeResourceDefinition` (XRD) _defines_ a new kind of composite
- resource, including its schema. An XRD may optionally _offer_ a claim.
-- A `Composition` specifies which resources a composite resource will be
- composed of, and how they should be configured. You can create multiple
- `Composition` options for each composite resource.
-
-XRDs and Compositions may be [packaged] as a _configuration_, that may easily be
-installed to Crossplane by creating a declarative `Configuration` resource, or
-by using `kubectl crossplane install configuration`. In the examples below we
-will build and push a configuration that defines a new
-`CompositePostgreSQLInstance` XR that takes a single `storageGB` parameter, and
-creates a connection `Secret` with keys for `username`, `password`, and
-`endpoint`.
-
-## Create a Configuration Directory
-
-Our configuration will consist of three files:
-
-* `crossplane.yaml` - Metadata about the configuration.
-* `definition.yaml` - The XRD.
-* `composition.yaml` - The Composition.
-
-Crossplane can create a configuration from any directory with a valid
-`crossplane.yaml` metadata file at its root, and one or more XRDs or
-Compositions. The directory structure does not matter, as long as the
-`crossplane.yaml` file is at the root. Note that a configuration need not
-contain one XRD and one composition - it could include only an XRD, only a
-composition, several compositions, or any combination thereof.
-
-Before we go any further, we must create a directory in which to build our
-configuration:
-
-```console
-mkdir crossplane-config
-cd crossplane-config
-```
-
-We'll create the aforementioned three files in this directory, then build them
-into a package.
-
-## Create CompositeResourceDefinition
-
-First we'll create a `CompositeResourceDefinition` (XRD) to define the schema of
-our `CompositePostgreSQLInstance` and its `PostgreSQLInstance` resource claim.
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: CompositeResourceDefinition
-metadata:
- name: compositepostgresqlinstances.database.example.org
-spec:
- claimNames:
- kind: PostgreSQLInstance
- plural: postgresqlinstances
- connectionSecretKeys:
- - username
- - password
- - endpoint
- - port
- crdSpecTemplate:
- group: database.example.org
- version: v1alpha1
- names:
- kind: CompositePostgreSQLInstance
- plural: compositepostgresqlinstances
- validation:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- parameters:
- type: object
- properties:
- storageGB:
- type: integer
- required:
- - storageGB
- required:
- - parameters
-```
-
-```console
-curl -OL https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/package/definition.yaml
-```
-
-> You might notice that the XRD we created specifies both "names" and "claim
-> names". This is because the composite resource it defines offers a composite
-> resource claim (XRC).
-
-## Create Compositions
-
-Now we'll specify which managed resources our `CompositePostgreSQLInstance` XR
-and its claim could be composed of, and how they should be configured. We do
-this by defining a `Composition` that can satisfy the XR we defined above. In
-this case, our `Composition` will specify how to provision a public PostgreSQL
-instance on the chosen provider.
-
-
-
-## Build and Push The Configuration
-
-Finally, we'll author our metadata file then build and push our configuration
-so that Crossplane users may install it.
-
-> Note that Crossplane pushes packages to an OCI registry - currently [Docker
-> Hub] by default. You may need to run `docker login` before you are able to
-> push a package.
-
-
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: getting-started-with-aws
- annotations:
- guide: quickstart
- provider: aws
- vpc: default
-```
-
-```console
-curl -OL https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/package/aws/crossplane.yaml
-
-# Set this to the Docker Hub username or OCI registry you wish to use.
-REG=my-package-repo
-
-kubectl crossplane build configuration
-kubectl crossplane push configuration ${REG}/getting-started-with-aws:v0.13
-```
-
-
-
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: getting-started-with-aws-with-vpc
- annotations:
- guide: quickstart
- provider: aws
- vpc: new
-```
-
-```console
-curl -OL https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/package/aws-with-vpc/crossplane.yaml
-
-# Set this to the Docker Hub username or OCI registry you wish to use.
-REG=my-package-repo
-
-kubectl crossplane build configuration
-kubectl crossplane push configuration ${REG}/getting-started-with-aws-with-vpc:v0.13
-```
-
-
-
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: getting-started-with-gcp
- annotations:
- guide: quickstart
- provider: gcp
-```
-
-```console
-curl -OL https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/package/gcp/crossplane.yaml
-
-# Set this to the Docker Hub username or OCI registry you wish to use.
-REG=my-package-repo
-
-kubectl crossplane build configuration
-kubectl crossplane push configuration ${REG}/getting-started-with-gcp:v0.13
-```
-
-
-
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: getting-started-with-azure
- annotations:
- guide: quickstart
- provider: azure
-```
-
-```console
-curl -OL https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/package/azure/crossplane.yaml
-
-# Set this to the Docker Hub username or OCI registry you wish to use.
-REG=my-package-repo
-
-kubectl crossplane build configuration
-kubectl crossplane push configuration ${REG}/getting-started-with-azure:v0.13
-```
-
-
-
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: getting-started-with-alibaba
- annotations:
- guide: quickstart
- provider: alibaba
-```
-
-```console
-curl -OL https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/package/alibaba/crossplane.yaml
-
-# Set this to the Docker Hub username or OCI registry you wish to use.
-REG=my-package-repo
-
-kubectl crossplane build configuration
-kubectl crossplane push configuration ${REG}/getting-started-with-alibaba:v0.13
-```
-
-
-
-
-That's it! You've now built and pushed your package. Take a look at the
-Crossplane [packages] documentation for more information about installing and
-working with packages.
-
-## Clean Up
-
-To clean up, you can simply delete your package directory:
-
-```console
-cd ..
-rm -rf crossplane-config
-```
-
-
-
-[previous section]: compose-infrastructure.md
-[composed]: ../introduction/composition.md
-[composition]: ../introduction/composition.md
-[Docker Hub]: https://hub.docker.com/
-[packages]: ../introduction/packages.md
-[packaged]: ../introduction/packages.md
diff --git a/docs/v0.13/getting-started/provision-infrastructure.md b/docs/v0.13/getting-started/provision-infrastructure.md
deleted file mode 100644
index 1c621dde..00000000
--- a/docs/v0.13/getting-started/provision-infrastructure.md
+++ /dev/null
@@ -1,257 +0,0 @@
----
-title: Provision Infrastructure
-toc: true
-weight: 3
-indent: true
----
-
-# Provision Infrastructure
-
-Crossplane allows you to provision infrastructure anywhere using the Kubernetes
-API. Once you have [installed a provider] and [configured your credentials], you
-can create any infrastructure currently supported by the provider. Let's start
-by provisioning a database on your provider of choice.
-
-Each provider below offers their own flavor of a managed database. When you
-install a provider it extends Crossplane by adding support for several "managed
-resources". A managed resource is a cluster-scoped Kubernetes custom resource
-that represents an infrastructure object, such as a database instance.
-
-
-
-The AWS provider supports provisioning an [RDS] instance via the `RDSInstance`
-managed resource it adds to Crossplane.
-
-```yaml
-apiVersion: database.aws.crossplane.io/v1beta1
-kind: RDSInstance
-metadata:
- name: rdspostgresql
-spec:
- forProvider:
- dbInstanceClass: db.t2.small
- masterUsername: masteruser
- allocatedStorage: 20
- engine: postgres
- engineVersion: "9.6"
- skipFinalSnapshotBeforeDeletion: true
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: aws-rdspostgresql-conn
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/provision/aws.yaml
-```
-
-Creating the above instance will cause Crossplane to provision an RDS instance
-on AWS. You can view the progress with the following command:
-
-```console
-kubectl get rdsinstance rdspostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can take a look at its connection secret that is referenced under `spec.writeConnectionSecretToRef`:
-
-```console
-kubectl describe secret aws-rdspostgresql-conn -n crossplane-system
-```
-
-You can then delete the `RDSInstance`:
-
-```console
-kubectl delete rdsinstance rdspostgresql
-```
-
-
-
-
-The GCP provider supports provisioning a [CloudSQL] instance with the
-`CloudSQLInstance` managed resource it adds to Crossplane.
-
-```yaml
-apiVersion: database.gcp.crossplane.io/v1beta1
-kind: CloudSQLInstance
-metadata:
- name: cloudsqlpostgresql
-spec:
- forProvider:
- databaseVersion: POSTGRES_9_6
- region: us-central1
- settings:
- tier: db-custom-1-3840
- dataDiskType: PD_SSD
- dataDiskSizeGb: 10
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: cloudsqlpostgresql-conn
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/provision/gcp.yaml
-```
-
-Creating the above instance will cause Crossplane to provision a CloudSQL
-instance on GCP. You can view the progress with the following command:
-
-```console
-kubectl get cloudsqlinstance cloudsqlpostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can take a look at its connection secret that is referenced under `spec.writeConnectionSecretToRef`:
-
-```console
-kubectl describe secret cloudsqlpostgresql-conn -n crossplane-system
-```
-
-You can then delete the `CloudSQLInstance`:
-
-```console
-kubectl delete cloudsqlinstance cloudsqlpostgresql
-```
-
-
-
-
-The Azure provider supports provisioning an [Azure Database for PostgreSQL]
-instance with the `PostgreSQLServer` managed resource it adds to Crossplane.
-
-> Note: provisioning an Azure Database for PostgreSQL requires the presence of a
-> [Resource Group] in your Azure account. We go ahead and provision a new
-> `ResourceGroup` here in case you do not already have a suitable one in your
-> account.
-
-```yaml
-apiVersion: azure.crossplane.io/v1alpha3
-kind: ResourceGroup
-metadata:
- name: sqlserverpostgresql-rg
-spec:
- location: West US 2
----
-apiVersion: database.azure.crossplane.io/v1beta1
-kind: PostgreSQLServer
-metadata:
- name: sqlserverpostgresql
-spec:
- forProvider:
- administratorLogin: myadmin
- resourceGroupNameRef:
- name: sqlserverpostgresql-rg
- location: West US 2
- sslEnforcement: Disabled
- version: "9.6"
- sku:
- tier: GeneralPurpose
- capacity: 2
- family: Gen5
- storageProfile:
- storageMB: 20480
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: sqlserverpostgresql-conn
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/provision/azure.yaml
-```
-
-Creating the above instance will cause Crossplane to provision a PostgreSQL
-database instance on Azure. You can view the progress with the following
-command:
-
-```console
-kubectl get postgresqlserver sqlserverpostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can take a look at its connection secret that is referenced under `spec.writeConnectionSecretToRef`:
-
-```console
-kubectl describe secret sqlserverpostgresql-conn -n crossplane-system
-```
-
-You can then delete the `PostgreSQLServer`:
-
-```console
-kubectl delete postgresqlserver sqlserverpostgresql
-kubectl delete resourcegroup sqlserverpostgresql-rg
-```
-
-
-
-
-The Alibaba provider supports provisioning an [ApsaraDB for RDS] instance with
-the `RDSInstance` managed resource it adds to Crossplane.
-
-```yaml
-apiVersion: database.alibaba.crossplane.io/v1alpha1
-kind: RDSInstance
-metadata:
- name: rdspostgresql
-spec:
- forProvider:
- engine: PostgreSQL
- engineVersion: "9.4"
- dbInstanceClass: rds.pg.s1.small
- dbInstanceStorageInGB: 20
- securityIPList: "0.0.0.0/0"
- masterUsername: "test123"
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: alibaba-rdspostgresql-conn
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/provision/alibaba.yaml
-```
-
-Creating the above instance will cause Crossplane to provision an RDS instance
-on Alibaba. You can view the progress with the following command:
-
-```console
-kubectl get rdsinstance rdspostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can take a look at its connection secret that is referenced under `spec.writeConnectionSecretToRef`:
-
-```console
-kubectl describe secret alibaba-rdspostgresql-conn -n crossplane-system
-```
-
-You can then delete the `RDSInstance`:
-
-```console
-kubectl delete rdsinstance rdspostgresql
-```
-
-
-
-
-## Next Steps
-
-Now that you have seen how to provision individual managed resources, let's take
-a look at how we can compose several managed resources into new resources with
-APIs of our choosing in the [next section].
-
-
-
-[installed a provider]: install-configure.md
-[configured your credentials]: install-configure.md
-[RDS]: https://aws.amazon.com/rds/
-[CloudSQL]: https://cloud.google.com/sql
-[Azure Database for PostgreSQL]: https://azure.microsoft.com/en-us/services/postgresql/
-[Resource Group]: https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal#what-is-a-resource-group
-[ApsaraDB for RDS]: https://www.alibabacloud.com/product/apsaradb-for-rds-postgresql
-[next section]: compose-infrastructure.md
diff --git a/docs/v0.13/getting-started/run-applications-dash.png b/docs/v0.13/getting-started/run-applications-dash.png
deleted file mode 100644
index 5390190b..00000000
Binary files a/docs/v0.13/getting-started/run-applications-dash.png and /dev/null differ
diff --git a/docs/v0.13/getting-started/run-applications-diagram.jpg b/docs/v0.13/getting-started/run-applications-diagram.jpg
deleted file mode 100644
index 16037640..00000000
Binary files a/docs/v0.13/getting-started/run-applications-diagram.jpg and /dev/null differ
diff --git a/docs/v0.13/getting-started/run-applications-flights.png b/docs/v0.13/getting-started/run-applications-flights.png
deleted file mode 100644
index c7d3b8d0..00000000
Binary files a/docs/v0.13/getting-started/run-applications-flights.png and /dev/null differ
diff --git a/docs/v0.13/getting-started/run-applications.md b/docs/v0.13/getting-started/run-applications.md
deleted file mode 100644
index cb437cb3..00000000
--- a/docs/v0.13/getting-started/run-applications.md
+++ /dev/null
@@ -1,482 +0,0 @@
----
-title: Run Applications
-toc: true
-weight: 5
-indent: true
----
-
-# Run Applications
-
-Crossplane strives to be the best Kubernetes add-on to provision and manage the
-infrastructure and services your applications need directly from kubectl. A huge
-part of this mission is arriving at an elegant, flexible way to model and manage
-cloud native applications. Crossplane allows your team to deploy and run
-applications using the [Open Application Model] (OAM).
-
-OAM is a team-centric model for cloud native apps. Like Crossplane, OAM focuses
-on the different people who might be involved in the deployment of a cloud
-native application. In this getting started guide:
-
-* _Infrastructure Operators_ provide the infrastructure applications need.
-* _Application Developers_ build and supply the components of an application.
-* _Application Operators_ compose, deploy, and run application configurations.
-
-We'll play the roles of each of these team members as we deploy an application -
-Service Tracker - that consists of several services. One of these services, the
-`data-api`, is backed by a managed PostgreSQL database that is provisioned
-on-demand by Crossplane.
-
-![Service Tracker Diagram]
-
-> This guide follows on from the previous one in which we covered defining,
-> [composing], and offering infrastructure. You'll need to have defined and
-> offered a PostgreSQLInstance with at least one working Composition in order
-> to create the OAM application we'll use in this guide.
-
-## Infrastructure Operator
-
-### Install workloads and traits
-
-As the infrastructure operator our work is almost done - we defined, published,
-and composed the infrastructure that our application developer and operator
-teammates will use in the previous guide. One task remains, which is to define
-the [_workloads_] and [_traits_] that our platform supports.
-
-OAM applications consist of workloads, each of which may be modified by traits.
-The infrastructure operator may choose which workloads and traits by creating
-or deleting `WorkloadDefinitions` and `TraitDefinitions` like below:
-
-```yaml
----
-apiVersion: core.oam.dev/v1alpha2
-kind: WorkloadDefinition
-metadata:
- name: postgresqlinstances.database.example.org
-spec:
- definitionRef:
- name: postgresqlinstances.database.example.org
----
-# The OAM controller needs RBAC access to reconcile any non-core workloads.
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- labels:
- rbac.oam.dev/aggregate-to-controller: "true"
- name: oam:claim:postgresqlinstancesdatabase.example.org:aggregate-to-controller
-rules:
-- apiGroups:
- - database.example.org
- resources:
- - postgresqlinstances
- verbs:
- - '*'
-```
-
-Run the following command to add support for all the workloads and traits required
-by this guide:
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/run/definitions.yaml
-```
-
-## Application Developer
-
-### Publish Application Components
-
-Now we'll play the role of the application developer. Our Service Tracker
-application consists of a UI service, four API services, and a PostgreSQL
-database. Under the Open Application Model application developers define
-[_components_] that application operators may compose into applications, which
-produce workloads. Creating components allows us as application developers to
-communicate any fundamental, suggested, or optional properties of our services
-and their infrastructure claims.
-
-```yaml
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: data-api-database
-spec:
- workload:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstance
- metadata:
- name: app-postgresql
- spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- guide: quickstart
- parameters:
- - name: database-secret
- description: Secret to which to write PostgreSQL database connection details.
- required: true
- fieldPaths:
- - spec.writeConnectionSecretToRef.name
- - name: database-provider
- description: |
- Cloud provider that should be used to create a PostgreSQL database.
- Either alibaba, aws, azure, or gcp.
- fieldPaths:
- - spec.compositionSelector.matchLabels.provider
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: data-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: data-api
- spec:
- containers:
- - name: data-api
- image: artursouza/rudr-data-api:0.50
- env:
- - name: DATABASE_USER
- fromSecret:
- key: username
- - name: DATABASE_PASSWORD
- fromSecret:
- key: password
- - name: DATABASE_HOSTNAME
- fromSecret:
- key: endpoint
- - name: DATABASE_PORT
- fromSecret:
- key: port
- - name: DATABASE_NAME
- value: postgres
- - name: DATABASE_DRIVER
- value: postgresql
- ports:
- - name: http
- containerPort: 3009
- protocol: TCP
- livenessProbe:
- exec:
- command: [wget, -q, http://127.0.0.1:3009/status, -O, /dev/null, -S]
- parameters:
- - name: database-secret
- description: Secret from which to read PostgreSQL connection details.
- required: true
- fieldPaths:
- - spec.containers[0].env[0].fromSecret.name
- - spec.containers[0].env[1].fromSecret.name
- - spec.containers[0].env[2].fromSecret.name
- - spec.containers[0].env[3].fromSecret.name
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: flights-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: flights-api
- spec:
- containers:
- - name: flights-api
- image: sonofjorel/rudr-flights-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3003
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: quakes-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: quakes-api
- spec:
- containers:
- - name: quakes-api
- image: sonofjorel/rudr-quakes-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3012
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: service-tracker-ui
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: web-ui
- spec:
- containers:
- - name: service-tracker-ui
- image: sonofjorel/rudr-web-ui:0.49
- env:
- - name: FLIGHT_API_ROOT
- - name: WEATHER_API_ROOT
- - name: QUAKES_API_ROOT
- ports:
- - name: http
- containerPort: 8080
- protocol: TCP
- parameters:
- - name: flights-uri
- description: URI at which the flights service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
- - name: weather-uri
- description: URI at which the weather service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[1].value
- - name: quakes-uri
- description: URI at which the quakes service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[2].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: weather-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: weather-api
- spec:
- containers:
- - name: weather-api
- image: sonofjorel/rudr-weather-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3015
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/run/components.yaml
-```
-
-Each of the above components describes a particular kind of workload. The
-Service Tracker application consists of two kinds of workload:
-
-* A [`ContainerizedWorkload`] is a long-running containerized process.
-* A `PostgreSQLInstance` is a PostgreSQL instance and database.
-
-All OAM components configure a kind of workload, and any kind of Kubernetes
-resource may act as an OAM workload as long as an infrastructure operator has
-allowed it to by authoring a `WorkloadDefinition`.
-
-## Application Operator
-
-### Run The Application
-
-Finally, we'll play the role of an application operator and tie together the
-application components and infrastructure that our application developer and
-infrastructure operator team-mates have published. In OAM this is done by
-authoring an [_application configuration_]:
-
-```yaml
-apiVersion: core.oam.dev/v1alpha2
-kind: ApplicationConfiguration
-metadata:
- name: service-tracker
-spec:
- components:
- - componentName: data-api-database
- parameterValues:
- - name: database-secret
- value: tracker-database-secret
- - componentName: data-api
- parameterValues:
- - name: database-secret
- value: tracker-database-secret
- - componentName: flights-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: flights-api
- spec:
- replicaCount: 2
- - componentName: quakes-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: quakes-api
- spec:
- replicaCount: 2
- - componentName: weather-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: weather-api
- spec:
- replicaCount: 2
- - componentName: service-tracker-ui
- parameterValues:
- - name: flights-uri
- value: "http://flights-api.default.svc.cluster.local:3003/"
- - name: weather-uri
- value: "http://weather-api.default.svc.cluster.local:3015/"
- - name: quakes-uri
- value: "http://quakes-api.default.svc.cluster.local:3012/"
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/run/appconfig.yaml
-```
-
-This application configuration names each of components the application
-developer created earlier to produce workloads. The application operator may (or
-in some cases _must_) provide parameter values for a component in order to
-override or specify certain configuration values. Component parameters represent
-configuration settings that the component author - the application developer -
-deemed to be of interest to application operators.
-
-```yaml
-- componentName: data-api-database
- parameterValues:
- - name: database-provider
- value: azure
-```
-
-> If you created Compositions for more than one provider in the previous guide
-> you can add the above parameter to the `data-api-database` component to choose
-> which cloud provider the Service Tracker's database should run on.
-
-You might notice that some components include a [`ManualScalerTrait`]. Traits
-augment the workload produced by a component with additional features, allowing
-application operators to make decisions about the configuration of a component
-without having to involve the developer. The `ManualScalerTrait` allows an
-application operator to specify how many replicas should exist of any scalable
-kind of workload.
-
-> Note that the OAM spec also includes the concept of an _application scope_.
-> Crossplane does not yet support scopes.
-
-## Use The Application
-
-Finally, we'll open and use the Service Tracker application we just deployed.
-
-
-
-If you deployed Service Tracker to a managed cluster like AKS, ACK, EKS, or GKE
-with support for load balancer Services you should be able to browse to the IP
-of the `web-ui` service on port 8080 - for example .
-
-```console
-kubectl get svc web-ui -o=jsonpath={.status.loadBalancer.ingress[0].ip}
-```
-
-
-
-
-If you're using a cluster that doesn't support load balancer Services, like Kind
-or Minikube you can use a port forward instead, and connect to
-
-
-```console
-kubectl port-forward deployment/web-ui 8080
-```
-
-
-
-
-You should see the Service Tracker dashboard in your browser. Hit 'Refresh Data'
-for each of the services to ensure the Service Tracker web UI can connect to its
-various data API services and populate its PostgreSQL database:
-
-![Service Tracker Dashboard]
-
-If everything was successful you should be able to browse to Flights,
-Earthquakes, or Weather to see what's going on in the world today:
-
-![Service Tracker Flights]
-
-## Clean Up
-
-To shut down your application, simply run:
-
-```console
-kubectl delete applicationconfiguration service-tracker
-```
-
-If you also wish to delete the components, workload definitions, and trait
-definitions we created in this guide, run:
-
-```console
-kubectl delete -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/run/components.yaml
-kubectl delete -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/docs/snippets/run/definitions.yaml
-```
-
-[Open Application Model]: https://oam.dev/
-[composing]: compose-infrastructure.md
-[Service Tracker Diagram]: run-applications-diagram.jpg
-[_workloads_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/3.workload.md
-[_traits_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/6.traits.md
-[_components_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/4.component.md
-[_application configuration_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/7.application_configuration.md
-[`ContainerizedWorkload`]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/core/workloads/containerized_workload/containerized_workload.md
-[`ManualScalerTrait`]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/core/traits/manual_scaler_trait.md
-[_application scope_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/5.application_scopes.md
-[Service Tracker Dashboard]: run-applications-dash.png
-[Service Tracker Flights]: run-applications-flights.png
diff --git a/docs/v0.13/guides/argocd.md b/docs/v0.13/guides/argocd.md
deleted file mode 100644
index 7ff668fe..00000000
--- a/docs/v0.13/guides/argocd.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Argo CD
-toc: true
-weight: 201
-indent: true
-redirect_to: https://aws.amazon.com/blogs/opensource/connecting-aws-managed-services-to-your-argo-cd-pipeline-with-open-source-crossplane/
----
diff --git a/docs/v0.13/guides/guides.md b/docs/v0.13/guides/guides.md
deleted file mode 100644
index 2dbb6064..00000000
--- a/docs/v0.13/guides/guides.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: Guides
-toc: true
-weight: 200
----
-
-# Guides
-
-Because of Crossplane's standardization on the Kubernetes API, it integrates
-well with many other projects. Below is a collection of guides and tutorials that
-demonstrate how to use Crossplane with a variety tools and projects often used
-with Kubernetes plus some deep dive content on Crossplane itself!
-
-- [Argo CD] - use GitOps to provision managed services with Crossplane and Argo CD.
-- [Knative] - use managed services provisioned by Crossplane in your Knative services.
-- [Okteto] - use managed services in your Okteto development workflow.
-- [Open Policy Agent] - set global policy on provisioning cloud resources with Crossplane and OPA.
-- [OpenFaaS] - consume managed services with for your serverless functions.
-- [Provider Internals] - translate provider APIs into managed resource CRDs and explore managed resource API patterns & best practices.
-- [Velero] - backup and restore your Crossplane infrastructure resources.
-
-
-
-[Velero]: https://www.youtube.com/watch?v=eV_2QoMRqGw&list=PL510POnNVaaYFuK-B_SIUrpIonCtLVOzT&index=18&t=183s
-[Argo CD]: https://aws.amazon.com/blogs/opensource/connecting-aws-managed-services-to-your-argo-cd-pipeline-with-open-source-crossplane/
-[Open Policy Agent]: https://github.com/crossplane/tbs/tree/master/episodes/14
-[Knative]: https://github.com/crossplane/tbs/tree/master/episodes/15
-[OpenFaaS]: https://github.com/crossplane/tbs/tree/master/episodes/13
-[Okteto]: https://github.com/crossplane/tbs/tree/master/episodes/10
-[Provider Internals]: https://github.com/crossplane/tbs/tree/master/episodes/7
diff --git a/docs/v0.13/guides/knative.md b/docs/v0.13/guides/knative.md
deleted file mode 100644
index ddb0953b..00000000
--- a/docs/v0.13/guides/knative.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Knative
-toc: true
-weight: 202
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/15
----
diff --git a/docs/v0.13/guides/okteto.md b/docs/v0.13/guides/okteto.md
deleted file mode 100644
index 3cede639..00000000
--- a/docs/v0.13/guides/okteto.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Okteto
-toc: true
-weight: 203
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/10
----
diff --git a/docs/v0.13/guides/opa.md b/docs/v0.13/guides/opa.md
deleted file mode 100644
index 9e0abc8d..00000000
--- a/docs/v0.13/guides/opa.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Open Policy Agent
-toc: true
-weight: 204
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/14
----
diff --git a/docs/v0.13/guides/openfaas.md b/docs/v0.13/guides/openfaas.md
deleted file mode 100644
index d7c3bcac..00000000
--- a/docs/v0.13/guides/openfaas.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: OpenFaaS
-toc: true
-weight: 205
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/13
----
diff --git a/docs/v0.13/guides/provider-internals.md b/docs/v0.13/guides/provider-internals.md
deleted file mode 100644
index bc178a17..00000000
--- a/docs/v0.13/guides/provider-internals.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Provider Internals
-toc: true
-weight: 206
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/7
----
diff --git a/docs/v0.13/guides/velero.md b/docs/v0.13/guides/velero.md
deleted file mode 100644
index ebec433a..00000000
--- a/docs/v0.13/guides/velero.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Velero
-toc: true
-weight: 207
-indent: true
-redirect_to: https://www.youtube.com/watch?v=eV_2QoMRqGw&list=PL510POnNVaaYFuK-B_SIUrpIonCtLVOzT&index=18&t=183s
----
diff --git a/docs/v0.13/introduction/composition-concepts.png b/docs/v0.13/introduction/composition-concepts.png
deleted file mode 100644
index 75327226..00000000
Binary files a/docs/v0.13/introduction/composition-concepts.png and /dev/null differ
diff --git a/docs/v0.13/introduction/composition-provisioning.png b/docs/v0.13/introduction/composition-provisioning.png
deleted file mode 100644
index a07aac66..00000000
Binary files a/docs/v0.13/introduction/composition-provisioning.png and /dev/null differ
diff --git a/docs/v0.13/introduction/composition.md b/docs/v0.13/introduction/composition.md
deleted file mode 100644
index 319e482a..00000000
--- a/docs/v0.13/introduction/composition.md
+++ /dev/null
@@ -1,817 +0,0 @@
----
-title: Composing Infrastructure
-toc: true
-weight: 103
-indent: true
----
-
-# Composing Infrastructure
-
-Crossplane allows infrastructure operators to define and compose new kinds of
-infrastructure resources then offer them for the application operators they
-support to use, all without writing any code.
-
-Infrastructure providers extend Crossplane, enabling it to manage a wide array
-of infrastructure resources like Azure SQL servers and AWS ElastiCache clusters.
-Infrastructure composition allows infrastructure operators to define, share, and
-reuse new kinds of infrastructure resources that are _composed_ of these
-infrastructure resources. Infrastructure operators may configure one or more
-compositions of any defined resource, and may publish any defined resource to
-their application operators, who may then declare that their application
-requires that kind of resource.
-
-Composition can be used to build a catalogue of kinds and configuration classes
-of infrastructure that fit the needs and opinions of your organisation. As an
-infrastructure operator you might define your own `MySQLInstance` resource. This
-resource would allow your application operators to configure only the settings
-that _your_ organisation needs - perhaps engine version and storage size. All
-other settings are deferred to a selectable composition representing a
-configuration class like "production" or "staging". Compositions can hide
-infrastructure complexity and include policy guardrails so that applications can
-easily and safely consume the infrastructure they need, while conforming to your
-organisational best-practices.
-
-> Note that composition is an **alpha** feature of Crossplane. Refer to [Current
-> Limitations] for information on functionality that is planned but not yet
-> implemented.
-
-## Concepts
-
-![Infrastructure Composition Concepts]
-
-A _Composite Resource_ (XR) is a special kind of custom resource that is
-composed of other resources. Its schema is user-defined. The
-`CompositeMySQLInstance` in the above diagram is a composite resource. The kind
-of a composite resource is configurable - the `Composite` prefix is not
-required.
-
-A `Composition` specifies how Crossplane should reconcile a composite
-infrastructure resource - i.e. what infrastructure resources it should compose.
-For example the Azure `Composition` configures Crossplane to reconcile a
-`CompositeMySQLInstance` by creating and managing the lifecycle of an Azure
-`MySQLServer` and `MySQLServerFirewallRule`.
-
-A _Composite Resource Claim_ (XRC) for an resource declares that an application
-requires particular kind of infrastructure, as well as specifying how to
-configure it. The `MySQLInstance` resources in the above diagram declare that
-the application pods each require a `CompositeMySQLInstance`. As with composite
-resources, the kind of the claim is configurable. Offering a claim is optional.
-
-A `CompositeResourceDefinition` (XRD) defines a new kind of composite resource,
-and optionally the claim it offers. The `CompositeResourceDefinition` in the
-above diagram defines the `CompositeMySQLInstance` composite resource, and its
-corresponding `MySQLInstance` claim.
-
-> Note that composite resources and compositions are _cluster scoped_ - they
-> exist outside of any Kubernetes namespace. A claim is a namespaced proxy for a
-> composite resource. This enables an RBAC model under which application
-> operators may only interact with infrastructure via resource claims.
-
-## Defining Infrastructure
-
-New kinds of infrastructure resource are defined by an infrastructure operator.
-There are three steps to this process:
-
-1. Define your composite resource, and optionally the claim it offers.
-1. Specify one or more possible ways your composite resource may be composed.
-
-### Define your Composite Resource
-
-Composite resources are defined by a `CompositeResourceDefinition`:
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: CompositeResourceDefinition
-metadata:
- # XRDs follow the constraints of CRD names. They must be named
- # ., per the plural and group names configured by the
- # crdSpecTemplate below.
- name: compositemysqlinstances.example.org
-spec:
- # Composite resources may optionally expose a connection secret - a Kubernetes
- # Secret containing all of the details a pod might need to connect to the
- # resource. Resources that wish to expose a connection secret must declare
- # what keys they support. These keys form a 'contract' - any composition that
- # intends to be compatible with this resource must compose resources that
- # supply these connection secret keys.
- connectionSecretKeys:
- - username
- - password
- - hostname
- - port
- # You can specify a default Composition resource to be selected if there is
- # no composition selector or reference was supplied on the Custom Resource.
- defaultCompositionRef:
- name: example-azure
- # Enforced composition will be selected for all instances of this type and it
- # will override the selectors and referencers that are different.
- #
- #enforcedCompositionRef:
- # name: securemysql.acme.org
- #
- # The kind of claim this composite resource offers. Optional - omit the claim
- # names if you don't wish to offer a claim for this composite resource. Must
- # be different from the composite resource's kind. The established convention
- # is for the claim kind to represent what the resource is, conceptually. e.g.
- # 'MySQLInstance', not `MySQLInstanceClaim`.
- claimNames:
- kind: MySQLInstance
- plural: mysqlinstances
- # A template for the spec of a CustomResourceDefinition. Only the group,
- # version, names, validation, and additionalPrinterColumns fields of a CRD
- # spec are supported.
- crdSpecTemplate:
- group: example.org
- version: v1alpha1
- names:
- kind: CompositeMySQLInstance
- plural: compositemysqlinstances
- validation:
- # This schema defines the configuration fields that the composite resource
- # supports. It uses the same structural OpenAPI schema as a Kubernetes CRD
- # - for example, this resource supports a spec.parameters.version enum.
- # The following fields are reserved for Crossplane's use, and will be
- # overwritten if included in this validation schema:
- #
- # - spec.resourceRef
- # - spec.resourceRefs
- # - spec.claimRef
- # - spec.writeConnectionSecretToRef
- # - status.conditions
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- parameters:
- type: object
- properties:
- version:
- description: MySQL engine version
- type: string
- enum: ["5.6", "5.7"]
- storageGB:
- type: integer
- location:
- description: Geographic location of this MySQL server.
- type: string
- required:
- - version
- - storageGB
- - location
- required:
- - parameters
-```
-
-Refer to the Kubernetes documentation on [structural schemas] for full details
-on how to configure the `openAPIV3Schema` for your composite resource.
-
-`kubectl describe` can be used to confirm that a new composite
-resource was successfully defined. Note the `Established` condition and events,
-which indicate the process was successful.
-
-```console
-$ kubectl describe xrd compositemysqlinstances.example.org
-
-Name: compositemysqlinstances.example.org
-Namespace:
-Labels:
-Annotations: API Version: apiextensions.crossplane.io/v1alpha1
-Kind: CompositeResourceDefinition
-Metadata:
- Creation Timestamp: 2020-05-15T05:30:44Z
- Generation: 1
- Resource Version: 1418120
- Self Link: /apis/apiextensions.crossplane.io/v1alpha1/compositeresourcedefinitions/compositemysqlinstances.example.org
- UID: f8fedfaf-4dfd-4b8a-8228-6af0f4abd7a0
-Spec:
- Connection Secret Keys:
- username
- password
- hostname
- port
- Default Composition Ref:
- Name: example-azure
- Claim Names:
- Kind: MySQLInstance
- List Kind: MySQLInstanceList
- Plural: mysqlinstances
- Singular: mysqlinstance
- Crd Spec Template:
- Group: example.org
- Names:
- Kind: CompositeMySQLInstance
- List Kind: CompositeMySQLInstanceList
- Plural: compositemysqlinstances
- Singular: compositemysqlinstance
- Validation:
- openAPIV3Schema:
- Properties:
- Spec:
- Parameters:
- Properties:
- Location:
- Description: Geographic location of this MySQL server.
- Type: string
- Storage GB:
- Type: integer
- Version:
- Description: MySQL engine version
- Enum:
- 5.6
- 5.7
- Type: string
- Required:
- version
- storageGB
- location
- Type: object
- Required:
- parameters
- Type: object
- Type: object
- Version: v1alpha1
-Status:
- Conditions:
- Last Transition Time: 2020-05-15T05:30:45Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
- Last Transition Time: 2020-05-15T05:30:45Z
- Reason: Created CRD and started controller
- Status: True
- Type: Established
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal ApplyCompositeResourceDefinition 4m10s apiextension/compositeresourcedefinition.apiextensions.crossplane.io waiting for CustomResourceDefinition to be established
- Normal RenderCustomResourceDefinition 55s (x8 over 4m10s) apiextension/compositeresourcedefinition.apiextensions.crossplane.io Rendered CustomResourceDefinition
- Normal ApplyCompositeResourceDefinition 55s (x7 over 4m9s) apiextension/compositeresourcedefinition.apiextensions.crossplane.io Applied CustomResourceDefinition and (re)started composite controller
-```
-
-### Specify How Your Resource May Be Composed
-
-Once a new kind of composite resource is defined Crossplane must be instructed
-how to reconcile that kind of resource. This is done by authoring a
-`Composition`.
-
-A `Composition`:
-
-* Declares one kind of composite resource that it satisfies.
-* Specifies a "base" configuration for one or more composed resources.
-* Specifies "patches" that overlay configuration values from an instance of the
- composite resource onto each "base".
-
-Multiple compositions may satisfy a particular kind of composite resource, and
-the author of a composite resource (or resource claim) may select which
-composition will be used. This allows an infrastructure operator to offer their
-application operators a choice between multiple opinionated classes of
-infrastructure, allowing them to explicitly specify only some configuration. An
-infrastructure operator may offer their application operators the choice between
-an "Azure" and a "GCP" composition when creating a `MySQLInstance` for example,
-Or they may offer a choice between a "production" and a "staging" composition.
-They can also offer a default composition in case application operators do not
-supply a composition selector or enforce a specific composition in order to
-override the composition choice of users for all instances. In all cases, the
-application operator may configure any value supported by the composite
-resource's schema, with all other values being deferred to the composition.
-
-The below `Composition` satisfies the `CompositeMySQLInstance` defined in the
-previous section by composing an Azure SQL server, firewall rule, and resource
-group:
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: Composition
-metadata:
- name: example-azure
- labels:
- purpose: example
- provider: azure
-spec:
- # This Composition declares that it satisfies the CompositeMySQLInstance
- # resource defined above - i.e. it patches "from" a CompositeMySQLInstance.
- compositeTypeRef:
- apiVersion: example.org/v1alpha1
- kind: CompositeMySQLInstance
- # This Composition reconciles a CompositeMySQLInstance by patching from
- # the CompositeMySQLInstance "to" new instances of the infrastructure
- # resources below. These resources may be the managed resources of an
- # infrastructure provider such as provider-azure, or other composite
- # resources.
- resources:
- # A CompositeMySQLInstance that uses this Composition will be composed of an
- # Azure ResourceGroup. The "base" for this ResourceGroup specifies the base
- # configuration that may be extended or mutated by the patches below.
- - base:
- apiVersion: azure.crossplane.io/v1alpha3
- kind: ResourceGroup
- spec: {}
- # Patches copy or "overlay" the value of a field path within the composite
- # resource (the CompositeMySQLInstance) to a field path within the composed
- # resource (the ResourceGroup). In the below example any labels and
- # annotations will be propagated from the CompositeMySQLInstance to the
- # ResourceGroup, as will the location.
- patches:
- - fromFieldPath: "metadata.labels"
- toFieldPath: "metadata.labels"
- - fromFieldPath: "metadata.annotations"
- toFieldPath: "metadata.annotations"
- - fromFieldPath: "spec.parameters.location"
- toFieldPath: "spec.location"
- # Sometimes it is necessary to "transform" the value from the composite
- # resource into a value suitable for the composed resource, for example an
- # Azure based composition may represent geographical locations differently
- # from a GCP based composition that satisfies the same composite resource.
- # This can be done by providing an optional array of transforms, such as
- # the below that will transform the MySQLInstance spec.parameters.location
- # value "us-west" into the ResourceGroup spec.location value "West US".
- transforms:
- - type: map
- map:
- us-west: West US
- us-east: East US
- au-east: Australia East
- # A MySQLInstance that uses this Composition will also be composed of an
- # Azure MySQLServer.
- - base:
- apiVersion: database.azure.crossplane.io/v1beta1
- kind: MySQLServer
- spec:
- forProvider:
- # When this MySQLServer is created it must specify a ResourceGroup in
- # which it will exist. The below resourceGroupNameSelector corresponds
- # to the spec.forProvider.resourceGroupName field of the MySQLServer.
- # It selects a ResourceGroup with a matching controller reference.
- # Two resources that are part of the same composite resource will have
- # matching controller references, so this MySQLServer will always
- # select the ResourceGroup above. If this Composition included more
- # than one ResourceGroup they could be differentiated by matchLabels.
- resourceGroupNameSelector:
- matchControllerRef: true
- administratorLogin: notadmin
- sslEnforcement: Disabled
- sku:
- tier: GeneralPurpose
- capacity: 8
- family: Gen5
- storageProfile:
- backupRetentionDays: 7
- geoRedundantBackup: Disabled
- writeConnectionSecretToRef:
- namespace: crossplane-system
- patches:
- - fromFieldPath: "metadata.labels"
- toFieldPath: "metadata.labels"
- - fromFieldPath: "metadata.annotations"
- toFieldPath: "metadata.annotations"
- - fromFieldPath: "metadata.uid"
- toFieldPath: "spec.writeConnectionSecretToRef.name"
- transforms:
- # Transform the value from the CompositeMySQLInstance using Go string
- # formatting. This can be used to prefix or suffix a string, or to
- # convert a number to a string. See https://golang.org/pkg/fmt/ for more
- # detail.
- - type: string
- string:
- fmt: "%s-mysqlserver"
- - fromFieldPath: "spec.parameters.version"
- toFieldPath: "spec.forProvider.version"
- - fromFieldPath: "spec.parameters.location"
- toFieldPath: "spec.forProvider.location"
- transforms:
- - type: map
- map:
- us-west: West US
- us-east: East US
- au-east: Australia East
- - fromFieldPath: "spec.parameters.storageGB"
- toFieldPath: "spec.forProvider.storageProfile.storageMB"
- # Transform the value from the CompositeMySQLInstance by multiplying it by
- # 1024 to convert Gigabytes to Megabytes.
- transforms:
- - type: math
- math:
- multiply: 1024
- # In addition to a base and patches, this composed MySQLServer declares that
- # it can fulfil the connectionSecretKeys contract required by the definition
- # of the CompositeMySQLInstance. This MySQLServer writes a connection secret
- # with a username, password, and endpoint that may be used to connect to it.
- # These connection details will also be exposed via the composite resource's
- # connection secret. Exactly one composed resource must provide each secret
- # key, but different composed resources may provide different keys.
- connectionDetails:
- - fromConnectionSecretKey: username
- - fromConnectionSecretKey: password
- # The name of the required CompositeMySQLInstance connection secret key
- # can be supplied if it is different from the connection secret key
- # exposed by the MySQLServer.
- - name: hostname
- fromConnectionSecretKey: endpoint
- # In some cases it may be desirable to inject a fixed connection secret
- # value, for example to expose fixed, non-sensitive connection details
- # like standard ports that are not published to the composed resource's
- # connection secret.
- - name: port
- value: "3306"
- # A CompositeMySQLInstance that uses this Composition will also be composed
- # of an Azure MySQLServerFirewallRule.
- - base:
- apiVersion: database.azure.crossplane.io/v1alpha3
- kind: MySQLServerFirewallRule
- spec:
- forProvider:
- resourceGroupNameSelector:
- matchControllerRef: true
- serverNameSelector:
- matchControllerRef: true
- properties:
- startIpAddress: 10.10.0.0
- endIpAddress: 10.10.255.254
- virtualNetworkSubnetIdSelector:
- name: sample-subnet
- patches:
- - fromFieldPath: "metadata.labels"
- toFieldPath: "metadata.labels"
- - fromFieldPath: "metadata.annotations"
- toFieldPath: "metadata.annotations"
- # Some composite resources may be "dynamically provisioned" - i.e. provisioned
- # on-demand to satisfy an application's claim for infrastructure. The
- # writeConnectionSecretsToNamespace field configures the default value used
- # when dynamically provisioning a composite resource; it is explained in more
- # detail below.
- writeConnectionSecretsToNamespace: crossplane-system
-```
-
-Field paths reference a field within a Kubernetes object via a simple string.
-API conventions describe the syntax as "standard JavaScript syntax for accessing
-that field, assuming the JSON object was transformed into a JavaScript object,
-without the leading dot, such as metadata.name". Array indices are specified via
-square braces while object fields may be specified via a period or via square
-braces.Kubernetes field paths do not support advanced features of JSON paths,
-such as `@`, `$`, or `*`. For example given the below `Pod`:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: example-pod
- annotations:
- example.org/a: example-annotation
-spec:
- containers:
- - name: example-container
- image: example:latest
- command: [example]
- args: ["--debug", "--example"]
-```
-
-* `metadata.name` would contain "example-pod"
-* `metadata.annotations['example.org/a']` would contain "example-annotation"
-* `spec.containers[0].name` would contain "example-container"
-* `spec.containers[0].args[1]` would contain "--example"
-
-> Note that Compositions provide _intentionally_ limited functionality when
-> compared to powerful templating and composition tools like Helm or Kustomize.
-> This allows a Composition to be a schemafied Kubernetes-native resource that
-> can be stored in and validated by the Kubernetes API server at authoring time
-> rather than invocation time.
-
-### Permit Crossplane to Reconcile Your Composite Resource
-
-Typically Crossplane runs using a service account that does not have access to
-reconcile arbitrary kinds of resource. A `ClusterRole` can grant Crossplane
-permission to reconcile your newly defined and published resource:
-
-```yaml
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: compositemysqlinstances.example.org
- labels:
- rbac.crossplane.io/aggregate-to-crossplane: "true"
-rules:
-- apiGroups:
- - example.org
- resources:
- - compositemysqlinstances
- - compositemysqlinstances/status
- - mysqlinstances
- - mysqlinstances/status
- verbs:
- - "*"
-```
-
-## Using Composite Resources
-
-![Infrastructure Composition Provisioning]
-
-Crossplane offers several ways for both infrastructure operators and application
-operators to use the composite resource they've defined and offered:
-
-1. Only infrastructure operators can create or manage a composite resource that
- does not offer a composite resource claim.
-1. Infrastructure operators can also create composite resources that offer a
- claim. This allows an application operator to create a claim that
- specifically requests the composite resource the infrastructure operator
- created.
-1. Application operators can create a composite resource claim (if the composite
- resource offers one), and a composite resource will be provisioned on-demand.
-
-Options one and two are frequently referred to as "static provisioning", while
-option three is known as "dynamic provisioning".
-
-> Note that infrastructure operator focused Crossplane concepts are cluster
-> scoped - they exist outside any namespace. Crossplane assumes infrastructure
-> operators will have similar RBAC permissions to cluster administrators, and
-> will thus be permitted to manage cluster scoped resources. Application
-> operator focused Crossplane concepts are namespaced. Crossplane assumes
-> application operators will be permitted access to the namespace(s) in which
-> their applications run, and not to cluster scoped resources.
-
-### Creating and Managing Composite Resources
-
-An infrastructure operator may wish to author a composite resource of a kind
-that offers a claim so that an application operator may later author a claim for
-that exact resource. This pattern is useful for resources that may take several
-minutes to provision - the infrastructure operator can keep a pool of resources
-available in advance in order to ensure claims may be instantly satisfied.
-
-In some cases an infrastructure operator may wish to use Crossplane to model a
-composite that they do not wish to allow application operators to provision.
-Consider a `VPCNetwork` composite resource that creates an AWS VPC network with
-an internet gateway, route table, and several subnets. Defining this resource as
-a composite allows the infrastructure operator to easily reuse their
-configuration, but it does not make sense in their organisation to allow
-application operators to create "supporting infrastructure" like a VPC network.
-
-In both of the above scenarios the infrastructure operator may statically
-provision a composite resource; i.e. author it directly rather than via its
-corresponding resource claim. The `CompositeMySQLInstance` composite resource
-defined above could be authored as follows:
-
-```yaml
-apiVersion: example.org/v1alpha1
-kind: CompositeMySQLInstance
-metadata:
- # Composite resources are cluster scoped, so there's no need for a namespace.
- name: example
-spec:
- # The schema of the spec.parameters object is defined by the earlier example
- # of an CompositeResourceDefinition. The location, storageGB, and version fields
- # are patched onto the ResourceGroup, MySQLServer, and MySQLServerFirewallRule
- # that this MySQLInstance composes.
- parameters:
- location: au-east
- storageGB: 20
- version: "5.7"
- # Support for a compositionRef is automatically injected into the schema of
- # all defined composite resources. This allows the resource
- # author to explicitly reference a Composition that this composite resource
- # should use - in this case the earlier example-azure Composition. Note that
- # it is also possible to select a composition by labels - see the below
- # MySQLInstance for an example of this approach.
- compositionRef:
- name: example-azure
- # Support for a writeConnectionSecretToRef is automatically injected into the
- # schema of all defined composite resources. This allows the
- # resource to write a connection secret containing any details required to
- # connect to it - in this case the hostname, username, and password. Composite
- # resource authors may omit this reference if they do not need or wish to
- # write these details.
- writeConnectionSecretToRef:
- namespace: infra-secrets
- name: example-mysqlinstance
-```
-
-Any updates to the `CompositeMySQLInstance` will be immediately reconciled with
-the resources it composes. For example if more storage were needed an update to
-the `spec.parameters.storageGB` field would immediately be propagated to the
-`spec.forProvider.storageProfile.storageMB` field of the composed `MySQLServer`
-due to the relationship established between these two fields by the patches
-configured in the `example-azure` `Composition`.
-
-`kubectl describe` may be used to examine a composite resource. Note the
-`Synced` and `Ready` conditions below. The former indicates that Crossplane is
-successfully reconciling the composite resource by updating the composed
-resources. The latter indicates that all composed resources are also indicating
-that they are in condition `Ready`, and therefore the composite resource should
-be online and ready to use. More detail about the health and configuration of
-the composite resource can be determined by describing each composite resource.
-The kinds and names of each composed resource are exposed as "Resource Refs" -
-for example `kubectl describe mysqlserver example-zrpgr` will describe the
-detailed state of the composed Azure `MySQLServer`.
-
-```console
-$ kubectl describe compositemysqlinstance.example.org
-
-Name: example
-Namespace:
-Labels:
-Annotations: API Version: example.org/v1alpha1
-Kind: CompositeMySQLInstance
-Metadata:
- Creation Timestamp: 2020-05-15T06:53:16Z
- Generation: 4
- Resource Version: 1425809
- Self Link: /apis/example.org/v1alpha1/compositemysqlinstances/example
- UID: f654dd52-fe0e-47c8-aa9b-235c77505674
-Spec:
- Composition Ref:
- Name: example-azure
- Parameters:
- Location: au-east
- Storage GB: 20
- Version: 5.7
- Reclaim Policy: Delete
- Resource Refs:
- API Version: azure.crossplane.io/v1alpha3
- Kind: ResourceGroup
- Name: example-wspmk
- UID: 4909ab46-95ef-4ba7-8f7a-e1d9ee1a6b23
- API Version: database.azure.crossplane.io/v1beta1
- Kind: MySQLServer
- Name: example-zrpgr
- UID: 3afb903e-32db-4834-a6e7-31249212dca0
- API Version: database.azure.crossplane.io/v1alpha3
- Kind: MySQLServerFirewallRule
- Name: example-h4zjn
- UID: 602c8412-7c33-4338-a3af-78166c17b1a0
- Write Connection Secret To Ref:
- Name: example-mysqlinstance
- Namespace: infra-secrets
-Status:
- Conditions:
- Last Transition Time: 2020-05-15T06:56:46Z
- Reason: Resource is available for use
- Status: True
- Type: Ready
- Last Transition Time: 2020-05-15T06:53:16Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal SelectComposition 10s (x7 over 3m40s) composite/compositemysqlinstances.example.org Successfully selected composition
- Normal PublishConnectionSecret 10s (x7 over 3m40s) composite/compositemysqlinstances.example.org Successfully published connection details
- Normal ComposeResources 10s (x7 over 3m40s) composite/compositemysqlinstances.example.org Successfully composed resources
-```
-
-### Creating a Composite Resource Claim
-
-Composite resource claims represent an application's need for a particular kind
-of composite resource, for example the above `MySQLInstance`. Claims are a proxy
-for the kind of resource they require, allowing application operators to
-provision and consume infrastructure. An claim may request pre-existing,
-statically provisioned infrastructure or it may dynamically provision a
-composite resource on-demand.
-
-The below claim explicitly requests the `CompositeMySQLInstance` authored in the
-previous example:
-
-```yaml
-# The MySQLInstance always has the same API group and version as the
-# resource it requires. Its kind is always suffixed with .
-apiVersion: example.org/v1alpha1
-kind: MySQLInstance
-metadata:
- # Infrastructure claims are namespaced.
- namespace: default
- name: example
-spec:
- # The schema of the spec.parameters object is defined by the earlier example
- # of an CompositeResourceDefinition. The location, storageGB, and version fields
- # are patched onto the ResourceGroup, MySQLServer, and MySQLServerFirewallRule
- # composed by the required MySQLInstance.
- parameters:
- location: au-east
- storageGB: 20
- version: "5.7"
- # Support for a resourceRef is automatically injected into the schema of all
- # resource claims. The resourceRef requests a CompositeMySQLInstance
- # explicitly.
- resourceRef:
- apiVersion: example.org/v1alpha1
- kind: CompositeMySQLInstance
- name: example
- # Support for a writeConnectionSecretToRef is automatically injected into the
- # schema of all published infrastructure claim resources. This allows
- # the resource to write a connection secret containing any details required to
- # connect to it - in this case the hostname, username, and password.
- writeConnectionSecretToRef:
- name: example-mysqlinstance
-```
-
-A claim may omit the `resourceRef` and instead include a `compositionRef` (as in
-the previous `CompositeMySQLInstance` example) or a `compositionSelector` in
-order to trigger dynamic provisioning. A claim that does not include a reference
-to an existing composite resource will have a suitable composite resource
-provisioned on demand:
-
-```yaml
-apiVersion: example.org/v1alpha1
-kind: MySQLInstance
-metadata:
- namespace: default
- name: example
-spec:
- parameters:
- location: au-east
- storageGB: 20
- version: "5.7"
- # Support for a compositionSelector is automatically injected into the schema
- # of all published infrastructure claim resources. This selector selects
- # the example-azure composition by its labels.
- compositionSelector:
- matchLabels:
- purpose: example
- provider: azure
- writeConnectionSecretToRef:
- name: example-mysqlinstance
-```
-
-> Note that compositionSelector labels can form a shared language between the
-> infrastructure operators who define compositions and the application operators
-> who require composite resources. Compositions could be labelled by zone, size,
-> or purpose in order to allow application operators to request a class of
-> composite resource by describing their needs such as "east coast, production".
-
-Like composite resources, claims can be examined using `kubectl describe`.
-The `Synced` and `Ready` conditions have the same meaning as the `MySQLInstance`
-above. The "Resource Ref" indicates the name of the composite resource that was
-either explicitly required, or in the case of the below claim dynamically
-provisioned.
-
-```console
-$ kubectl describe mysqlinstanceclaim.example.org example
-
-Name: example
-Namespace: default
-Labels:
-Annotations: API Version: example.org/v1alpha1
-Kind: MySQLInstance
-Metadata:
- Creation Timestamp: 2020-05-15T07:08:11Z
- Finalizers:
- finalizer.apiextensions.crossplane.io
- Generation: 3
- Resource Version: 1428420
- Self Link: /apis/example.org/v1alpha1/namespaces/default/mysqlinstances/example
- UID: d87e9580-9d2e-41a7-a198-a39851815840
-Spec:
- Composition Selector:
- Match Labels:
- Provider: azure
- Purpose: example
- Parameters:
- Location: au-east
- Storage GB: 20
- Version: 5.7
- Resource Ref:
- API Version: example.org/v1alpha1
- Kind: CompositeMySQLInstance
- Name: default-example-8t4tb
- Write Connection Secret To Ref:
- Name: example-mysqlinstance
-Status:
- Conditions:
- Last Transition Time: 2020-05-15T07:26:49Z
- Reason: Resource is available for use
- Status: True
- Type: Ready
- Last Transition Time: 2020-05-15T07:08:11Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal ConfigureCompositeResource 8m23s claim/compositemysqlinstances.example.org Successfully configured composite resource
- Normal BindCompositeResource 8m23s (x7 over 8m23s) claim/compositemysqlinstances.example.org Composite resource is not yet ready
- Normal BindCompositeResource 4m53s (x4 over 23m) claim/compositemysqlinstances.example.org Successfully bound composite resource
- Normal PropagateConnectionSecret 4m53s (x4 over 23m) claim/compositemysqlinstances.example.org Successfully propagated connection details from composite resource
-```
-
-## Current Limitations
-
-Composite resources are an alpha feature of Crossplane. At present the below
-functionality is planned but not yet implemented:
-
-* Updates to a composite resource are immediately applied to the resources it
- composes, but updates to a claim are not yet applied to the composite resource
- that was allocated to satisfy the claim. In a future release of Crossplane
- updating a claim will update its allocated composite resource.
-* Only three transforms are currently supported - string format, multiplication,
- and map. Crossplane intends to limit the set of supported transforms, and will
- add more as clear use cases appear.
-* Compositions are mutable, and updating a composition causes all composite
- resources that use that composition to be updated accordingly. A future
- release of Crossplane may alter this behaviour.
-
-[Current Limitations]: #current-limitations
-[Infrastructure Composition Concepts]: composition-concepts.png
-[structural schemas]: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#specifying-a-structural-schema
-[Infrastructure Composition Provisioning]: composition-provisioning.png
diff --git a/docs/v0.13/introduction/crossplane-concepts.png b/docs/v0.13/introduction/crossplane-concepts.png
deleted file mode 100644
index 7ae3b0a9..00000000
Binary files a/docs/v0.13/introduction/crossplane-concepts.png and /dev/null differ
diff --git a/docs/v0.13/introduction/managed-resources.md b/docs/v0.13/introduction/managed-resources.md
deleted file mode 100644
index 0f0f4f72..00000000
--- a/docs/v0.13/introduction/managed-resources.md
+++ /dev/null
@@ -1,270 +0,0 @@
----
-title: Managed Resources
-toc: true
-weight: 102
-indent: true
----
-
-# Managed Resources
-
-## Overview
-
-Managed resources are the Crossplane representation of the cloud
-[provider][provider] resources and they are considered primitive low level
-custom resources that can be used directly to provision external cloud resources
-for an application or as part of an infrastructure composition.
-
-For example, `RDSInstance` in AWS Provider corresponds to an actual RDS Instance
-in AWS. There is a one-to-one relationship and the changes on managed resources
-are reflected directly on the corresponding resource in the provider.
-
-You can browse [API Reference][api-reference] to discover all available managed
-resources.
-
-## Syntax
-
-Crossplane API conventions extend the Kubernetes API conventions for the schema
-of Crossplane managed resources. Following is an example of `RDSInstance`:
-
-```yaml
-apiVersion: database.aws.crossplane.io/v1beta1
-kind: RDSInstance
-metadata:
- name: foodb
-spec:
- forProvider:
- dbInstanceClass: db.t2.small
- masterUsername: root
- allocatedStorage: 20
- engine: mysql
- writeConnectionSecretToRef:
- name: mysql-secret
- namespace: crossplane-system
- providerConfigRef:
- name: default
- reclaimPolicy: Delete
-```
-
-In Kubernetes, `spec` top field represents the desired state of the user.
-Crossplane adheres to that and has its own conventions about how the fields
-under `spec` should look like.
-
-* `writeConnectionSecretToRef`: A reference to the secret that you want this
- managed resource to write its connection secret that you'd be able to mount to
- your pods in the same namespace. For `RDSInstance`, this secret would contain
- `endpoint`, `username` and `password`.
-
-* `providerConfigRef`: Reference to the `ProviderConfig` resource that will
- provide information regarding authentication of Crossplane to the provider.
- `ProviderConfig` resources refer to `Secret` and potentially contain other
- information regarding authentication. The `providerConfigRef` is defaulted to
- a `ProviderConfig` named `default` if omitted.
-
-* `deletionPolicy`: Enum to specify whether the actual cloud resource should be
- deleted when this managed resource is deleted in Kubernetes API server.
- Possible values are `Delete` (the default) and `Orphan`.
-
-* `forProvider`: While the rest of the fields relate to how Crossplane should
- behave, the fields under `forProvider` are solely used to configure the actual
- external resource. In most of the cases, the field names correspond to the
- what exists in provider's API Reference.
-
- The objects under `forProvider` field can get huge depending on the provider
- API. For example, GCP `ServiceAccount` has only a few fields while GCP
- `CloudSQLInstance` has over 100 fields that you can configure.
-
-### Versioning
-
-Crossplane closely follows the [Kubernetes API versioning
-conventions][api-versioning] for the CRDs that it deploys. In short, for
-`vXbeta` and `vX` versions, you can expect that either automatic migration or
-instructions for manual migration will be provided when a new version of that
-CRD schema is released.
-
-### Grouping
-
-In general, managed resources are high fidelity resources meaning they will
-provide parameters and behaviors that are provided by the external resource API.
-This applies to grouping of resources, too. For example, `Queue` appears under
-`sqs` API group in AWS,so, its `APIVersion` and `Kind` look like the following:
-
-```yaml
-apiVersion: sqs.aws.crossplane.io/v1beta1
-kind: Queue
-```
-
-## Behavior
-
-As a general rule, managed resource controllers try not to make any decision
-that is not specified by the user in the desired state since managed resources
-are the lowest level primitives that operate directly on the cloud provider
-APIs.
-
-### Continuous Reconciliation
-
-Crossplane providers continuously reconcile the managed resource to achieve the
-desired state. The parameters under `spec` are considered the one and only
-source of truth for the external resource. This means that if someone changed a
-configuration in the UI of the provider, like AWS Console, Crossplane will
-change it back to what's given under `spec`.
-
-#### Immutable Properties
-
-There are configuration parameters in external resources that cloud providers do
-not allow to be changed. If the corresponding field in the managed resource is
-changed by the user, Crossplane submits the new desired state to the provider
-and returns the error, if any. For example, in AWS, you cannot change the region
-of an `RDSInstance`.
-
-Some infrastructure tools such as Terraform delete and recreate the resource to
-accommodate those changes but Crossplane does not take that route. Unless the
-managed resource is deleted and its `reclaimPolicy` is `Delete`, its controller
-never deletes the external resource in the provider.
-
-> Immutable fields are marked as `immutable` in Crossplane codebase but
-Kubernetes does not yet have immutable field notation in CRDs.
-
-### External Name
-
-By default the name of the managed resource is used as the name of the external
-cloud resource that will show up in your cloud console. To specify a different
-external name, Crossplane has a special annotation to represent the name of the
-external resource. For example, I would like to have a `CloudSQLInstance` with
-an external name that is different than its managed resource name:
-
-```yaml
-apiVersion: database.gcp.crossplane.io/v1beta1
-kind: CloudSQLInstance
-metadata:
- name: foodb
- annotations:
- crossplane.io/external-name: my-special-db
-spec:
- ...
-```
-
-When you create this managed resource, you will see that the name of
-`CloudSQLInstance` in GCP console will be `my-special-db`.
-
-If the annotation is not given, Crossplane will fill it with the name of the
-managed resource by default. In cases where provider doesn't allow you to name
-the resource, like AWS VPC, the controller creates the resource and sets
-external annotation to be the name that the cloud provider chose. So, you would
-see something like `vpc-28dsnh3` as the value of `crossplane.io/external-name`
-annotation of your AWS `VPC` resource even if you added your own custom external
-name during creation.
-
-### Late Initialization
-
-For some of the optional fields, users rely on the default that the cloud
-provider chooses for them. Since Crossplane treats the managed resource as the
-source of the truth, values of those fields need to exist in `spec` of the
-managed resource. So, in each reconciliation, Crossplane will fill the value of
-a field that is left empty by the user but is assigned a value by the provider.
-For example, there could be two fields like `region` and `availabilityZone` and
-you might want to give only `region` and leave the availability zone to be
-chosen by the cloud provider. In that case, if the provider assigns an
-availability zone, Crossplane gets that value and fills `availabilityZone`. Note
-that if the field is already filled, the controller won't override its value.
-
-### Deletion
-
-When a deletion request is made for a managed resource, its controller starts
-the deletion process immediately. However, the managed resource is kept in the
-Kubernetes API (via a finalizer) until the controller confirms the external
-resource in the cloud is gone. So you can be sure that if the managed resource
-is deleted, then the external cloud resource is also deleted. Any errors that
-happen during deletion will be added to the `status` of the managed resource, so
-you can troubleshoot any issues.
-
-## Dependencies
-
-In many cases, an external resource refers to another one for a specific
-configuration. For example, you could want your Azure Kubernetes cluster in a
-specific Virtual Network. External resources have specific fields for these
-relations, however, they usually require the information to be supplied in
-different formats. In Azure MySQL, you might be required to enter only the name
-of the Virtual Network while in Azure Kubernetes, it could be required to enter
-a string in a specific format that includes other information such as resource
-group name.
-
-In Crossplane, users have 3 fields to refer to another resource. Here is an
-example from Azure MySQL managed resource referring to a Azure Resource Group:
-
-```yaml
-spec:
- forProvider:
- resourceGroupName: foo-res-group
- resourceGroupNameRef:
- name: resourcegroup
- resourceGroupNameSelector:
- matchLabels:
- app: prod
-```
-
-In this example, the user provided only a set of labels to select a
-`ResourceGroup` managed resource that already exists in the cluster via
-`resourceGroupNameSelector`. Then after a specific `ResourceGroup` is selected,
-`resourceGroupNameRef` is filled with the name of that `ResourceGroup` managed
-resource. Then in the last step, Crossplane fills the actual `resourceGroupName`
-field with whatever format Azure accepts it. Once a dependency is resolved, the
-controller never changes it.
-
-Users are able to specify any of these three fields:
-
-- Selector to select via labels
-- Reference to point to a determined managed resource
-- Actual value that will be submitted to the provider
-
-It's important to note that in case a reference exists, the managed resource
-does not create the external resource until the referenced object is ready. In
-this example, creation call of Azure MySQL Server will not be made until
-referenced `ResourceGroup` has its `status.condition` named `Ready` to be true.
-
-## Importing Existing Resources
-
-If you have some resources that are already provisioned in the cloud provider,
-you can import them as managed resources and let Crossplane manage them. What
-you need to do is to enter the name of the external resource as well as the
-required fields on the managed resource. For example, let's say I have a GCP
-Network provisioned from GCP console and I would like to migrate it to
-Crossplane. Here is the YAML that I need to create:
-
-```yaml
-apiVersion: compute.gcp.crossplane.io/v1beta1
-kind: Network
-metadata:
- name: foo-network
- annotations:
- crossplane.io/external-name: existing-network
-spec:
- providerConfigRef:
- name: default
-```
-
-Crossplane will check whether a GCP Network called `existing-network` exists,
-and if it does, then the optional fields under `forProvider` will be filled with
-the values that are fetched from the provider.
-
-Note that if a resource has required fields, you must fill those fields or the
-creation of the managed resource will be rejected. So, in those cases, you will
-need to enter the name of the resource as well as the required fields as
-indicated in the [API Reference][api-reference] documentation.
-
-## Backup and Restore
-
-Crossplane adheres to Kubernetes conventions as much as possible and one of the
-advantages we gain is backup & restore ability with tools that work with native
-Kubernetes types, like [Velero][velero].
-
-If you'd like to backup and restore manually, you can simply export them and
-save YAMLs in your file system. When you reload them, as we've discovered in
-import section, their `crosssplane.io/external-name` annotation and required
-fields are there and those are enough to import a resource. The tool you're
-using needs to store `annotations` and `spec` fields, which most tools do
-including Velero.
-
-[api-versioning]: https://kubernetes.io/docs/reference/using-api/api-overview/#api-versioning
-[velero]: https://velero.io/
-[api-reference]: api-docs/overview.md
-[provider]: provider.md
diff --git a/docs/v0.13/introduction/overview.md b/docs/v0.13/introduction/overview.md
deleted file mode 100644
index 6c8b72de..00000000
--- a/docs/v0.13/introduction/overview.md
+++ /dev/null
@@ -1,131 +0,0 @@
----
-title: Introduction
-toc: true
-weight: 100
----
-
-# Overview
-
-Crossplane introduces multiple building blocks that enable you to provision,
-compose, and consume infrastructure using the Kubernetes API. These individual
-concepts work together to allow for powerful separation of concern between
-different personas in an organization, meaning that each member of a team
-interacts with Crossplane at an appropriate level of abstraction.
-
-![Crossplane Concepts]
-
-The diagram above illustrates a common workflow using most of Crossplane's
-functionality.
-
-An infrastructure operator...
-
-1. Installs Crossplane and one or more [providers] (in this case
- [provider-azure]) as [packages]. This enables provisioning of external
- infrastructure from the Kubernetes cluster.
-2. Defines a new `CompositeMySQLInstance` composite resource and a corresponding
- `MySQLInstance` resource claim by authoring a `CompositeResourceDefinition`.
-3. Creates a `Composition` that instructs Crossplane how to render one or more
- managed resources installed by providers in response to the creation of the
- composite resource. In this case the `Composition` specifies that Azure
- `MySQLServer` and `MySQLFirewallRule` [managed resources] should be created
- to satisfy a `CompositeMySQLInstance`.
-
-An application developer...
-
-1. Creates an [OAM] `Component` for their service that specifies that they wish
- to be run as an OAM `ContainerizedWorkload`.
-2. Creates an OAM `Component` for their MySQL database that can be satisfied by
- the `MySQLInstance` resource claim.
-
-An application operator...
-
-1. Creates an OAM `ApplicationConfiguration`, which is comprised of the two
- `Component` types that were defined by the application developer, and a
- `ManualScalerTrait` trait to modify the replicas in the
- `ContainerizedWorkload`. In response, Crossplane translates the OAM types
- into Kubernetes-native types, in this case a `Deployment` and `Service` for
- the `ContainerizedWorkload` component, and a `MySQLServer` and
- `MySQLFirewallRule` for the `MySQLInstance` component.
-2. Crossplane provisions the external infrastructure and makes the connection
- information available to the application, allowing it to connect to and
- consume the MySQL database on Azure.
-
-The concepts used in this workflow are explained in greater detail below and in
-their individual documentation.
-
-## Packages
-
-Packages allow Crossplane to be extended to include new functionality. This
-typically looks like bundling a set of Kubernetes [CRDs] and [controllers] that
-represent and manage external infrastructure (i.e. a provider), then installing
-them into a cluster where Crossplane is running. Crossplane handles making sure
-any new CRDs do not conflict with existing ones, as well as manages the RBAC and
-security of new packages. Packages are not strictly required to be providers,
-but it is the most common use-case for packages at this time.
-
-## Providers
-
-Providers are packages that enable Crossplane to provision infrastructure on an
-external service. They bring CRDs (i.e. managed resources) that map one-to-one
-to external infrastructure resources, as well as controllers to manage the
-life-cycle of those resources. You can read more about providers, including how
-to install and configure them, in the [providers documentation].
-
-## Managed Resources
-
-Managed resources are Kubernetes custom resources that represent infrastructure
-primitives. Managed resources with an API version of `v1beta1` or higher support
-every field that the cloud provider does for the given resource. You can find
-the Managed Resources and their API specifications for each provider on
-[doc.crds.dev] and learn more in the [managed resource documentation].
-
-## Composite Resources
-
-A composite resource (XR) is a special kind of custom resource that is defined
-by a `CompositeResourceDefinition`. It composes one or more managed resources
-into a higher level infrastructure unit. Composite resources are infrastructure
-operator facing, but may optionally offer an application developer facing
-composite resource claim that acts as a proxy for a composite resource. You can
-learn more about all of these concepts in the [composition documentation].
-
-## OAM
-
-Crossplane supports application management as the Kubernetes implementation of
-the [Open Application Model]. As such, Crossplane currently implements the
-following OAM API types as Kubernetes custom resources.
-
-* `WorkloadDefinition`: defines the kind of components that an application
- developer can use in an application, along with the component's schema.
- * Crossplane also implements the core `ContainerizedWorkload` type.
- Infrastructure owners may define any resource as a workload type by
- referencing it in a `WorkloadDefinition`.
-* `Component`: describe functional units that may be instantiated as part of a
- larger distributed application. For example, each micro-service in an
- application is described as a `Component`.
-* `Trait`: a discretionary runtime overlay that augments a component workload
- type with additional features. It represents an opportunity for those in the
- application operator role to make specific decisions about the configuration
- of components, without having to involve the developer.
- * Crossplane also implements the core `ManualScalerTrait` type.
-* `ApplicationConfiguration`: includes one or more component instances, each
- represented by a component definition that defines how an instance of a
- component spec should be deployed.
-
-For more information, take a look at the [OAM documentation].
-
-
-
-[Crossplane Concepts]: crossplane-concepts.png
-[providers]: #providers
-[provider-azure]: https://github.com/crossplane/provider-azure
-[packages]: #packages
-[managed resources]: #managed-resources
-[OAM]: #oam
-[CRDs]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[controllers]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-controllers
-[providers documentation]: providers.md
-[doc.crds.dev]: https://doc.crds.dev
-[managed resources documentation]: managed-resources.md
-[composition documentation]: composition.md
-[Open Application Model]: https://oam.dev/
-[OAM documentation]: oam.md
diff --git a/docs/v0.13/introduction/packages.md b/docs/v0.13/introduction/packages.md
deleted file mode 100644
index 8e383bf9..00000000
--- a/docs/v0.13/introduction/packages.md
+++ /dev/null
@@ -1,256 +0,0 @@
----
-title: Packages
-toc: true
-weight: 104
-indent: true
----
-
-# Crossplane Packages
-
-Crossplane packages are opinionated [OCI images] that contain a stream of YAML
-that can be parsed by the Crossplane package manager. Crossplane packages come
-in two varieties: [Providers] and Configurations. Ultimately, the primary
-purposes of Crossplane packages are as follows:
-
-- **Convenient Distribution**: Crossplane packages can be pushed to or installed
- from any OCI-compatible registry.
-- **Version Upgrade**: Crossplane can update packages in-place, meaning that you
- can pick up support for new resource types or controller bug-fixes without
- modifying your existing infrastructure.
-- **Permissions**: Crossplane allocates permissions to packaged controllers in a
- manner that ensures they will not maliciously take over control of existing
- resources owned by other packages. Installing CRDs via packages also allows
- Crossplane itself to manage those resources, allowing for powerful
- [composition] features to be enabled.
-- **Dependency Management**: In future releases, Crossplane will be able to
- resolve dependencies between packages, automatically installing a package's
- dependencies if they are not present in the cluster.
-
-## Building a Package
-
-As stated above, Crossplane packages are just opinionated OCI images, meaning
-they can be constructed using any tool that outputs files that comply the the
-OCI specification. However, constructing packages using the Crossplane CLI is a
-more streamlined experience, as it will perform build-time checks on your
-packages to ensure that they are compliant with the Crossplane [package format].
-
-Providers and Configurations vary in the types of resources they may contain in
-their packages. All packages must have a `crossplane.yaml` file in the root
-directory with package contents. The `crossplane.yaml` contains the package's
-metadata, which governs how Crossplane will install the package.
-
-### Provider Packages
-
-A Provider package contains a `crossplane.yaml` with the following format:
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Provider
-metadata:
- name: provider-gcp
-spec:
- controller:
- image: crossplane/provider-gcp-controller:master
-```
-
-> Note: The `meta.pkg.crossplane.io` group does contain custom resources that
-> may be installed into the cluster. They are strictly used as metadata in a
-> Crossplane package.
-
-The `spec.controller.image` fields specifies that the `Provider` desires for a
-`Deployment` to be created with the provided image. It is important to note that
-this image is separate from the package image itself. In the case above, it is
-an image containing the `provider-gcp` controller binary.
-
-A Provider package may optionally contain one or more CRDs. These CRDs will be
-installed prior to the creation of the Provider's `Deployment`. Crossplane will
-not install _any_ CRDs for a package unless it can determine that _all_ CRDs can
-be installed. This guards against multiple Providers attempting to reconcile the
-same CRDs. Crossplane will also create a `ServiceAccount` with permissions to
-reconcile these CRDs and it will be assigned to the controller `Deployment`.
-
-For an example Provider package, see [provider-gcp].
-
-To build a Provider package, navigate to the package root directory and execute
-the following command:
-
-```
-kubectl crossplane build provider
-```
-
-If the Provider package is valid, you will see a file with the `.xpkg`
-extension.
-
-### Configuration Packages
-
-A Configuration package contains a `crossplane.yaml` with the following format:
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: my-org-infra
-```
-
-Currently, the only purpose of a Configuration's `crossplane.yaml` is to declare
-that it is in fact a Configuration package type. However, future releases will
-include additional fields for functionality such as specifying dependencies on
-Provider packages.
-
-A Configuration package may also specify one or more of
-`CompositeResourceDefinition` and `Composition` types. These resources will be
-installed and will be solely owned by the Configuration package. No other
-package will be able to modify them.
-
-To build a Configuration package, navigate to the package root directory and
-execute the following command:
-
-```
-kubectl crossplane build configuration
-```
-
-If the Provider package is valid, you will see a file with the `.xpkg`
-extension.
-
-## Pushing a Package
-
-Crossplane packages can be pushed to any OCI-compatible registry. If a specific
-registry is not specified they will be pushed to Docker Hub.
-
-To push a Provider package, execute the following command:
-
-```
-kubectl crossplane push provider crossplane/provider-gcp:master
-```
-
-To push a Configuration package, execute the following command:
-
-```
-kubectl crossplane push configuration crossplane/my-org-infra:master
-```
-
-> Note: Both of the above commands assume a single `.xpkg` file exists in the
-> directory. If multiple exist or you would like to specify a package in a
-> different directory, you can supply the `-f` flag with the path to the
-> package.
-
-## Installing a Package
-
-Packages can be installed into a Crossplane cluster using the Crossplane CLI.
-
-To install a Provider package, execute the following command:
-
-```
-kubectl crossplane install provider crossplane/provider-gcp:master
-```
-
-To install a Configuration package, execute the following command:
-
-```
-kubectl crossplane install configuration crossplane/my-org-infra:master
-```
-
-Packages can also be installed manually by creating a `Provider` or
-`Configuration` object directly. The preceding commands would result in the
-creation of the following two resources, which could have been authored by hand:
-
-```yaml
-apiVersion: pkg.crossplane.io/v1alpha1
-kind: Provider
-metadata:
- name: provider-gcp
-spec:
- package: crossplane/provider-gcp:master
- revisionActivationPolicy: Automatic
- revisionHistoryLimit: 1
-```
-
-```yaml
-apiVersion: pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: provider-gcp
-spec:
- package: crossplane/provider-gcp:master
- revisionActivationPolicy: Automatic
- revisionHistoryLimit: 1
-```
-
-> Note: These types differ from the `Provider` and `Configuration` types we saw
-> earlier. They exist in the `pkg.crossplane.io` group rather than the
-> `meta.pkg.crossplane.io` group and are actual custom resources created in the
-> cluster.
-
-The `spec.revisionActivationPolicy` and `spec.revisionHistoryLimit` fields are
-explained in the following section.
-
-## Upgrading a Package
-
-Once a package is installed, Crossplane makes it easy to upgrade to a new
-version. Controlling this functionality is accomplished via the three `spec`
-fields shown above. They are explained in detail below.
-
-### spec.package
-
-This is the package image that we built, pushed, and are asking Crossplane to
-install. The tag we specify here is important. Crossplane will periodically
-check if the installed image matches the digest of the image in the remote
-registry. If it does not, Crossplane will create a new _Revision_ (either
-`ProviderRevision` or `ConfigurationRevision`). If you do not wish Crossplane to
-ever update your packages without explicitly instructing it to do so, you should
-consider specifying a tag which you know will not have the underlying contents
-change unexpectedly (e.g. a specific semantic version, such as `v0.1.0`) or, for
-an even stronger guarantee, providing the image with a `@sha256` extension
-instead of a tag.
-
-### spec.revisionActivationPolicy
-
-Valid values: `Automatic` or `Manual` (default: `Automatic`)
-
-This field determines what Crossplane does when a new revision is created, be it
-manually by you specifying a new tag in the `spec.package` field, or
-automatically if a general tag such as `latest` or `master` is used and the
-underlying contents change. When a new revision is created for a package, it can
-either be `Active` or `Inactive`.
-
-An `Active` package revision attempts to become the _controller_ of all
-resources it installs. There can only be one controller of a resource, so if two
-`Active` revisions both install the same resource, one will fail to install
-until the other cedes control.
-
-An `Inactive` package revision attempts to become the _owner_ of all resource it
-installs. There can be an arbitrary number of owners of a resource, so multiple
-`Inactive` revisions and a single `Active` revision can exist for a resource.
-Importantly, an `Inactive` package revision will not perform any auxiliary
-actions (such as creating a `Deployment` in the case of a `Provider`), meaning
-we will not encounter a situation where two revisions are fighting over
-reconciling a resource.
-
-### spec.revisionHistoryLimit
-
-Valid values: any integer, disabled by explicitly setting to `0` (default `1`)
-
-When a revision transitions from `Inactive` to `Active`, its revision number
-gets set to one greater than the largest revision number of all revisions for
-its package. Therefore, as the number of revisions increases, the least recently
-`Active` revision will have the lowest revision number. Crossplane will garbage
-collect old `Inactive` revisions if they fall outside the
-`spec.revisionHistoryLimit`. For instance, if my revision history limit is `3`
-and I currently have three old `Inactive` revisions and one `Active` revision,
-when I upgrade the next time, the new revision will be given the highest
-revision number when it becomes `Active`, the previously `Active` revision will
-become `Inactive`, and the oldest `Inactive` revision will be garbage collected.
-
-> Note: In the case that `spec.revisionActivationPolicy: Manual` and you upgrade
-> enough times (but do not make `Active` the new revisions), it is possible that
-> activating a newer revision could cause the previously `Active` revision to
-> immediately be garbage collected if it is outside the
-> `spec.revisionHistoryLimit`.
-
-
-
-[OCI images]: https://github.com/opencontainers/image-spec
-[Providers]: providers.md
-[composition]: composition.md
-[package format]: https://github.com/crossplane/crossplane/blob/1aa83092172bdf0d2ed64754d33517c612ff7368/design/one-pager-package-format-v2.md
-[provider-gcp]: https://github.com/crossplane/provider-gcp/tree/master/package
diff --git a/docs/v0.13/introduction/providers.md b/docs/v0.13/introduction/providers.md
deleted file mode 100644
index 510789e0..00000000
--- a/docs/v0.13/introduction/providers.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-title: Providers
-toc: true
-weight: 101
-indent: true
----
-
-# Providers
-
-Providers extend Crossplane to enable infrastructure resource provisioning. In
-order to provision a resource, a Custom Resource Definition (CRD) needs to be
-registered in your Kubernetes cluster and its controller should be watching the
-Custom Resources those CRDs define. Provider packages contain many Custom
-Resource Definitions and their controllers.
-
-Here is the list of current providers:
-
-### AWS Provider
-
-* [GitHub][provider-aws]
-* [API Reference][aws-reference]
-
-### GCP Provider
-
-* [GitHub][provider-gcp]
-* [API Reference][gcp-reference]
-
-### Azure Provider
-
-* [GitHub][provider-azure]
-* [API Reference][azure-reference]
-
-### Rook Provider
-
-* [GitHub][provider-rook]
-* [API Reference][rook-reference]
-
-### Alibaba Cloud Provider
-
-* [GitHub][provider-alibaba]
-* [API Reference][alibaba-reference]
-
-## Installing Providers
-
-The core Crossplane controller can install provider controllers and CRDs for you
-through its own provider packaging mechanism, which is triggered by the
-application of a `Provider` resource. For example, in order to request
-installation of the `provider-aws` package, apply the following resource to the
-cluster where Crossplane is running:
-
-```yaml
-apiVersion: pkg.crossplane.io/v1alpha1
-kind: Provider
-metadata:
- name: provider-aws
-spec:
- package: crossplane/provider-aws:master"
-```
-
-The field `spec.package` is where you refer to the container image of the
-provider. Crossplane Package Manager will unpack that container, register CRDs
-and set up necessary RBAC rules and then start the controllers.
-
-There are a few other ways to to trigger the installation of provider packages:
-
-* As part of Crossplane Helm chart by adding the following statement to your
- `helm install` command: `--set
- provider.packages={crossplane/provider-aws:master}`.
-* Using the Crossplane CLI: `kubectl crossplane install provider
- crossplane/provider-aws:master`
-
-You can uninstall a provider by deleting the `ClusterPackageInstall` resource
-you've created.
-
-## Configuring Providers
-
-In order to authenticate with the external provider API, the provider
-controllers need to have access to credentials. It could be an IAM User for AWS,
-a Service Account for GCP or a Service Principal for Azure. Every provider has a
-type called `ProviderConfig` that has information about how to authenticate to
-the provider API. An example `ProviderConfig` resource for AWS looks like the
-following:
-
-```yaml
-apiVersion: aws.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: aws-provider
-spec:
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: aws-creds
- key: key
-```
-
-You can see that there is a reference to a key in a specific `Secret`. The value
-of that key should contain the credentials that the controller will use. The
-documentation of each provider should give you an idea of how that credentials
-blob should look like. See [Getting Started][getting-started] guide for more
-details.
-
-The following is an example usage of Azure `ProviderConfig`, referenced by a
-`RDSInstance`:
-
-```yaml
-apiVersion: database.aws.crossplane.io/v1beta1
-kind: RDSInstance
-metadata:
- name: prod-sql
-spec:
- providerConfigRef: prod-acc
- ...
-```
-
-The AWS provider controller will use that provider for this instance of
-`RDSInstance`. Since every resource has its own reference to a `ProviderConfig`,
-you can have multiple `ProviderConfig` resources in your cluster referenced by
-different resources. When no `providerConfigRef` is specified, the `RDSInstance`
-will attempt to use a `ProviderConfig` named `default`.
-
-
-
-[provider-aws]: https://github.com/crossplane/provider-aws
-[aws-reference]: https://doc.crds.dev/github.com/crossplane/provider-aws
-[provider-gcp]: https://github.com/crossplane/provider-gcp
-[gcp-reference]: https://doc.crds.dev/github.com/crossplane/provider-gcp
-[provider-azure]: https://github.com/crossplane/provider-azure
-[azure-reference]: https://doc.crds.dev/github.com/crossplane/provider-azure
-[provider-rook]: https://github.com/crossplane/provider-rook
-[rook-reference]: https://doc.crds.dev/github.com/crossplane/provider-rook
-[provider-alibaba]: https://github.com/crossplane/provider-alibaba
-[alibaba-reference]: https://doc.crds.dev/github.com/crossplane/provider-alibaba
-[getting-started]: ../getting-started/install-configure.md
diff --git a/docs/v0.13/media/arch.png b/docs/v0.13/media/arch.png
deleted file mode 100644
index 8205e62e..00000000
Binary files a/docs/v0.13/media/arch.png and /dev/null differ
diff --git a/docs/v0.13/media/banner.png b/docs/v0.13/media/banner.png
deleted file mode 100644
index 0a495e1d..00000000
Binary files a/docs/v0.13/media/banner.png and /dev/null differ
diff --git a/docs/v0.13/media/crossplane-overview.png b/docs/v0.13/media/crossplane-overview.png
deleted file mode 100644
index 87c25a89..00000000
Binary files a/docs/v0.13/media/crossplane-overview.png and /dev/null differ
diff --git a/docs/v0.13/media/logo.svg b/docs/v0.13/media/logo.svg
deleted file mode 100644
index 3af90369..00000000
--- a/docs/v0.13/media/logo.svg
+++ /dev/null
@@ -1,310 +0,0 @@
-
-
-
diff --git a/docs/v0.13/reference/configure.md b/docs/v0.13/reference/configure.md
deleted file mode 100644
index 45c4934c..00000000
--- a/docs/v0.13/reference/configure.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Configure
-toc: true
-weight: 302
-indent: true
----
-
-# Configure Your Cloud Provider Account
-
-In order for Crossplane to be able to manage resources in a specific cloud
-provider, you will need to create an account for Crossplane to use. Use the
-links below for cloud-specific instructions to create an account that can be
-used throughout the guides:
-
-* [Google Cloud Platform (GCP) Service Account]
-* [Microsoft Azure Service Principal]
-* [Amazon Web Services (AWS) IAM User]
-
-Once you have configured your cloud provider account, you can get started
-provisioning resources!
-
-
-
-[Google Cloud Platform (GCP) Service Account]: ../cloud-providers/gcp/gcp-provider.md
-[Microsoft Azure Service Principal]: ../cloud-providers/azure/azure-provider.md
-[Amazon Web Services (AWS) IAM User]: ../cloud-providers/aws/aws-provider.md
diff --git a/docs/v0.13/reference/install.md b/docs/v0.13/reference/install.md
deleted file mode 100644
index 8e82487d..00000000
--- a/docs/v0.13/reference/install.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: Install
-toc: true
-weight: 301
-indent: true
----
-
-# Install Crossplane
-
-Crossplane can be easily installed into any existing Kubernetes cluster using
-the regularly published Helm chart. The Helm chart contains all the custom
-resources and controllers needed to deploy and configure Crossplane.
-
-## Pre-requisites
-
-* [Kubernetes cluster], minimum version `v1.15.0+`
-* [Helm], minimum version `v3.0.0+`.
-
-## Installation
-
-Helm charts for Crossplane are currently published to the `alpha` and `master`
-channels. In the future, `beta` and `stable` will also be available.
-
-### Alpha
-
-The alpha channel is the most recent release of Crossplane that is considered
-ready for testing by the community.
-
-```console
-kubectl create namespace crossplane-system
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-### Master
-
-The `master` channel contains the latest commits, with all automated tests
-passing. `master` is subject to instability, incompatibility, and features may
-be added or removed without much prior notice. It is recommended to use one of
-the more stable channels, but if you want the absolute newest Crossplane
-installed, then you can use the `master` channel.
-
-To install the Helm chart from master, you will need to pass the specific
-version returned by the `search` command:
-
-```console
-kubectl create namespace crossplane-system
-helm repo add crossplane-master https://charts.crossplane.io/master/
-helm search repo crossplane-master --devel
-
-helm install crossplane --namespace crossplane-system crossplane-master/crossplane --devel --version
-```
-
-## Uninstalling the Chart
-
-To uninstall/delete the `crossplane` deployment:
-
-```console
-helm delete crossplane --namespace crossplane-system
-```
-
-That command removes all Kubernetes components associated with Crossplane,
-including all the custom resources and controllers.
-
-## Configuration
-
-The following tables lists the configurable parameters of the Crossplane chart
-and their default values.
-
-| Parameter | Description | Default |
-| --- | --- | --- |
-| `image.repository` | Image | `crossplane/crossplane` |
-| `image.tag` | Image tag | `master` |
-| `image.pullPolicy` | Image pull policy | `Always` |
-| `imagePullSecrets` | Names of image pull secrets to use | `dockerhub` |
-| `replicas` | The number of replicas to run for the Crossplane and RBAC Manager (if enabled) pods | `1` |
-| `deploymentStrategy` | The deployment strategy for the Crossplane and RBAC Manager (if enabled) pods | `RollingUpdate` |
-| `priorityClassName` | Priority class name for Crossplane and RBAC Manager (if enabled) pods | `""` |
-| `resourcesCrossplane.limits.cpu` | CPU resource limits for Crossplane | `100m` |
-| `resourcesCrossplane.limits.memory` | Memory resource limits for Crossplane | `512Mi` |
-| `resourcesCrossplane.requests.cpu` | CPU resource requests for Crossplane | `100m` |
-| `resourcesCrossplane.requests.memory` | Memory resource requests for Crossplane | `256Mi` |
-| `packageCache.medium` | Storage medium for package cache. `Memory` means volume will be backed by tmpfs, which can be useful for development. | `""` |
-| `packageCache.sizeLimit` | Size limit for package cache. If medium is `Memory` then maximum usage would be the minimum of this value the sum of all memory limits on containers in the Crossplane pod. | `5Mi` |
-| `packageCache.pvc` | Name of the PersistentVolumeClaim to be used as the package cache. Providing a value will cause the default emptyDir volume to not be mounted. | `""` |
-| `resourcesRBACManager.limits.cpu` | CPU resource limits for RBAC Manager | `100m` |
-| `resourcesRBACManager.limits.memory` | Memory resource limits for RBAC Manager | `512Mi` |
-| `resourcesRBACManager.requests.cpu` | CPU resource requests for RBAC Manager | `100m` |
-| `resourcesRBACManager.requests.memory` | Memory resource requests for RBAC Manager | `256Mi` |
-| `rbacManager.deploy` | Deploy RBAC Manager and its required roles | `true` |
-| `rbacManager.managementPolicy`| The extent to which the RBAC manager will manage permissions. `All` indicates to manage all Crossplane controller and user roles. `Basic` indicates to only manage Crossplane controller roles and the `crossplane-admin`, `crossplane-edit`, and `crossplane-view` user roles. | `All` |
-| `alpha.oam.enabled` | Deploy the `crossplane/oam-kubernetes-runtime` Helm chart | `false` |
-| `provider.packages` | The list of Provider packages to install together with Crossplane | `[]` |
-
-### Command Line
-
-You can pass the settings with helm command line parameters. Specify each
-parameter using the `--set key=value[,key=value]` argument to `helm install`.
-For example, the following command will install Crossplane with an image pull
-policy of `IfNotPresent`.
-
-```console
-helm install --namespace crossplane-system crossplane-alpha/crossplane --set image.pullPolicy=IfNotPresent
-```
-
-### Settings File
-
-Alternatively, a yaml file that specifies the values for the above parameters
-(`values.yaml`) can be provided while installing the chart.
-
-```console
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane -f values.yaml
-```
-
-Here are the sample settings to get you started.
-
-```yaml
-replicas: 1
-
-deploymentStrategy: RollingUpdate
-
-image:
- repository: crossplane/crossplane
- tag: alpha
- pullPolicy: Always
-
-imagePullSecrets:
-- dockerhub
-```
-
-
-
-[Kubernetes cluster]: https://kubernetes.io/docs/setup/
-[Minikube]: https://kubernetes.io/docs/tasks/tools/install-minikube/
-[Helm]: https://docs.helm.sh/using_helm/
diff --git a/docs/v0.13/reference/learn_more.md b/docs/v0.13/reference/learn_more.md
deleted file mode 100644
index 75bd883e..00000000
--- a/docs/v0.13/reference/learn_more.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: Learn More
-toc: true
-weight: 304
-indent: true
----
-
-# Learn More
-
-If you have any questions, please drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us]!
-
-***Learn more about using Crossplane***
- - [Latest Design Docs](https://github.com/crossplane/crossplane/tree/master/design)
- - [Roadmap](https://github.com/crossplane/crossplane/blob/master/ROADMAP.md)
- - [Crossplane Architecture](https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit?usp=sharing)
- - [GitLab deploys into multiple clouds from kubectl using Crossplane](https://about.gitlab.com/2019/05/20/gitlab-first-deployed-kubernetes-api-to-multiple-clouds/)
- - [CNCF Talks & Community Presentations](https://www.youtube.com/playlist?list=PL510POnNVaaZJj9OG6PbgsZvgYbhwJRyE)
- - [Software Engineering Daily - Intro Podcast](https://softwareengineeringdaily.com/2019/01/02/crossplane-multicloud-control-plane-with-bassam-tabbara/)
-
-***Writing Kubernetes controllers to extend Crossplane***
- - [Keep the Space Shuttle Flying: Writing Robust Operators](https://www.youtube.com/watch?v=uf97lOApOv8)
- - [Best practices for building Kubernetes Operators](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)
- - [Programming Kubernetes Book](https://www.oreilly.com/library/view/programming-kubernetes/9781492047094/)
- - [Contributor Guide](https://github.com/crossplane/crossplane/blob/master/CONTRIBUTING.md)
-
-***Join the growing Crossplane community and get involved!***
-- Join our [Community Slack](https://slack.crossplane.io/)!
-- Submit an issue on [GitHub](https://github.com/crossplane/crossplane)
-- Attend our bi-weekly [Community Meeting](https://github.com/crossplane/crossplane#community-meeting)
-- Join our bi-weekly live stream: [The Binding Status](https://github.com/crossplane/tbs)
-- Subscribe to our [YouTube Channel](https://www.youtube.com/channel/UC19FgzMBMqBro361HbE46Fw)
-- Drop us a note on Twitter: [@crossplane_io](https://twitter.com/crossplane_io)
-- Email us: [info@crossplane.io](mailto:info@crossplane.io)
-
-
-
-[join-crossplane-slack]: https://slack.crossplane.io
-[contact-us]: https://github.com/crossplane/crossplane#contact
diff --git a/docs/v0.13/reference/overview.md b/docs/v0.13/reference/overview.md
deleted file mode 100644
index 9f3a4a15..00000000
--- a/docs/v0.13/reference/overview.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Reference
-toc: true
-weight: 300
----
-
-# Overview
-
-The reference documentation includes answers to frequently asked questions, information about similar projects, and links to resources that can help you learn more about Crossplane and Kubernetes. If you have additional information that you think would be valuable for the community, please feel free to [open a pull request]() and add it.
-
-1. [Install]
-1. [Configure]
-1. [Troubleshoot]
-1. [Learn More]
-
-
-
-[Install]: install.md
-[Configure]: configure.md
-[Troubleshoot]: troubleshoot.md
-[Learn More]: learn_more.md
diff --git a/docs/v0.13/reference/troubleshoot.md b/docs/v0.13/reference/troubleshoot.md
deleted file mode 100644
index 8b5ee2d9..00000000
--- a/docs/v0.13/reference/troubleshoot.md
+++ /dev/null
@@ -1,144 +0,0 @@
----
-title: Troubleshoot
-toc: true
-weight: 303
-indent: true
----
-
-# Troubleshooting
-
-* [Using the trace command]
-* [Resource Status and Conditions]
-* [Crossplane Logs]
-* [Pausing Crossplane]
-* [Deleting a Resource Hangs]
-
-## Using the trace command
-
-The [Crossplane CLI] trace command provides a holistic view for a particular
-object and related ones to ease debugging and troubleshooting process. It finds
-the relevant Crossplane resources for a given one and provides detailed
-information as well as an overview indicating what could be wrong.
-
-Usage:
-```
-kubectl crossplane trace TYPE[.GROUP] NAME [-n| --namespace NAMESPACE] [--kubeconfig KUBECONFIG] [-o| --outputFormat dot]
-```
-
-Examples:
-```
-# Trace a KubernetesApplication
-kubectl crossplane trace KubernetesApplication wordpress-app-83f04457-0b1b-4532-9691-f55cf6c0da6e -n app-project1-dev
-
-# Trace a MySQLInstance
-kubectl crossplane trace MySQLInstance wordpress-mysql-83f04457-0b1b-4532-9691-f55cf6c0da6e -n app-project1-dev
-```
-
-For more information, see [the trace command documentation].
-
-## Resource Status and Conditions
-
-Most Crossplane resources have a `status` section that can represent the current
-state of that particular resource. Running `kubectl describe` against a
-Crossplane resource will frequently give insightful information about its
-condition. For example, to determine the status of a MySQLInstance resource
-claim, run:
-
-```shell
-kubectl -n app-project1-dev describe mysqlinstance mysql-claim
-```
-
-This should produce output that includes:
-
-```console
-Status:
- Conditions:
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Managed claim is waiting for managed resource to become bindable
- Status: False
- Type: Ready
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Successfully reconciled managed resource
- Status: True
- Type: Synced
-```
-
-Most Crossplane resources set exactly two condition types; `Ready` and `Synced`.
-`Ready` represents the availability of the resource itself - whether it is
-creating, deleting, available, unavailable, binding, etc. `Synced` represents
-the success of the most recent attempt to 'reconcile' the _desired_ state of the
-resource with its _actual_ state. The `Synced` condition is the first place you
-should look when a Crossplane resource is not behaving as expected.
-
-## Crossplane Logs
-
-The next place to look to get more information or investigate a failure would be
-in the Crossplane pod logs, which should be running in the `crossplane-system`
-namespace. To get the current Crossplane logs, run the following:
-
-```shell
-kubectl -n crossplane-system logs -lapp=crossplane
-```
-
-Remember that much of Crossplane's functionality is provided by Stacks. You can
-use `kubectl logs` to view Stack logs too, though Stacks may not run in the
-`crossplane-system` namespace.
-
-## Pausing Crossplane
-
-Sometimes, for example when you encounter a bug. it can be useful to pause
-Crossplane if you want to stop it from actively attempting to manage your
-resources. To pause Crossplane without deleting all of its resources, run the
-following command to simply scale down its deployment:
-
-```bash
-kubectl -n crossplane-system scale --replicas=0 deployment/crossplane
-```
-
-Once you have been able to rectify the problem or smooth things out, you can
-unpause Crossplane simply by scaling its deployment back up:
-
-```bash
-kubectl -n crossplane-system scale --replicas=1 deployment/crossplane
-```
-
-Remember that much of Crossplane's functionality is provided by Stacks. You can
-use `kubectl scale` to pause Stack pods too, though Stacks may not run in the
-`crossplane-system` namespace.
-
-## Deleting a Resource Hangs
-
-The resources that Crossplane manages will automatically be cleaned up so as not
-to leave anything running behind. This is accomplished by using finalizers, but
-in certain scenarios the finalizer can prevent the Kubernetes object from
-getting deleted.
-
-To deal with this, we essentially want to patch the object to remove its
-finalizer, which will then allow it to be deleted completely. Note that this
-won't necessarily delete the external resource that Crossplane was managing, so
-you will want to go to your cloud provider's console and look there for any
-lingering resources to clean up.
-
-In general, a finalizer can be removed from an object with this command:
-
-```console
-kubectl patch -p '{"metadata":{"finalizers": []}}' --type=merge
-```
-
-For example, for a Workload object (`workloads.compute.crossplane.io`) named
-`test-workload`, you can remove its finalizer with:
-
-```console
-kubectl patch workloads.compute.crossplane.io test-workload -p '{"metadata":{"finalizers": []}}' --type=merge
-```
-
-
-
-[Using the trace command]: #using-the-trace-command
-[Resource Status and Conditions]: #resource-status-and-conditions
-[Crossplane Logs]: #crossplane-logs
-[Pausing Crossplane]: #pausing-crossplane
-[Deleting a Resource Hangs]: #deleting-a-resource-hangs
-[Crossplane CLI]: https://github.com/crossplane/crossplane-cli
-[the trace command documentation]: https://github.com/crossplane/crossplane-cli/tree/master/docs/trace-command.md
-[Owner References]: https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents
diff --git a/docs/v0.13/release/release-process.md b/docs/v0.13/release/release-process.md
deleted file mode 100644
index 58950e17..00000000
--- a/docs/v0.13/release/release-process.md
+++ /dev/null
@@ -1,483 +0,0 @@
-# Release Process
-
-This document is meant to be a complete end-to-end guide for how to release new
-versions of software for Crossplane and its related projects.
-
-## tl;dr Process Overview
-
-All the details are available in the sections below, but we'll start this guide
-with a very high level sequential overview for how to run the release process.
-
-1. **feature freeze**: Merge all completed features into master branches of all
- repos to begin "feature freeze" period
-1. **API docs/user guides**: Regenerate API docs and update all user guides with
- current content for scenarios included in the release
-1. **release crossplane-runtime**: Tag and release a new version of
- crossplane-runtime using the GitHub UI.
-1. **pin crossplane dependencies**: Update the go modules of core crossplane in
- master to depend on the newly released version of crossplane-runtime.
-1. **pre-release tag crossplane**: Run tag pipeline to tag the start of
- pre-releases in master in the crossplane repo
-1. **branch crossplane**: Create a new release branch using the GitHub UI for
- the crossplane repo
-1. **crossplane release branch prep**: In Crossplane's release branch, update
- all examples, docs, and integration tests to update references and versions,
- including the yet to be released versions of providers and stacks.
-1. **tag**: Run the tag pipeline to tag Crossplane's release branch with an
- official semver
-1. **release providers**: Run the release process for each **provider** that we
- maintain
- 1. **pin dependencies**: Update the go modules of each provider repo to
- depend on the new version of crossplane and crossplane-runtime.
- 1. **pre-release tag**: Run tag pipeline to tag the start of pre-releases in
- **master** of each provider repo
- 1. **branch**: Create a new release branch using the GitHub UI for the
- provider repo
- 1. **release branch prep**: In the release branch, update all examples,
- docs, and integration tests to update references and versions
- 1. **test** Test builds from the release branch, fix any critical bugs that
- are found
- 1. **tag**: Run the tag pipeline to tag the release branch with an official
- semver
- 1. **build/publish**: Run build pipeline to publish build with official
- semver
-1. **release template stacks**: Run the release process for each **template
- stack** that we maintain. Note that the process for template stacks is
- slightly different from the stack release process.
- 1. **test** Test builds from the release branch (typically `master`), fix
- any critical bugs that are found
- 1. **version**: Update all version information in the docs, as appropriate
- 1. **tag**: Run the tag pipeline to tag the release branch with an official
- semver
- 1. **build/publish**: Run the publish pipeline to publish build with
- official semver
-1. **build/publish**: Run build pipeline to publish Crossplane build from
- release branch with official semver
-1. **verify**: Verify all artifacts have been published successfully, perform
- sanity testing
-1. **promote**: Run promote pipelines on all repos to promote releases to
- desired channel(s)
-1. **release notes**: Publish well authored and complete release notes on GitHub
-1. **announce**: Announce the release on Twitter, Slack, etc.
-
-## Detailed Process
-
-This section will walk through the release process in more fine grained and
-prescriptive detail.
-
-### Scope
-
-This document will cover the release process for all of the repositories that
-the Crossplane team maintains and publishes regular versioned artifacts from.
-This set of repositories covers both core Crossplane and the set of Providers,
-Stacks, and Apps that Crossplane currently maintains:
-
-* [`crossplane`](https://github.com/crossplane/crossplane)
-* [`provider-gcp`](https://github.com/crossplane/provider-gcp)
-* [`provider-aws`](https://github.com/crossplane/provider-aws)
-* [`provider-azure`](https://github.com/crossplane/provider-azure)
-* [`provider-rook`](https://github.com/crossplane/provider-rook)
-* [`stack-minimal-gcp`](https://github.com/crossplane/stack-minimal-gcp)
-* [`stack-minimal-aws`](https://github.com/crossplane/stack-minimal-aws)
-* [`stack-minimal-azure`](https://github.com/crossplane/stack-minimal-azure)
-* [`app-wordpress`](https://github.com/crossplane/app-wordpress)
-
-The release process for Providers is almost identical to that of core Crossplane
-because they use the same [shared build
-logic](https://github.com/upbound/build/). The steps in this guide will apply
-to all repositories listed above unless otherwise mentioned.
-
-### Feature Freeze
-
-Feature freeze should be performed on all repos. In order to start the feature
-freeze period, the following conditions should be met:
-
-* All expected features should be
- ["complete"](https://github.com/crossplane/crossplane/blob/master/design/one-pager-definition-of-done.md)
- and merged into master. This includes user guides, examples, API documentation
- via [crossdocs](https://github.com/negz/crossdocs/), and test updates.
-* All issues in the
- [milestone](https://github.com/crossplane/crossplane/milestones) should be
- closed
-* Sanity testing has been performed on `master`
-
-After these conditions are met, the feature freeze begins by creating the RC tag
-and the release branch.
-
-### Pin Dependencies
-
-It is a best practice to release Crossplane projects with "pinned" dependencies
-to specific versions of other upstream Crossplane projects. For example, after
-crossplane-runtime has been released, we want to update the main Crossplane repo
-to use that specific released version.
-
-To update a dependency to a specific version, simply edit the `go.mod` file to
-point to the desired version, then run `go mod tidy`.
-
-### Pre-release Tag
-
-The next step is to create the pre-release tag for the `HEAD` commit in
-`master`. This tag serves as an indication of when the release was branched
-from master and is also important for generating future versions of `master`
-builds since that [versioning
-process](https://github.com/upbound/build/blob/master/makelib/common.mk#L182-L196)
-is based on `git describe --tags`.
-
-> **NOTE:** The `tag` pipeline does not yet support additional (pre-release)
-tags in the version number, such as `v0.5.0-rc`.
-[#330](https://github.com/crossplane/crossplane/issues/330) will be resolved
-when this functionality is available. In the meantime, **manually tagging and
-pushing to the repo is required**. Ignore the steps below about running the
-pipeline because the pipeline won't work.
-
-To accomplish this, run the `tag` pipeline for each repo on the `master` branch.
-You will be prompted to enter the `version` for the tag and the `commit` hash to
-tag. It's possible to leave the `commit` field blank to default to tagging
-`HEAD`.
-
-Since this tag will essentially be the start of pre-releases working towards the
-**next** version, the `version` should be the **next** release number, plus a
-trailing tag to indicate it is a pre-release. The current convention is to use
-`*-rc`. For example, when we are releasing the `v0.9.0` release and we are
-ready for master to start working towards the **next** release of `v0.10.0`, we
-would make the tag `v0.10.0-rc`
-
-After the tag pipeline has succeeded, verify in the [GitHub
-UI](https://github.com/crossplane/crossplane/tags) that the tag was successfully
-applied to the correct commit.
-
-### Create Release Branch
-
-Creating the release branch can be done within the [GitHub
-UI](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-and-deleting-branches-within-your-repository).
-Basically, you just use the branch selector drop down and type in the name of
-the new release branch, e.g. `release-0.5`. Release branch names always follow
-the convention of `release-[minor-semver]`.
-
-If this is the first ever release branch being created in a repo (uncommon), you
-should also set up branch protection rules for the `release-*` pattern. You can
-find existing examples in the [Crossplane repo
-settings](https://github.com/crossplane/crossplane/settings/branches).
-
-At this point, the `HEAD` commit in the release branch will be our release
-candidate. The build pipeline will automatically be started due to the create
-branch event, so we can start to perform testing on this build. Note that it
-should be the exact same as what is currently in `master` since they are using
-the same commit and have the same tag. Also note that this is not the official
-release build since we have not made the official release tag yet (e.g.
-`v0.5.0`).
-
-The `master` branch can now be opened for new features since we have a safe
-release branch to continue bug fixes and improvements for the release itself.
-Essentially, `master` is free to now diverge from the release branch.
-
-### Release Branch Prep
-
-In the core Crossplane repository, we need to update the release branch docs and
-examples to point to the new versions that we will be releasing soon.
-
-* Documentation, such as [Installation
- instructions](https://github.com/crossplane/crossplane/blob/release-0.9/docs/install.md#installing-infrastructure-providers),
- and
- [Stack](https://github.com/crossplane/crossplane/blob/release-0.9/docs/stack.md)
- and
- [App](https://github.com/crossplane/crossplane/blob/release-0.9/docs/app.md)
- guides.
- * searching for `:master` will help a lot here
-* [Helm chart
- defaults](https://github.com/crossplane/crossplane/blob/release-0.9/cluster/charts/crossplane/values.yaml.tmpl),
- ensure all `values.yaml.tmpl` files are updated.
- * provider versions
- * `templating-controller` version (if a new version is available and ready)
-
-#### Bug Fixes in Release Branch
-
-During our testing of the release candidate, we may find issues or bugs that we
-triage and decide we want to fix before the release goes out. In order to fix a
-bug in the release branch, the following process is recommended:
-
-1. Make the bug fix into `master` first through the normal PR process
- 1. If the applicable code has already been removed from `master` then simply
- fix the bug directly in the release branch by opening a PR directly
- against the release branch
-1. Backport the fix by performing a cherry-pick of the fix's commit hash
- (**not** the merge commit) from `master` into the release branch. For
- example, to backport a fix from master to `v0.5.0`, something like the
- following should be used:
-
- ```console
- git fetch --all
- git checkout -b release-0.5 upstream/release-0.5
- git cherry-pick -x
- ```
-
-1. Open a PR with the cherry-pick commit targeting the release-branch
-
-After all bugs have been fixed and backported to the release branch, we can move
-on to tagging the final release commit.
-
-### Tag Core Crossplane
-
-Similar to running the `tag` pipelines for each stack, now it's time to run the
-[`tag`
-pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fcrossplane%2Fcrossplane-tag/branches)
-for core Crossplane. In fact, the [instructions](#stack-tag-pipeline) are
-exactly the same:
-
-Run the tag pipeline by clicking the Run button in the Jenkins UI in the correct
-release branch's row. You will be prompted for the version you are tagging,
-e.g., `v0.5.0` as well as the commit hash. The hash is optional and if you leave
-it blank it will default to `HEAD` of the branch, which is what you want.
-
-> **Note:** The first time you run a pipeline on a new branch, you won't get
-> prompted for the values to input. The build will quickly fail and then you can
-> run (not replay) it a second time to be prompted. This is a Jenkins bug that
-> is tracked by [#41929](https://issues.jenkins-ci.org/browse/JENKINS-41929) and
-> has been open for almost 3 years, so don't hold your breath.
-
-### Draft Release Notes
-
-We're getting close to starting the official release, so you should take this
-opportunity to draft up the release notes. You can create a [new release draft
-here](https://github.com/crossplane/crossplane/releases/new). Make sure you
-select "This is a pre-release" and hit "Save draft" when you are ready to share
-and collect feedback. Do **not** hit "Publish release" yet.
-
-You can see and follow the template and structure from [previous
-releases](https://github.com/crossplane/crossplane/releases).
-
-### Provider Release Process
-
-This section will walk through how to release the Providers and does not
-directly apply to core Crossplane.
-
-#### Pin Provider Dependencies
-
-Similar to core crossplane, each provider should have its crossplane related
-dependencies pinned to the versions that we are releasing. In the **master**
-branch of each provider repo, update the `crossplane` and `crossplane-runtime`
-dependencies to the versions we are releasing.
-
-Simply edit `go.mod` with the new versions, then run `go mod tidy`.
-
-The providers also depend on `crossplane-tools`, but that currently does not
-have official releases, so in practice should be using the latest from master.
-
-#### Provider Pre-release tag
-
-Follow the same steps that we did for core crossplane to tag the **master**
-branch of each provider repo with a pre-release tag for the **next** version.
-
-These steps can be found in the [pre-release tag section](#pre-release-tag).
-
-#### Create Provider Release Branches
-
-Now create a release branch for each of the provider repos using the GitHub UI.
-The steps are the same as what we did to [create the release
-branch](#create-release-branch) for core crossplane.
-
-#### Provider Release Branch Prep
-
-In the **release branch** for each provider, you should update the version tags
-and metadata in:
-
-* `integration_tests.sh` - `STACK_IMAGE`
-* `ClusterStackInstall` sample and example yaml files
-* `*.resource.yaml` - docs links in markdown
- * Not all of these `*.resource.yaml` files have links that need to be updated,
- they are infrequent and inconsistent
-
-Searching for `:master` will be a big help here.
-
-#### Provider Tag, Build, and Publish
-
-Now that the Providers are all tested and their version metadata has been
-updated, it's time to tag the release branch with the official version tag. You
-can do this by running the `tag` pipeline on the release branch of each
-Provider:
-
-* [`provider-gcp` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-gcp-pipelines%2Fprovider-gcp-tag/branches)
-* [`provider-aws` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-aws-pipelines%2Fprovider-aws-tag/branches/)
-* [`provider-azure` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-azure-pipelines%2Fprovider-azure-tag/branches/)
-* [`provider-rook` tag
- pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fprovider-rook-pipelines%2Fprovider-rook-tag/branches/)
-
-* Run the `tag` pipeline on the release branch
-* Enter the version and commit hash (leave blank for `HEAD`)
-* The first time you run on a new release branch, you won't be prompted and the
- build will fail, just run (not replay) a second time
-
-After the tag pipeline has been run and the release branch has been tagged, you
-can run the normal build pipeline on the release branch. This will kick off the
-official release build and upon success, all release artifacts will be
-officially published.
-
-After the release build succeeds, verify that the correctly versioned Provider
-images have been pushed to Docker Hub.
-
-### Template Stack Release Process
-
-The Template Stacks we maintain are slightly different from the controller-based
-stacks that we maintain. Their processes are similar but a little simpler. This
-section will walk through how to release the Template Stacks themselves, and
-does not directly apply to core Crossplane.
-
-For Template Stacks, we do not use release branches unless we need to make a
-patch release. In the future we may need a more robust branching strategy, but
-for now we are not using branches because it is simpler.
-
-Note that Template Stacks **do not** require any code changes to update their
-version. A slight exception to this is for their `behavior.yaml` files, which
-should have the `controllerImage` field updated if a new version of the
-`templating-controller` is available and ready.
-
-### Template Stack Tag And Publish Pipeline
-
-Here is the list of all template stacks:
-
-* [`stack-minimal-gcp`](https://github.com/crossplane/stack-minimal-gcp)
-* [`stack-minimal-aws`](https://github.com/crossplane/stack-minimal-aws)
-* [`stack-minimal-azure`](https://github.com/crossplane/stack-minimal-azure)
-* [`app-wordpress`](https://github.com/crossplane/app-wordpress)
-
-Each one should be released as part of a complete release, using the
-instructions below. To read even more about the template stack release process,
-see [the release section of this
-document](https://github.com/crossplane/cicd/blob/master/docs/pipelines.md#how-do-i-cut-a-release)
-
-Note that there's also the
-[`templating-controller`](https://github.com/crossplane/templating-controller),
-which supports template stacks. It is possible that it **may** need to be
-released as well, but typically is released independently from Crossplane.
-
-#### Tag the Template Stack
-
-Once a template stack is tested and ready for cutting a semver release, we will
-want to tag the repository with the new release version. In most cases, to get
-the version, take a look at the most recent tag in the repo, and increment the
-minor version. For example, if the most recent tag was `v0.2.0`, the new tag
-should be `v0.3.0`.
-
-Run the template stack's tag job on Jenkins, against the `master` branch. Enter
-in the new tag to use. If the current release candidate is not the head of
-`master`, enter in the commit to tag.
-
-You can find the tag pipeline for the individual stack by going to the
-[crossplane org in Jenkins](https://jenkinsci.upbound.io/job/crossplane/),
-finding the folder with the same name as the template stack, and then going to
-the `tag` job group. Then going to the `master` branch job under the group. For
-example, here is [a link to the stack-minimal-gcp tag job for
-master](https://jenkinsci.upbound.io/job/crossplane/job/stack-minimal-gcp/job/tag/job/master/).
-
-> **Note:** The first time you run a pipeline on a new branch, you won't get
-> prompted for the values to input and the build will fail. See details in the
-> [tagging core crossplane section](#tag-core-crossplane).
-
-#### Publish the Template Stack
-
-After the tag pipeline has been run and the repository has been tagged, you can
-run the `publish` job for the template stack. For example, here's a [link to the
-stack-minimal-gcp publish
-job](https://jenkinsci.upbound.io/job/crossplane/job/stack-minimal-gcp/job/publish/job/master/).
-This will kick off the official release build and upon success, all release
-artifacts will be officially published. This should also be run from the
-`master` branch in most cases. Or, if a release branch was used, from the
-release branch. The tag parameter should be used, and the tag for the current
-release should be used. For example, if the new tag we created was `v0.3.0`, we
-would want to provide `v0.3.0` for the `publish` job.
-
-#### Verify the Template Stack was Published
-
-After the publish build succeeds, verify that the correctly versioned template
-stack images have been pushed to Docker Hub.
-
-### Template Stack Patch Releases
-
-To do a patch release with a template stack, create a release branch from the
-minor version tag on the `master` branch, if a release branch doesn't already
-exist. Then, the regular tagging and publishing process for template stacks can
-be followed, incrementing the patch version to get the new release tag.
-
-### Build and Release Core Crossplane
-
-After the providers, stacks, and apps have all been released, ensure the [normal
-build
-pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fcrossplane%2Fbuild/branches)
-is run on the release branch for core crossplane. This will be the official
-release build with an official version number and all of its release artifacts
-will be published.
-
-After the pipeline runs successfully, you should verify that all artifacts have
-been published to:
-
-* [Docker Hub](https://hub.docker.com/repository/docker/crossplane/crossplane)
-* [S3 releases bucket](https://releases.crossplane.io/)
-* [Helm chart repository](https://charts.crossplane.io/)
-* [Docs website](https://crossplane.io/docs/latest)
-
-### Promotion
-
-If everything looks good with the official versioned release that we just
-published, we can go ahead and run the `promote` pipeline for the core
-crossplane and provider repos. This is a very quick pipeline that doesn't
-rebuild anything, it simply makes metadata changes to the published release to
-also include the release in the channel of your choice.
-
-Currently, we only support the `master` and `alpha` channels.
-
-For the core crossplane and each provider repo, run the `promote` pipeline on
-the release branch and input the version you would like to promote (e.g.
-`v0.5.0`) and the channel you'd like to promote it to. The first time you run
-this pipeline on a new release branch, you will not be prompted for values, so
-the pipeline will fail. Just run (not replay) it a second time to be prompted.
-
-* Run `promote` pipeline for `master` channel
-* Run `promote` pipeline for `alpha` channel
-
-After the `promote` pipelines have succeeded, verify on DockerHub and the Helm
-chart repository that the release has been promoted to the right channels.
-
-### Publish Release Notes
-
-Now that the release has been published and verified, you can publish the
-[release notes](https://github.com/crossplane/crossplane/releases) that you
-drafted earlier. After incorporating all feedback, you can now click on the
-"Publish release" button.
-
-This will send an email notification with the release notes to all watchers of
-the repo.
-
-### Announce Release
-
-We have completed the entire release, so it's now time to announce it to the
-world. Using the [@crossplane_io](https://twitter.com/crossplane_io) Twitter
-account, tweet about the new release and blog. You'll see examples from the
-previous releases, such as this tweet for
-[v0.4](https://twitter.com/crossplane_io/status/1189307636350705664).
-
-Post a link to this tweet on the Slack #announcements channel, then copy a link
-to that and post it in the #general channel.
-
-### Patch Releases
-
-We also have the ability to run patch releases to update previous releases that
-have already been published. These patch releases are always run from the last
-release branch, we do **not** create a new release branch for a patch release.
-
-The basic flow is **very** similar to a normal release, but with a few less
-steps. Please refer to details for each step in the sections above.
-
-* Fix any bugs in `master` first and then `cherry-pick -x` to the release branch
- * If `master` has already removed the relevant code then make your fix
- directly in the release branch
-* After all testing on the release branch look good and any docs/tests have been
- updated with the new version number, run the `tag` pipeline on the release
- branch with the new patch version (e.g. `v0.5.1`)
-* Run the normal build pipeline on the release branch to build and publish the
- release
-* Publish release notes
-* Run promote pipeline to promote the patch release to the `master` and `alpha`
- channels
diff --git a/docs/v0.13/snippets/compose/claim-alibaba.yaml b/docs/v0.13/snippets/compose/claim-alibaba.yaml
deleted file mode 100644
index 2214b1a1..00000000
--- a/docs/v0.13/snippets/compose/claim-alibaba.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstance
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: alibaba
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.13/snippets/compose/claim-aws.yaml b/docs/v0.13/snippets/compose/claim-aws.yaml
deleted file mode 100644
index 9fb5464b..00000000
--- a/docs/v0.13/snippets/compose/claim-aws.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstance
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: aws
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.13/snippets/compose/claim-azure.yaml b/docs/v0.13/snippets/compose/claim-azure.yaml
deleted file mode 100644
index dbf7f70b..00000000
--- a/docs/v0.13/snippets/compose/claim-azure.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstance
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: azure
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.13/snippets/compose/claim-gcp.yaml b/docs/v0.13/snippets/compose/claim-gcp.yaml
deleted file mode 100644
index 9529c617..00000000
--- a/docs/v0.13/snippets/compose/claim-gcp.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstance
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: gcp
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.13/snippets/compose/pod.yaml b/docs/v0.13/snippets/compose/pod.yaml
deleted file mode 100644
index 0b65ecef..00000000
--- a/docs/v0.13/snippets/compose/pod.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
- name: see-db
- namespace: default
-spec:
- containers:
- - name: see-db
- image: postgres:9.6
- command: ['psql']
- args: ['-c', 'SELECT current_database();']
- env:
- - name: PGDATABASE
- value: postgres
- - name: PGHOST
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: endpoint
- - name: PGUSER
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: username
- - name: PGPASSWORD
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: password
- - name: PGPORT
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: port
diff --git a/docs/v0.13/snippets/configure/alibaba/providerconfig.yaml b/docs/v0.13/snippets/configure/alibaba/providerconfig.yaml
deleted file mode 100644
index 1a8bdd95..00000000
--- a/docs/v0.13/snippets/configure/alibaba/providerconfig.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
----
-apiVersion: alibaba.crossplane.io/v1alpha1
-kind: ProviderConfig
-metadata:
- name: default
-spec:
- region: cn-beijing
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: alibaba-creds
- key: credentials
diff --git a/docs/v0.13/snippets/configure/aws/providerconfig.yaml b/docs/v0.13/snippets/configure/aws/providerconfig.yaml
deleted file mode 100644
index b00e6860..00000000
--- a/docs/v0.13/snippets/configure/aws/providerconfig.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
----
-apiVersion: aws.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: default
-spec:
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: aws-creds
- key: key
diff --git a/docs/v0.13/snippets/configure/aws/setup.sh b/docs/v0.13/snippets/configure/aws/setup.sh
deleted file mode 100755
index 59d3523c..00000000
--- a/docs/v0.13/snippets/configure/aws/setup.sh
+++ /dev/null
@@ -1,53 +0,0 @@
-#!/usr/bin/env bash
-#
-# This is a helper script that uses ~/.aws/credentials and ~/.aws/config
-# to build an aws provider object
-#
-# aws configuration (credentials and default region) is required for this
-# script
-
-set -e -o pipefail
-
-# change to script directory
-cd "$( cd "$( dirname "${BASH_SOURCE[0]}")" && pwd )"
-
-aws_profile=
-
-while (( "$#" )); do
- if test -z "$2"; then
- echo "invalid value for $1 option"
- exit -1
- fi
- case "$1" in
- -p|--profile)
- aws_profile=$2
- shift 2
- ;;
- *)
- shift
- ;;
- esac
-done
-
-# make sure kubectl is configured
-kubectl cluster-info > /dev/null || echo "KUBECONFIG is not configured properly"
-
-# if aws_profile is not provided, use default
-aws_profile="${aws_profile:-default}"
-
-# retrieve aws profile credentials, save it under 'default' profile, and base64 encode it
-AWS_CREDS_BASE64=$(echo -e "[default]\naws_access_key_id = $(aws configure get aws_access_key_id --profile $aws_profile)\naws_secret_access_key = $(aws configure get aws_secret_access_key --profile $aws_profile)" | base64 | tr -d "\n")
-
-if test -z "$AWS_CREDS_BASE64"; then
- echo "error reading credentials from aws config"
- exit 1
-fi
-
-echo "apiVersion: v1
-data:
- key: $AWS_CREDS_BASE64
-kind: Secret
-metadata:
- name: aws-creds
- namespace: crossplane-system
-type: Opaque" | kubectl apply -f -
\ No newline at end of file
diff --git a/docs/v0.13/snippets/configure/azure/providerconfig.yaml b/docs/v0.13/snippets/configure/azure/providerconfig.yaml
deleted file mode 100644
index 581e277b..00000000
--- a/docs/v0.13/snippets/configure/azure/providerconfig.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
----
-apiVersion: azure.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: default
-spec:
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: azure-creds
- key: key
diff --git a/docs/v0.13/snippets/configure/gcp/credentials.sh b/docs/v0.13/snippets/configure/gcp/credentials.sh
deleted file mode 100755
index 5d2bfbd3..00000000
--- a/docs/v0.13/snippets/configure/gcp/credentials.sh
+++ /dev/null
@@ -1,84 +0,0 @@
-#!/usr/bin/env bash
-#
-# This is a helper script to create a project, service account, and credentials.json
-# file for use in Crossplane GCP examples
-#
-# gcloud is required for use and must be configured with privileges to perform these tasks
-#
-set -e -o pipefail
-ROLES=(roles/iam.serviceAccountUser roles/cloudsql.admin roles/container.admin roles/redis.admin roles/compute.networkAdmin roles/storage.admin)
-SERVICES=(container.googleapis.com sqladmin.googleapis.com redis.googleapis.com compute.googleapis.com servicenetworking.googleapis.com)
-KEYFILE=crossplane-gcp-provider-key.json
-RAND=$RANDOM
-
-if ! command -v gcloud > /dev/null; then
- echo "Please install gcloud: https://cloud.google.com/sdk/install"
- exit 1
-fi
-
-tab () { sed 's/^/ /' ; }
-# list your organizations (if applicable), take note of the specific organization ID you want to use
-# if you have more than one organization (not common)
-gcloud organizations list --format '[box]' 2>&1 | tab
-
-ORGANIZATION_ID=$(gcloud organizations list --format 'value(ID)' --limit 1)
-read -e -p "Choose an Organization ID [$ORGANIZATION_ID]: " PROMPT_ORGANIZATION_ID
-ORGANIZATION_ID=${PROMPT_ORGANIZATION_ID:-$ORGANIZATION_ID}
-
-gcloud projects list --format '[box]' 2>&1 | tab
-
-# create a new id
-EXAMPLE_PROJECT_ID="crossplane-example-$RAND"
-read -e -p "Choose or create a Project ID [$EXAMPLE_PROJECT_ID]: " PROMPT_EXAMPLE_PROJECT_ID
-EXAMPLE_PROJECT_ID=${PROMPT_EXAMPLE_PROJECT_ID:-$EXAMPLE_PROJECT_ID}
-
-EXAMPLE_PROJECT_ID_FOUND=$(gcloud projects list --filter PROJECT_ID="$EXAMPLE_PROJECT_ID" --format="value(PROJECT_ID)")
-
-if [[ -z $EXAMPLE_PROJECT_ID_FOUND ]]; then
- ACCOUNT_ID=$(gcloud beta billing accounts list --format 'value(ACCOUNT_ID)' --limit 1)
- gcloud beta billing accounts list --format '[box]' 2>&1 | tab
- read -e -p "Choose a Billing Account ID [$ACCOUNT_ID]: " PROMPT_ACCOUNT_ID
- ACCOUNT_ID=${PROMPT_ACCOUNT_ID:-$ACCOUNT_ID}
-
- echo -e "\n* Creating Project $EXAMPLE_PROJECT_ID ... "
- gcloud projects create $EXAMPLE_PROJECT_ID --enable-cloud-apis --organization $ORGANIZATION_ID 2>&1 | tab
-
- echo "* Linking Billing Account $ACCOUNT_ID with Project $EXAMPLE_PROJECT_ID ... "
- gcloud beta billing projects link $EXAMPLE_PROJECT_ID --billing-account=$ACCOUNT_ID 2>&1 | tab
-else
- echo -n "\n* Using Project $EXAMPLE_PROJECT_NAME ... $EXAMPLE_PROJECT_ID"
-fi
-
-# enable Kubernetes API
-for service in "${SERVICES[@]}"; do
- # enable Google API
- echo "* Enabling Service $service on $EXAMPLE_PROJECT_ID"
- gcloud --project $EXAMPLE_PROJECT_ID services enable $service 2>&1 | tab
-done
-
-# create service account
-SA_NAME="example-$RAND"
-echo " * Creating a Service Account"
-gcloud --project $EXAMPLE_PROJECT_ID iam service-accounts create $SA_NAME --display-name "Crossplane Example" 2>&1 | tab
-# export service account email
-EXAMPLE_SA="${SA_NAME}@${EXAMPLE_PROJECT_ID}.iam.gserviceaccount.com"
-
-# assign roles
-for role in "${ROLES[@]}"; do
- echo "* Adding Role $role to $EXAMPLE_SA on $EXAMPLE_PROJECT_ID"
- gcloud projects add-iam-policy-binding $EXAMPLE_PROJECT_ID --member "serviceAccount:$EXAMPLE_SA" --role="$role" 2>&1 | tab
-done
-
-# create service account key (this will create a `crossplane-gcp-provider-key.json` file in your current working directory)
-echo " * Creating $EXAMPLE_SA Key File $KEYFILE"
-gcloud --project $EXAMPLE_PROJECT_ID iam service-accounts keys create --iam-account $EXAMPLE_SA $KEYFILE 2>&1 | tab
-
-cat <
-
-[Install Crossplane]: getting-started/install-configure.md
-[Custom Resource Definitions]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[reconciling]: https://kubernetes.io/docs/concepts/architecture/controller/
-[GCP]: https://github.com/crossplane/provider-gcp
-[AWS]: https://github.com/crossplane/provider-aws
-[Azure]: https://github.com/crossplane/provider-azure
-[Alibaba]: https://github.com/crossplane/provider-alibaba
-[infrastructure resources]: https://blog.crossplane.io/crossplane-v0-10-compose-and-publish-your-own-infrastructure-crds-velero-backup-restore-compatibility-and-more/
-[OAM]: https://oam.dev/
diff --git a/docs/v0.14/api-docs/crds/meta.pkg.crossplane.io_configurations.yaml b/docs/v0.14/api-docs/crds/meta.pkg.crossplane.io_configurations.yaml
deleted file mode 100644
index 141b3aab..00000000
--- a/docs/v0.14/api-docs/crds/meta.pkg.crossplane.io_configurations.yaml
+++ /dev/null
@@ -1,73 +0,0 @@
-
----
-apiVersion: apiextensions.k8s.io/v1
-kind: CustomResourceDefinition
-metadata:
- annotations:
- controller-gen.kubebuilder.io/version: v0.3.0
- creationTimestamp: null
- name: configurations.meta.pkg.crossplane.io
-spec:
- group: meta.pkg.crossplane.io
- names:
- kind: Configuration
- listKind: ConfigurationList
- plural: configurations
- singular: configuration
- scope: Namespaced
- versions:
- - name: v1alpha1
- schema:
- openAPIV3Schema:
- description: A Configuration is the description of a Crossplane Configuration package.
- properties:
- apiVersion:
- description: 'APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
- type: string
- kind:
- description: 'Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
- type: string
- metadata:
- type: object
- spec:
- description: ConfigurationSpec specifies the configuration of a Configuration.
- properties:
- crossplane:
- description: Semantic version constraints of Crossplane that package is compatible with.
- properties:
- version:
- description: Semantic version constraints of Crossplane that package is compatible with.
- type: string
- required:
- - version
- type: object
- dependsOn:
- description: Dependencies on other packages.
- items:
- description: Dependency is a dependency on another package. One of Provider or Configuration may be supplied.
- properties:
- configuration:
- description: Configuration is the name of a Configuration package image.
- type: string
- provider:
- description: Provider is the name of a Provider package image.
- type: string
- version:
- description: Version is the semantic version constraints of the dependency image.
- type: string
- required:
- - version
- type: object
- type: array
- type: object
- required:
- - spec
- type: object
- served: true
- storage: true
-status:
- acceptedNames:
- kind: ""
- plural: ""
- conditions: []
- storedVersions: []
diff --git a/docs/v0.14/api-docs/crds/meta.pkg.crossplane.io_providers.yaml b/docs/v0.14/api-docs/crds/meta.pkg.crossplane.io_providers.yaml
deleted file mode 100644
index 1aa7a0a6..00000000
--- a/docs/v0.14/api-docs/crds/meta.pkg.crossplane.io_providers.yaml
+++ /dev/null
@@ -1,84 +0,0 @@
-
----
-apiVersion: apiextensions.k8s.io/v1
-kind: CustomResourceDefinition
-metadata:
- annotations:
- controller-gen.kubebuilder.io/version: v0.3.0
- creationTimestamp: null
- name: providers.meta.pkg.crossplane.io
-spec:
- group: meta.pkg.crossplane.io
- names:
- kind: Provider
- listKind: ProviderList
- plural: providers
- singular: provider
- scope: Namespaced
- versions:
- - name: v1alpha1
- schema:
- openAPIV3Schema:
- description: A Provider is the description of a Crossplane Provider package.
- properties:
- apiVersion:
- description: 'APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
- type: string
- kind:
- description: 'Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
- type: string
- metadata:
- type: object
- spec:
- description: ProviderSpec specifies the configuration of a Provider.
- properties:
- controller:
- description: Configuration for the packaged Provider's controller.
- properties:
- image:
- description: Image is the packaged Provider controller image.
- type: string
- required:
- - image
- type: object
- crossplane:
- description: Semantic version constraints of Crossplane that package is compatible with.
- properties:
- version:
- description: Semantic version constraints of Crossplane that package is compatible with.
- type: string
- required:
- - version
- type: object
- dependsOn:
- description: Dependencies on other packages.
- items:
- description: Dependency is a dependency on another package. One of Provider or Configuration may be supplied.
- properties:
- configuration:
- description: Configuration is the name of a Configuration package image.
- type: string
- provider:
- description: Provider is the name of a Provider package image.
- type: string
- version:
- description: Version is the semantic version constraints of the dependency image.
- type: string
- required:
- - version
- type: object
- type: array
- required:
- - controller
- type: object
- required:
- - spec
- type: object
- served: true
- storage: true
-status:
- acceptedNames:
- kind: ""
- plural: ""
- conditions: []
- storedVersions: []
diff --git a/docs/v0.14/api-docs/crossplane.md b/docs/v0.14/api-docs/crossplane.md
deleted file mode 100644
index dfdc06b1..00000000
--- a/docs/v0.14/api-docs/crossplane.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: crossplane
-toc: true
-weight: 401
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/crossplane
----
diff --git a/docs/v0.14/api-docs/oam-kubernetes-runtime.md b/docs/v0.14/api-docs/oam-kubernetes-runtime.md
deleted file mode 100644
index 2a5026cc..00000000
--- a/docs/v0.14/api-docs/oam-kubernetes-runtime.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: oam-kubernetes-runtime
-toc: true
-weight: 408
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/oam-kubernetes-runtime
----
diff --git a/docs/v0.14/api-docs/overview.md b/docs/v0.14/api-docs/overview.md
deleted file mode 100644
index e9a92c48..00000000
--- a/docs/v0.14/api-docs/overview.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: API Documentation
-toc: true
-weight: 400
----
-
-# API Documentation
-
-The Crossplane ecosystem contains many CRDs that map to API types represented by
-external infrastructure providers. The documentation for these CRDs are
-auto-generated on [doc.crds.dev]. To find the CRDs available for providers
-maintained by the Crossplane organization, you can search for the Github URL, or
-append it in the [doc.crds.dev] URL path.
-
-For instance, to find the CRDs available for [provider-azure], you would go to:
-
-[doc.crds.dev/github.com/crossplane/provider/azure]
-
-By default, you will be served the latest CRDs on the `master` branch for the
-repository. If you prefer to see the CRDs for a specific version, you can append
-the git tag for the release:
-
-[doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0]
-
-Crossplane repositories that are not providers but do publish CRDs are also
-served on [doc.crds.dev]. For instance, the [crossplane/crossplane] repository.
-
-Bugs and feature requests for API documentation should be [opened as issues] on
-the open source [doc.crds.dev repo].
-
-
-
-[doc.crds.dev]: https://doc.crds.dev/
-[provider-azure]: https://github.com/crossplane/provider-azure
-[doc.crds.dev/github.com/crossplane/provider/azure]: https://doc.crds.dev/github.com/crossplane/provider-azure
-[doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0]: https://doc.crds.dev/github.com/crossplane/provider-azure@v0.8.0
-[crossplane/crossplane]: https://doc.crds.dev/github.com/crossplane/crossplane
-[opened as issues]: https://github.com/crdsdev/doc/issues/new
-[doc.crds.dev repo]: https://github.com/crdsdev/doc
diff --git a/docs/v0.14/api-docs/provider-alibaba.md b/docs/v0.14/api-docs/provider-alibaba.md
deleted file mode 100644
index 099c6f43..00000000
--- a/docs/v0.14/api-docs/provider-alibaba.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-alibaba
-toc: true
-weight: 402
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-alibaba
----
diff --git a/docs/v0.14/api-docs/provider-aws.md b/docs/v0.14/api-docs/provider-aws.md
deleted file mode 100644
index b2e74e53..00000000
--- a/docs/v0.14/api-docs/provider-aws.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-aws
-toc: true
-weight: 403
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-aws
----
diff --git a/docs/v0.14/api-docs/provider-azure.md b/docs/v0.14/api-docs/provider-azure.md
deleted file mode 100644
index 955b3d22..00000000
--- a/docs/v0.14/api-docs/provider-azure.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-azure
-toc: true
-weight: 404
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-azure
----
diff --git a/docs/v0.14/api-docs/provider-gcp.md b/docs/v0.14/api-docs/provider-gcp.md
deleted file mode 100644
index 6e49c9b4..00000000
--- a/docs/v0.14/api-docs/provider-gcp.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-gcp
-toc: true
-weight: 405
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-gcp
----
diff --git a/docs/v0.14/api-docs/provider-helm.md b/docs/v0.14/api-docs/provider-helm.md
deleted file mode 100644
index a52f2f21..00000000
--- a/docs/v0.14/api-docs/provider-helm.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-helm
-toc: true
-weight: 407
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane-contrib/provider-helm
----
diff --git a/docs/v0.14/api-docs/provider-rook.md b/docs/v0.14/api-docs/provider-rook.md
deleted file mode 100644
index e84e2c36..00000000
--- a/docs/v0.14/api-docs/provider-rook.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: provider-rook
-toc: true
-weight: 406
-indent: true
-redirect_to: https://doc.crds.dev/github.com/crossplane/provider-rook
----
diff --git a/docs/v0.14/cloud-providers/aws/aws-provider.md b/docs/v0.14/cloud-providers/aws/aws-provider.md
deleted file mode 100644
index 92bb7b14..00000000
--- a/docs/v0.14/cloud-providers/aws/aws-provider.md
+++ /dev/null
@@ -1,143 +0,0 @@
-# Adding Amazon Web Services (AWS) to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your AWS
-account to be ready for integration with Crossplane. This will be done by adding
-an AWS `ProviderConfig` resource type, which enables Crossplane to communicate with an
-AWS account.
-
-## Requirements
-
-Prior to adding AWS to Crossplane, following steps need to be taken
-
-- Crossplane is installed in a k8s cluster
-- AWS Stack is installed in the same cluster
-- `kubectl` is configured to communicate with the same cluster
-
-## Step 1: Configure `aws` CLI
-
-Crossplane uses [AWS security credentials], and stores them as a [secret] which
-is managed by an AWS `ProviderConfig` instance. In addition, the AWS default region is
-also used for targeting a specific region. Crossplane requires to have [`aws`
-command line tool] [installed] and [configured]. Once installed, the credentials
-and configuration will reside in `~/.aws/credentials` and `~/.aws/config`
-respectively.
-
-## Step 2: Setup `aws` Provider
-
-Run `setup.sh` to read `aws` credentials and region, and create an `aws
-provider` instance in Crossplane:
-
-```bash
-curl -O https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/configure/aws/providerconfig.yaml
-curl -O https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/configure/aws/setup.sh
-./setup.sh [--profile aws_profile]
-```
-
-The `--profile` switch is optional and specifies the [aws named profile] that
-was set in Step 1. If not provided, the `default` profile will be selected.
-
-Once the script is successfully executed, Crossplane will use the specified aws
-account and region in the given named profile to create subsequent AWS managed
-resources.
-
-You can confirm the existence of the AWS `ProviderConfig` by running:
-
-```bash
-kubectl get providerconfig default
-```
-
-## Optional: Setup AWS Provider Manually
-
-An AWS [user][aws user] with `Administrative` privileges is needed to enable
-Crossplane to create the required resources. Once the user is provisioned, an
-[Access Key][] needs to be created so the user can have API access.
-
-Using the set of [access key credentials][AWS security credentials] for the user
-with the right access, we need to [install][install-aws] [`aws cli`][aws command
-line tool], and then [configure][aws-cli-configure] it.
-
-When the AWS cli is configured, the credentials and configuration will be in
-`~/.aws/credentials` and `~/.aws/config` respectively. These will be consumed in
-the next step.
-
-When configuring the AWS cli, the user credentials could be configured under a
-specific [AWS named profile][], or under `default`. Without loss of generality,
-in this guide let's assume that the credentials are configured under the
-`aws_profile` profile (which could also be `default`). We'll use this profile to
-setup cloud provider in the next section.
-
-Crossplane uses the AWS user credentials that were configured in the previous
-step to create resources in AWS. These credentials will be stored as a
-[secret][kubernetes secret] in Kubernetes, and will be used by an AWS
-`ProviderConfig` instance. The default AWS region is also pulled from the cli
-configuration, and added to the AWS provider.
-
-To store the credentials as a secret, run:
-
-```bash
-# retrieve profile's credentials, save it under 'default' profile, and base64 encode it
-BASE64ENCODED_AWS_ACCOUNT_CREDS=$(echo -e "[default]\naws_access_key_id = $(aws configure get aws_access_key_id --profile $aws_profile)\naws_secret_access_key = $(aws configure get aws_secret_access_key --profile $aws_profile)" | base64 | tr -d "\n")
-```
-
-Next, we'll need to create an AWS provider configuration:
-
-```bash
-cat > provider.yaml <
-
-[`aws` command line tool]: https://aws.amazon.com/cli/
-[AWS SDK for GO]: https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/setting-up.html
-[installed]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html
-[configured]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html
-[AWS security credentials]: https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html
-[secret]:https://kubernetes.io/docs/concepts/configuration/secret/
-[aws named profile]: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html
-[aws user]: https://docs.aws.amazon.com/mediapackage/latest/ug/setting-up-create-iam-user.html
-[Access Key]: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
-[AWS security credentials]: https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html
-[aws command line tool]: https://aws.amazon.com/cli/
-[install-aws]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html
-[aws-cli-configure]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html
-[kubernetes secret]: https://kubernetes.io/docs/concepts/configuration/secret/
-[AWS named profile]: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html
diff --git a/docs/v0.14/cloud-providers/azure/azure-provider.md b/docs/v0.14/cloud-providers/azure/azure-provider.md
deleted file mode 100644
index f9cab944..00000000
--- a/docs/v0.14/cloud-providers/azure/azure-provider.md
+++ /dev/null
@@ -1,129 +0,0 @@
-# Adding Microsoft Azure to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your Azure
-account to be ready for integration with Crossplane. The general steps we will
-take are summarized below:
-
-* Create a new service principal (account) that Crossplane will use to create
- and manage Azure resources
-* Add the required permissions to the account
-* Consent to the permissions using an administrator account
-
-## Preparing your Microsoft Azure Account
-
-In order to manage resources in Azure, you must provide credentials for a Azure
-service principal that Crossplane can use to authenticate. This assumes that you
-have already [set up the Azure CLI
-client](https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli?view=azure-cli-latest)
-with your credentials.
-
-Create a JSON file that contains all the information needed to connect and
-authenticate to Azure:
-
-```bash
-# create service principal with Owner role
-az ad sp create-for-rbac --sdk-auth --role Owner > crossplane-azure-provider-key.json
-```
-
-Take note of the `clientID` value from the JSON file that we just created, and
-save it to an environment variable:
-
-```bash
-export AZURE_CLIENT_ID=
-```
-
-Now add the required permissions to the service principal that will allow it to
-manage the necessary resources in Azure:
-
-```bash
-# add required Azure Active Directory permissions
-az ad app permission add --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --api-permissions 1cda74f2-2616-4834-b122-5cb1b07f8a59=Role 78c8a3c8-a07e-4b9e-af1b-b5ccab50a175=Role
-
-# grant (activate) the permissions
-az ad app permission grant --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --expires never
-```
-
-You might see an error similar to the following, but that is OK, the permissions
-should have gone through still:
-
-```console
-Operation failed with status: 'Conflict'. Details: 409 Client Error: Conflict for url: https://graph.windows.net/e7985bc4-a3b3-4f37-b9d2-fa256023b1ae/oauth2PermissionGrants?api-version=1.6
-```
-
-Finally, you need to grant admin permissions on the Azure Active Directory to
-the service principal because it will need to create other service principals
-for your `AKSCluster`:
-
-```bash
-# grant admin consent to the service princinpal you created
-az ad app permission admin-consent --id "${AZURE_CLIENT_ID}"
-```
-
-Note: You might need `Global Administrator` role to `Grant admin consent for
-Default Directory`. Please contact the administrator of your Azure subscription.
-To check your role, go to `Azure Active Directory` -> `Roles and
-administrators`. You can find your role(s) by clicking on `Your Role (Preview)`
-
-After these steps are completed, you should have the following file on your
-local filesystem:
-
-* `crossplane-azure-provider-key.json`
-
-## Setup Azure Provider
-
-Before creating any resources, we need to create and configure an Azure cloud
-provider resource in Crossplane, which stores the cloud account information in
-it. All the requests from Crossplane to Azure Cloud will use the credentials
-attached to this provider resource. The following command assumes that you have
-a `crossplane-azure-provider-key.json` file that belongs to the account you’d
-like Crossplane to use.
-
-```bash
-BASE64ENCODED_AZURE_ACCOUNT_CREDS=$(base64 crossplane-azure-provider-key.json | tr -d "\n")
-```
-
-Now we’ll create our `Secret` that contains the credential and `ProviderConfig`
-resource that refers to that secret:
-
-```bash
-cat > provider.yaml < provider.yaml <
-[templating-controller]: https://github.com/crossplane/templating-controller
-[stack-gcp-sample]: https://github.com/crossplane/stack-gcp-sample
-[stack-aws-sample]: https://github.com/crossplane/stack-aws-sample
-[stack-azure-sample]: https://github.com/crossplane/stack-azure-sample
-[app-wordpress]: https://github.com/crossplane/app-wordpress
-[Wordpress Quickstart Guide]: https://github.com/crossplane/app-wordpress/blob/master/docs/quickstart.md
-[packaging an app]: experimental/packaging_an_app.md
diff --git a/docs/v0.14/contributing/experimental/packaging_an_app.md b/docs/v0.14/contributing/experimental/packaging_an_app.md
deleted file mode 100644
index 38cdbc71..00000000
--- a/docs/v0.14/contributing/experimental/packaging_an_app.md
+++ /dev/null
@@ -1,198 +0,0 @@
----
-title: Packaging an Application
-toc: false
-weight: 2000
-indent: true
----
-
-# Packaging an Application
-
-In the quick start guide, we demonstrated how Wordpress can be installed as a
-Crossplane `Application`. Now we want to learn more about how to package any
-application in a similar fashion. The good news is that we can use common
-Kubernetes configuration tools, such as [Helm] and [Kustomize], which you may
-already be familiar with.
-
-## Setting up a Repository
-
-The required components of an application repository are minimal. For example,
-the required components of the [Wordpress application] we deployed in the quick
-start are the following:
-
-```
-├── Dockerfile
-├── .registry
-│ ├── app.yaml
-│ ├── behavior.yaml
-│ ├── icon.svg
-│ └── resources
-│ ├── wordpress.apps.crossplane.io_wordpressinstances.crd.yaml
-│ ├── wordpressinstance.icon.svg
-│ ├── wordpressinstance.resource.yaml
-│ └── wordpressinstance.ui-schema.yaml
-├── helm-chart
-│ ├── Chart.yaml
-│ ├── templates
-│ │ ├── app.yaml
-│ │ ├── cluster.yaml
-│ │ └── database.yaml
-│ └── values.yaml
-```
-
-Let's take a look at each component in-depth.
-
-### Dockerfile
-
-The Dockerfile is only responsible for copying the configuration directory
-(`helm-chart/` in this case) and the `.registry` directory. You can likely use a
-very similar Dockerfile across all of your applications:
-
-```Dockerfile
-FROM alpine:3.7
-WORKDIR /
-COPY helm-chart /helm-chart
-COPY .registry /.registry
-```
-
-### .registry
-
-The `.registry` directory informs Crossplane how to install your application. It
-consists of the following:
-
-**app.yaml** `[required]`
-
-The `app.yaml` file is responsible for defining the metadata for an application,
-such as name, version, and required permissions. The Wordpress `app.yaml` is a
-good reference for available fields:
-
-```yaml
-# Human readable title of application.
-title: Wordpress
-
-overviewShort: Cloud portable Wordpress deployments behind managed Kubernetes and SQL services are demonstrated in this Crossplane Stack.
-
-overview: |-
- This Wordpress application uses a simple controller that uses Crossplane to orchestrate managed SQL services and managed Kubernetes clusters which are then used to run a Wordpress deployment.
- A simple Custom Resource Definition (CRD) is provided allowing for instances of this Crossplane managed Wordpress Application to be provisioned with a few lines of yaml.
- The Sample Wordpress Application is intended for demonstration purposes and should not be used to deploy production instances of Wordpress.
-
-# Markdown description of this entry
-readme: |-
- ### Create wordpresses
- Before wordpresses will provision, the Crossplane control cluster must
- be configured to connect to a provider (e.g. GCP, Azure, AWS).
- Once a provider is configured, starting the process of creating a
- Wordpress Application instance is easy.
-
- cat <.icon.svg`: an image to be displayed for your application CRD
-- `.resource.yaml`: a description of your application CRD
-- `.ui-schema.yaml`: the configurable fields on your CRD that you
- wish to be displayed in a UI
-
-Crossplane will take these files and apply them as [annotations] on the
-installed application. They can then be parsed by a user interface.
-
-### Configuration Directory
-
-The configuration directory contains the actual manifests for deploying your
-application. In the case of Wordpress, this includes a `KubernetesApplication`
-(`helm-chart/templates/app.yaml`), a `KubernetesCluster` claim
-(`helm-chart/templates/cluster.yaml`), and a `MySQLInstance` claim
-(`helm-chart/templates/database.yaml`). The configuration tool for the manifests
-in the directory should match the `engine` field in your
-`.registry/behavior.yaml`. The options for engines at this time are `helm3` and
-`kustomize`. Crossplane will pass values from the `spec` of the application's
-CRD as variables in the manifests. For instance, the `provisionPolicy` field in
-the `spec` of the `WordpressInstance` CRD will be passed to the Helm chart
-defined in the `helm-chart/` directory.
-
-
-
-[Helm]: https://helm.sh/
-[Kustomize]: https://kustomize.io/
-[Wordpress application]: https://github.com/crossplane/app-wordpress
-[CustomResourceDefinition]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[controller-tools]: https://github.com/kubernetes-sigs/controller-tools
-[annotations]: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
diff --git a/docs/v0.14/contributing/observability_developer_guide.md b/docs/v0.14/contributing/observability_developer_guide.md
deleted file mode 100644
index 9741512f..00000000
--- a/docs/v0.14/contributing/observability_developer_guide.md
+++ /dev/null
@@ -1,200 +0,0 @@
----
-title: Observability Developer Guide
-toc: true
-weight: 1002
-indent: true
----
-
-# Observability Developer Guide
-
-## Introduction
-
-Observability is crucial to Crossplane users; both those operating Crossplane
-and those using Crossplane to operate their infrastructure. Crossplane currently
-approaches observability via Kubernetes events and structured logs. Timeseries
-metrics are desired but [not yet implemented].
-
-## Goals
-
-In short, a non-admin user and an admin user should both be able to debug any
-issues only by inspecting logs and events. There should be no need to rebuild
-the Crossplane binary or to reach out to a Crossplane developer.
-
-A user should be able to:
-
-* Debug an issue without rebuilding the Crossplane binary
-* Understand an issue without contacting a cluster admin
-* Ask a cluster admin to check the logs for more details about the reason the
- issue happened, if the details are not part of the error message
-
-A cluster admin should be able to:
-
-* Debug an issue without rebuilding the Crossplane binary
-* Debug an issue only by looking at the logs
-* Debug an issue without needing to contact a Crossplane developer
-
-## Error reporting in the logs
-
-Error reporting in the logs is mostly intended for consumption by Crossplane
-cluster admins. A cluster admin should be able to debug any issue by inspecting
-the logs, without needing to add more logs themselves or contact a Crossplane
-developer. This means that logs should contain:
-
-* Error messages, at either the info or debug level as contextually appropriate
-* Any context leading up to an error, typically at debug level, so that the
- errors can be debugged
-
-## Error reporting as events
-
-Error reporting as Kubernetes events is primarily aimed toward end-users of
-Crossplane who are not cluster admins. Crossplane typically runs as a Kubernetes
-pod, and thus it is unlikely that most users of Crossplane will have access to
-its logs. [Events], on the other hand, are available as top-level Kubernetes
-objects, and show up the objects they relate to when running `kubectl describe`.
-
-Events should be recorded in the following cases:
-
-* A significant operation is taken on a resource
-* The state of a resource is changed
-* An error occurs
-
-The events recorded in these cases can be thought of as forming an event log of
-things that happen for the resources that Crossplane manages. Each event should
-refer back to the relevant controller and resource, and use other fields of the
-Event kind as appropriate.
-
-More details about examples of how to interact with events can be found in the
-guide to [debugging an application cluster].
-
-## Choosing between methods of error reporting
-
-There are many ways to report errors, such as:
-
-* Metrics
-* Events
-* Logging
-* Tracing
-
-It can be confusing to figure out which one is appropriate in a given situation.
-This section will try to offer advice and a mindset that can be used to help
-make this decision.
-
-Let's set the context by listing the different user scenarios where error
-reporting may be consumed. Here are the typical scenarios as we imagine them:
-
-1. A person **using** a system needs to figure out why things aren't working as
- expected, and whether they made a mistake that they can correct.
-2. A person **operating** a service needs to monitor the service's **health**,
- both now and historically.
-3. A person **debugging** a problem which happened in a **live environment**
- (often an **operator** of the system) needs information to figure out what
- happened.
-4. A person **developing** the software wants to **observe** what is happening.
-5. A person **debugging** the software in a **development environment**
- (typically a **developer** of the system) wants to debug a problem (there is
- a lot of overlap between this and the live environment debugging scenario).
-
-The goal is to satisfy the users in all of the scenarios. We'll refer to the
-scenarios by number.
-
-The short version is: we should do whatever satisfies all of the scenarios.
-Logging and events are the recommendations for satisfying the scenarios,
-although they don't cover scenario 2.
-
-The longer version is:
-
-* Scenario 1 is best served by events in the context of Crossplane, since the
- users may not have access to read logs or metrics, and even if they did, it
- would be hard to relate them back to the event the user is trying to
- understand.
-* Scenario 2 is best served by metrics, because they can be aggregated and
- understood as a whole. And because they can be used to track things over time.
-* Scenario 3 is best served by either logging that contains all the information
- about and leading up to the event. Request-tracing systems are also useful for
- this scenario.
-* Scenario 4 is usually logs, maybe at a more verbose level than normal. But it
- could be an attached debugger or some other type of tool. It could also be a
- test suite.
-* Scenario 5 is usually either logs, up to the highest imaginable verbosity, or
- an attached debugging session. If there's a gap in reporting, it could involve
- adding some print statements to get more logging.
-
-As for the question of how to decide whether to log or not, we believe it helps
-to try to visualize which of the scenarios the error or information in question
-will be used for. We recommend starting with reporting as much information as
-possible, but with configurable runtime behavior so that, for example, debugging
-logs don't show up in production normally.
-
-For the question of what constitutes an error, errors should be actionable by a
-human. See the [Dave Cheney article] on this topic for some more discussion.
-
-## In Practice
-
-Crossplane provides two observability libraries as part of crossplane-runtime:
-
-* [`event`] emits Kubernetes events.
-* [`logging`] produces structured logs. Refer to its package documentation for
- additional context on its API choices.
-
-Keep the following in mind when using the above libraries:
-
-* [Do] [not] use package level loggers or event recorders. Instantiate them in
- `main()` and plumb them down to where they're needed.
-* Each [`Reconciler`] implementation should use its own `logging.Logger` and
- `event.Recorder`. Implementations are strongly encouraged to default to using
- `logging.NewNopLogger()` and `event.NewNopRecorder()`, and accept a functional
- loggers and recorder via variadic options. See for example the [managed
- resource reconciler].
-* Each controller should use its name as its event recorder's name, and include
- its name under the `controller` structured logging key. The controllers name
- should be of the form `controllertype/resourcekind`, for example
- `managed/cloudsqlinstance` or `stacks/stackdefinition`. Controller names
- should always be lowercase.
-* Logs and events should typically be emitted by the `Reconcile` method of the
- `Reconciler` implementation; not by functions called by `Reconcile`. Author
- the methods orchestrated by `Reconcile` as if they were a library; prefer
- surfacing useful information for the `Reconciler` to log (for example by
- [wrapping errors]) over plumbing loggers and event recorders down to
- increasingly deeper layers of code.
-* Almost nothing is worth logging at info level. When deciding which logging
- level to use, consider a production deployment of Crossplane reconciling tens
- or hundreds of managed resources. If in doubt, pick debug. You can easily
- increase the log level later if it proves warranted.
-* The above is true even for errors; consider the audience. Is this an error
- only the Crossplane cluster operator can fix? Does it indicate a significant
- degradation of Crossplane's functionality? If so, log it at info. If the error
- pertains to a single Crossplane resource emit an event instead.
-* Always log errors under the structured logging key `error` (e.g.
- `log.Debug("boom!, "error", err)`). Many logging implementations (including
- Crossplane's) add context like stack traces for this key.
-* Emit events liberally; they're rate limited and deduplicated.
-* Follow [API conventions] when emitting events; ensure event reasons are unique
- and `CamelCase`.
-* Consider emitting events and logs when a terminal condition is encountered
- (e.g. `Reconcile` returns) over logging logic flow. i.e. Prefer one log line
- that reads "encountered an error fooing the bar" over two log lines that read
- "about to foo the bar" and "encountered an error". Recall that if the audience
- is a developer debugging Crossplane they will be provided a stack trace with
- file and line context when an error is logged.
-* Consider including the `reconcile.Request`, and the resource's UID and
- resource version (not API version) under the keys `request`, `uid`, and
- `version`. Doing so allows log readers to determine what specific version of a
- resource the log pertains to.
-
-Finally, when in doubt, aim for consistency with existing Crossplane controller
-implementations.
-
-
-
-[not yet implemented]: https://github.com/crossplane/crossplane/issues/314
-[Events]: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#event-v1-core
-[debugging an application cluster]: https://kubernetes.io/docs/tasks/debug-application-cluster/
-[Dave Cheney article]: https://dave.cheney.net/2015/11/05/lets-talk-about-logging
-[`event`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/event
-[`logging`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/logging
-[Do]: https://peter.bourgon.org/go-best-practices-2016/#logging-and-instrumentation
-[not]: https://dave.cheney.net/2017/01/23/the-package-level-logger-anti-pattern
-[`Reconciler`]: https://godoc.org/sigs.k8s.io/controller-runtime/pkg/reconcile#Reconciler
-[managed resource reconciler]: https://github.com/crossplane/crossplane-runtime/blob/a6bb0/pkg/reconciler/managed/reconciler.go#L436
-[wrapping errors]: https://godoc.org/github.com/pkg/errors#Wrap
-[API conventions]: https://github.com/kubernetes/community/blob/09f55c6/contributors/devel/sig-architecture/api-conventions.md#events
diff --git a/docs/v0.14/contributing/overview.md b/docs/v0.14/contributing/overview.md
deleted file mode 100644
index 8d39576f..00000000
--- a/docs/v0.14/contributing/overview.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Contributing
-toc: true
-weight: 1000
----
-
-# Contributing
-
-The following documentation is for developers who wish to contribute to or
-extend Crossplane. Please [open an
-issue](https://github.com/crossplane/crossplane/issues/new) for any additional
-documentation you would like to see in this section.
-
-1. [Provider Development Guide]
-2. [Observability Developer Guide]
-
-# Experimental Projects
-See [experimental] projects.
-
-
-[Provider Development Guide]: provider_development_guide.md
-[Observability Developer Guide]: observability_developer_guide.md
-[experimental]: experimental.md
diff --git a/docs/v0.14/contributing/provider_development_guide.md b/docs/v0.14/contributing/provider_development_guide.md
deleted file mode 100644
index 3520696d..00000000
--- a/docs/v0.14/contributing/provider_development_guide.md
+++ /dev/null
@@ -1,644 +0,0 @@
----
-title: Provider Development Guide
-toc: true
-weight: 1001
-indent: true
----
-
-# Provider Development Guide
-
-Crossplane allows you to manage infrastructure directly from Kubernetes. Each
-infrastructure API resource that Crossplane orchestrates is known as a "managed
-resource". This guide will walk through the process of adding support for a new
-kind of managed resource to a Crossplane Provider.
-
-> You can watch [TBS Episode 18] to follow along the live implementation of GCP PubSub
-managed resource.
-
-## What Makes a Crossplane Infrastructure Resource
-
-Crossplane builds atop Kubernetes's powerful architecture in which declarative
-configuration, known as resources, are continually 'reconciled' with reality by
-one or more controllers. A controller is an endless loop that:
-
-1. Observes the desired state (the declarative configuration resource).
-1. Observes the actual state (the thing said configuration resource represents).
-1. Tries to make the actual state match the desired state.
-
-Typical Crossplane managed infrastructure consists of two configuration
-resources and one controller. The GCP Provider's support for Google Cloud
-Memorystore illustrates this. First, the configuration resources:
-
-1. A [managed resource]. Managed resources are cluster scoped, high-fidelity
- representations of a resource in an external system such as a cloud
- provider's API. Managed resources are _non-portable_ across external systems
- (i.e. cloud providers); they're tightly coupled to the implementation details
- of the external resource they represent. Managed resources are defined by a
- Provider. The GCP Provider's [`CloudMemorystoreInstance`] resource is an
- example of a managed resource.
-1. A provider. Providers enable access to an external system, typically by
- indicating a Kubernetes Secret containing any credentials required to
- authenticate to the system, as well as any other metadata required to
- connect. Providers are cluster scoped, like managed resources and classes.
- The GCP [`ProviderConfig`] is an example of a provider. Note that provider is a
- somewhat overloaded term in the Crossplane ecosystem - it's also used to
- refer to the controller manager for a particular cloud, for example
- `provider-gcp`.
-
-A managed resource is powered by a controller. This controller is responsible
-for taking instances of the aforementioned high-fidelity managed resource kind
-and reconciling them with an external system. The `CloudMemorystoreInstance`
-controller watches for changes to `CloudMemorystoreInstance` resources and calls
-Google's Cloud Memorystore API to create, update, or delete an instance as
-necessary.
-
-Crossplane does not require controllers to be written in any particular
-language. The Kubernetes API server is our API boundary, so any process capable
-of [watching the API server] and updating resources can be a Crossplane
-controller.
-
-## Getting Started
-
-At the time of writing all Crossplane Services controllers are written in Go,
-and built using [crossplane-runtime]. While it is possible to write a controller
-using any language and tooling with a Kubernetes client this set of tools are
-the "[golden path]". They're well supported, broadly used, and provide a shared
-language with the Crossplane community. This guide targets [crossplane-runtime
-v0.9.0]. It assumes the reader is familiar with the Kubernetes [API Conventions]
-and the [kubebuilder book].
-
-## Defining Resource Kinds
-
-Let's assume we want to add Crossplane support for your favourite cloud's
-database-as-a-service. Your favourite cloud brands these instances as "Favourite
-DB instances". Under the hood they're powered by the open source FancySQL
-engine. We'll name the new managed resource kind `FavouriteDBInstance`.
-
-The first step toward implementing a new managed service is to define the code
-level schema of its configuration resources. These are referred to as
-[resources], (resource) [kinds], and [objects] interchangeably. The kubebuilder
-scaffolding is a good starting point for any new Crossplane API kind.
-
-> Note that while Crossplane was originally derived from kubebuilder scaffolds
-> its patterns have diverged somewhat. It is _possible_ to use kubebuilder to
-> scaffold a resource, but the author must be careful to adapt said resource to
-> Crossplane patterns. It may often be quicker to copy and modify a v1beta1 or
-> above resource from the same provider repository, rather than using
-> kubebuilder.
-
-```console
-kubebuilder create api \
- --group example --version v1alpha1 --kind FavouriteDBInstance \
- --resource=true --controller=false --namespaced=false
-```
-
-The above command should produce a scaffold similar to the below example:
-
-```go
-type FavouriteDBInstanceSpec struct {
- // INSERT ADDITIONAL SPEC FIELDS - desired state of infrastructure
- // Important: Run "make" to regenerate code after modifying this file
-}
-
-// FavouriteDBInstanceStatus defines the observed state of FavouriteDBInstance
-type FavouriteDBInstanceStatus struct {
- // INSERT ADDITIONAL STATUS FIELD - define observed state of infrastructure
- // Important: Run "make" to regenerate code after modifying this file
-}
-
-// +kubebuilder:object:root=true
-
-// FavouriteDBInstance is the Schema for the favouritedbinstance API
-// +kubebuilder:resource:scope=Cluster
-type FavouriteDBInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FavouriteDBInstanceeSpec `json:"spec,omitempty"`
- Status FavouriteDBInstanceStatus `json:"status,omitempty"`
-}
-```
-
-Crossplane requires that these newly generated API type scaffolds be extended
-with a set of struct fields, getters, and setters that are standard to all
-Crossplane resource kinds. The getters and setter methods required to satisfy
-crossplane-runtime interfaces are omitted from the below examples for brevity.
-They can be added by hand, but new services are encouraged to use [`angryjet`]
-to generate them automatically using a `//go:generate` comment per the
-[`angryjet` documentation].
-
-Note that in many cases a suitable provider will already exist. Frequently
-adding support for a new managed service requires only the definition of the
-managed resource itself.
-
-### Managed Resource Kinds
-
-Managed resources must:
-
-* Satisfy crossplane-runtime's [`resource.Managed`] interface.
-* Embed a [`ResourceStatus`] struct in their `Status` struct.
-* Embed a [`ResourceSpec`] struct in their `Spec` struct.
-* Embed a `Parameters` struct in their `Spec` struct.
-* Use the `+kubebuilder:subresource:status` [comment marker].
-* Use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-The `Parameters` struct should be a _high fidelity_ representation of the
-writeable fields of the external resource's API. Put otherwise, if your
-favourite cloud represents Favourite DB instances as a JSON object then
-`FavouriteDBParameters` should marshal to a something as close to that JSON
-object as possible while still complying with Kubernetes API conventions.
-
-For example, assume the external API object for Favourite DB instance was:
-
-```json
-{
- "id": 42,
- "name": "mycoolinstance",
- "fanciness_level": 100,
- "version": "2.3",
- "status": "ONLINE",
- "hostname": "cool.fcp.example.org"
-}
-```
-
-Further assume the `id`, `status`, and `hostname` fields were output only, and
-the `version` field was optional. The `FavouriteDBInstance` managed resource
-should look as follows:
-
-```go
-// FavouriteDBInstanceParameters define the desired state of an FavouriteDB
-// instance. Most fields map directly to an Instance:
-// https://favourite.example.org/api/v1/db#Instance
-type FavouriteDBInstanceParameters struct {
-
- // We're still working on a standard for naming external resources. See
- // https://github.com/crossplane/crossplane/issues/624 for context.
-
- // Name of this instance.
- Name string `json:"name"`
-
- // Note that fanciness_level becomes fancinessLevel below. Kubernetes API
- // conventions trump cloud provider fidelity.
-
- // FancinessLevel specifies exactly how fancy this instance is.
- FancinessLevel int `json:"fancinessLevel"`
-
- // Version specifies what version of FancySQL this instance will run.
- // +optional
- Version *string `json:"version,omitempty"`
-}
-
-// A FavouriteDBInstanceSpec defines the desired state of a FavouriteDBInstance.
-type FavouriteDBInstanceSpec struct {
- runtimev1alpha1.ResourceSpec `json:",inline"`
- ForProvider FavouriteDBInstanceParameters `json:"forProvider"`
-}
-
-// A FavouriteDBInstanceStatus represents the observed state of a
-// FavouriteDBInstance.
-type FavouriteDBInstanceStatus struct {
- runtimev1alpha1.ResourceStatus `json:",inline"`
-
- // Note that we add the three "output only" fields here in the status,
- // instead of the parameters. We want this representation to be high
- // fidelity just like the parameters.
-
- // ID of this instance.
- ID int `json:"id,omitempty"`
-
- // Status of this instance.
- Status string `json:"status,omitempty"`
-
- // Hostname of this instance.
- Hostname string `json:"hostname,omitempty"`
-}
-
-// A FavouriteDBInstance is a managed resource that represents a Favourite DB
-// instance.
-// +kubebuilder:subresource:status
-type FavouriteDBInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FavouriteDBInstanceSpec `json:"spec"`
- Status FavouriteDBInstanceStatus `json:"status,omitempty"`
-}
-```
-
-Note that Crossplane uses the GoDoc strings of API kinds to generate user facing
-API documentation. __Document all fields__ and prefer GoDoc that assumes the
-reader is running `kubectl explain`, or reading an API reference, not reading
-the code. Refer to the [Managed Resource API Patterns] one pager for more detail
-on authoring high fidelity managed resources.
-
-### Provider Kinds
-
-You'll typically only need to add a new Provider kind if you're creating an
-infrastructure provider that adds support for a new infrastructure provider.
-
-Providers must:
-
-* Be named exactly `ProviderConfig`.
-* Embed a [`ProviderSpec`] struct in their `Spec` struct.
-* Use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-The Favourite Cloud `ProviderConfig` would look as follows. Note that the cloud to
-which it belongs should be indicated by its API group, i.e. its API Version
-would be `favouritecloud.crossplane.io/v1alpha1` or similar.
-
-```go
-// A ProviderSpec defines the desired state of a Provider.
-type ProviderSpec struct {
- runtimev1alpha1.ProviderSpec `json:",inline"`
-
- // Information required outside of the Secret referenced in the embedded
- // runtimev1alpha1.ProviderSpec that is required to authenticate to the provider.
- // ProjectID is used as an example here.
- ProjectID string `json:"projectID"`
-}
-
-// A Provider configures a Favourite Cloud 'provider', i.e. a connection to a
-// particular Favourite Cloud project using a particular Favourite Cloud service
-// account.
-type Provider struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec ProviderSpec `json:"spec"`
-}
-```
-
-### Finishing Touches
-
-At this point we've defined the managed resource necessary to start
-building controllers. Before moving on to the controllers:
-
-* Add any kubebuilder [comment markers] that may be useful for your resource.
- Comment markers can be used to validate input, or add additional columns to
- the standard `kubectl get` output, among other things.
-* Run `make reviewable` to generate Custom Resource Definitions and additional
- helper methods for your new resource kinds.
-* Make sure any package documentation (i.e. `// Package v1alpha1...` GoDoc,
- including package level comment markers) are in a file named `doc.go`.
- kubebuilder adds them to `groupversion_info.go`, but several code generation
- tools only check `doc.go`.
-
-Finally, add convenience [`GroupVersionKind`] variables for each new resource
-kind. These are typically added to either `register.go` or
-`groupversion_info.go` depending on which version of kubebuilder scaffolded the
-API type:
-
-```go
-// FavouriteDBInstance type metadata.
-var (
- FavouriteDBInstanceKind = reflect.TypeOf(FavouriteDBInstance{}).Name()
- FavouriteDBInstanceKindAPIVersion = FavouriteDBInstanceKind + "." + GroupVersion.String()
- FavouriteDBInstanceGroupVersionKind = GroupVersion.WithKind(FavouriteDBInstanceKind)
-)
-```
-
-Consider opening a draft pull request and asking a Crossplane maintainer for
-review before you start work on the controller!
-
-## Adding Controllers
-
-Crossplane controllers, like those scaffolded by kubebuilder, are built around
-the [controller-runtime] library. controller-runtime flavoured controllers
-encapsulate most of their domain-specific logic in a [`reconcile.Reconciler`]
-implementation. Most Crossplane controllers are one of the three kinds mentioned
-under [What Makes a Crossplane Managed Service]. Each of these controller kinds
-are similar enough across implementations that [crossplane-runtime] provides
-'default' reconcilers. These reconcilers encode what the Crossplane community
-has learned about managing external systems and narrow the problem space from
-reconciling a Kubernetes resource kind with an arbitrary system down to
-Crossplane-specific tasks.
-
-crossplane-runtime provides the following `reconcile.Reconcilers`:
-
-* The [`managed.Reconciler`] reconciles managed resources with external systems
- by instantiating a client of the external API and using it to create, update,
- or delete the external resource as necessary.
-
-Crossplane controllers typically differ sufficiently from those scaffolded by
-kubebuilder that there is little value in using kubebuilder to generate a
-controller scaffold.
-
-### Managed Resource Controllers
-
-Managed resource controllers should use [`managed.NewReconciler`] to wrap a
-managed-resource specific implementation of [`managed.ExternalConnecter`]. Parts
-of `managed.Reconciler`'s behaviour is customisable; refer to the
-[`managed.NewReconciler`] GoDoc for a list of options. The following is an
-example controller for the `FavouriteDBInstance` managed resource we defined
-earlier:
-
-```go
-import (
- "context"
- "fmt"
- "strings"
-
- "github.com/pkg/errors"
- corev1 "k8s.io/api/core/v1"
- "k8s.io/apimachinery/pkg/types"
- ctrl "sigs.k8s.io/controller-runtime"
- "sigs.k8s.io/controller-runtime/pkg/client"
-
- // An API client of the hypothetical FavouriteDB service.
- "github.com/fcp-sdk/v1/services/database"
-
- runtimev1alpha1 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
- "github.com/crossplane/crossplane-runtime/pkg/meta"
- "github.com/crossplane/crossplane-runtime/pkg/resource"
- "github.com/crossplane/crossplane-runtime/pkg/reconciler/managed"
-
- "github.com/crossplane/provider-fcp/apis/database/v1alpha3"
- fcpv1alpha3 "github.com/crossplane/provider-fcp/apis/v1alpha3"
-)
-
-type FavouriteDBInstanceController struct{}
-
-// SetupWithManager instantiates a new controller using a managed.Reconciler
-// configured to reconcile FavouriteDBInstances using an ExternalClient produced by
-// connecter, which satisfies the ExternalConnecter interface.
-func (c *FavouriteDBInstanceController) SetupWithManager(mgr ctrl.Manager) error {
- return ctrl.NewControllerManagedBy(mgr).
- Named(strings.ToLower(fmt.Sprintf("%s.%s", v1alpha3.FavouriteDBInstanceKind, v1alpha3.Group))).
- For(&v1alpha3.FavouriteDBInstance{}).
- Complete(managed.NewReconciler(mgr,
- resource.ManagedKind(v1alpha3.FavouriteDBInstanceGroupVersionKind),
- managed.WithExternalConnecter(&connecter{client: mgr.GetClient()})))
-}
-
-// Connecter satisfies the resource.ExternalConnecter interface.
-type connecter struct{ client client.Client }
-
-// Connect to the supplied resource.Managed (presumed to be a
-// FavouriteDBInstance) by using the Provider it references to create a new
-// database client.
-func (c *connecter) Connect(ctx context.Context, mg resource.Managed) (managed.ExternalClient, error) {
- // Assert that resource.Managed we were passed in fact contains a
- // FavouriteDBInstance. We told NewControllerManagedBy that this was a
- // controller For FavouriteDBInstance, so something would have to go
- // horribly wrong for us to encounter another type.
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return nil, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Get the Provider referenced by the FavouriteDBInstance.
- p := &fcpv1alpha3.Provider{}
- if err := c.client.Get(ctx, meta.NamespacedNameOf(i.Spec.ProviderReference), p); err != nil {
- return nil, errors.Wrap(err, "cannot get Provider")
- }
-
- // Get the Secret referenced by the Provider.
- s := &corev1.Secret{}
- n := types.NamespacedName{Namespace: p.Namespace, Name: p.Spec.Secret.Name}
- if err := c.client.Get(ctx, n, s); err != nil {
- return nil, errors.Wrap(err, "cannot get Provider secret")
- }
-
- // Create and return a new database client using the credentials read from
- // our Provider's Secret.
- client, err := database.NewClient(ctx, s.Data[p.Spec.Secret.Key])
- return &external{client: client}, errors.Wrap(err, "cannot create client")
-}
-
-// External satisfies the resource.ExternalClient interface.
-type external struct{ client database.Client }
-
-// Observe the existing external resource, if any. The managed.Reconciler
-// calls Observe in order to determine whether an external resource needs to be
-// created, updated, or deleted.
-func (e *external) Observe(ctx context.Context, mg resource.Managed) (managed.ExternalObservation, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalObservation{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Use our FavouriteDB API client to get an up to date view of the external
- // resource.
- existing, err := e.client.GetInstance(ctx, i.Spec.Name)
-
- // If we encounter an error indicating the external resource does not exist
- // we want to let the managed.Reconciler know so it can create it.
- if database.IsNotFound(err) {
- return managed.ExternalObservation{ResourceExists: false}, nil
- }
-
- // Any other errors are wrapped (as is good Go practice) and returned to the
- // managed.Reconciler. It will update the "Synced" status condition
- // of the managed resource to reflect that the most recent reconcile failed
- // and ensure the reconcile is reattempted after a brief wait.
- if err != nil {
- return managed.ExternalObservation{}, errors.Wrap(err, "cannot get instance")
- }
-
- // The external resource exists. Copy any output-only fields to their
- // corresponding entries in our status field.
- i.Status.Status = existing.GetStatus()
- i.Status.Hostname = existing.GetHostname()
- i.Status.ID = existing.GetID()
-
- // Update our "Ready" status condition to reflect the status of the external
- // resource. Most managed resources use the below well known reasons that
- // the "Ready" status may be true or false, but managed resource authors
- // are welcome to define and use their own.
- switch i.Status.Status {
- case database.StatusOnline:
- resource.SetBindable(i)
- i.SetConditions(runtimev1alpha1.Available())
- case database.StatusCreating:
- i.SetConditions(runtimev1alpha1.Creating())
- case database.StatusDeleting:
- i.SetConditions(runtimev1alpha1.Deleting())
- }
-
- // Finally, we report what we know about the external resource. In this
- // hypothetical case FancinessLevel is the only field that can be updated
- // after creation time, so the resource does not need to be updated if
- // the actual fanciness level matches our desired fanciness level. Any
- // ConnectionDetails we return will be published to the managed resource's
- // connection secret if it specified one.
- o := managed.ExternalObservation{
- ResourceExists: true,
- ResourceUpToDate: existing.GetFancinessLevel == i.Spec.FancinessLevel,
- ConnectionDetails: managed.ConnectionDetails{
- runtimev1alpha1.ResourceCredentialsSecretUserKey: []byte(existing.GetUsername()),
- runtimev1alpha1.ResourceCredentialsSecretEndpointKey: []byte(existing.GetHostname()),
- },
- }
-
- return o, nil
-}
-
-// Create a new external resource based on the specification of our managed
-// resource. managed.Reconciler only calls Create if Observe reported
-// that the external resource did not exist.
-func (e *external) Create(ctx context.Context, mg resource.Managed) (managed.ExternalCreation, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalCreation{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
- // Indicate that we're about to create the instance. Remember ExternalClient
- // authors can use a bespoke condition reason here in cases where Creating
- // doesn't make sense.
- i.SetConditions(runtimev1alpha1.Creating())
-
- // Create must return any connection details that are set or returned only
- // at creation time. The managed.Reconciler will merge any details
- // with those returned during the Observe phase.
- password := database.GeneratePassword()
- cd := managed.ConnectionDetails{runtimev1alpha1.ResourceCredentialsSecretPasswordKey: []byte(password)}
-
- // Create a new instance.
- new := database.Instance{Name: i.Name, FancinessLevel: i.FancinessLevel, Version: i.Version}
- err := e.client.CreateInstance(ctx, new, password)
-
- // Note that we use resource.Ignore to squash any error that indicates the
- // external resource already exists. Create implementations must not return
- // an error if asked to create a resource that already exists. Real managed
- // resource controllers are advised to avoid unintentially 'adoptign' an
- // existing, unrelated external resource, per
- // https://github.com/crossplane/crossplane-runtime/issues/27
- return managed.ExternalCreation{ConnectionDetails: cd}, errors.Wrap(resource.Ignore(database.IsExists, err), "cannot create instance")
-}
-
-// Update the existing external resource to match the specifications of our
-// managed resource. managed.Reconciler only calls Update if Observe
-// reported that the external resource was not up to date.
-func (e *external) Update(ctx context.Context, mg resource.Managed) (managed.ExternalUpdate, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return managed.ExternalUpdate{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Recall that FancinessLevel is the only field that we _can_ update.
- new := database.Instance{Name: i.Name, FancinessLevel: i.FancinessLevel}
- err := e.client.UpdateInstance(ctx, new)
- return managed.ExternalUpdate{}, errors.Wrap(err, "cannot update instance")
-}
-
-// Delete the external resource. managed.Reconciler only calls Delete
-// when a managed resource with the 'Delete' deletion policy (the default) has
-// been deleted.
-func (e *external) Delete(ctx context.Context, mg resource.Managed) error {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return errors.New("managed resource is not a FavouriteDBInstance")
- }
- // Indicate that we're about to delete the instance.
- i.SetConditions(runtimev1alpha1.Deleting())
-
- // Delete the instance.
- err := e.client.DeleteInstance(ctx, i.Spec.Name)
-
- // Note that we use resource.Ignore to squash any error that indicates the
- // external resource does not exist. Delete implementations must not return
- // an error when asked to delete a non-existent external resource.
- return errors.Wrap(resource.Ignore(database.IsNotFound, err), "cannot delete instance")
-}
-```
-
-### Wrapping Up
-
-Once all your controllers are in place you'll want to test them. Note that most
-projects under the [crossplane org] [favor] table driven tests that use Go's
-standard library `testing` package over kubebuilder's Gingko based tests. Please
-do not add or proliferate Gingko based tests.
-
-Finally, don't forget to plumb any newly added resource kinds and controllers up
-to your controller manager. Simple providers may do this for each type within
-within `main()`, but most more complicated providers take an approach in which
-each package exposes an `AddToScheme` (for resource kinds) or `SetupWithManager`
-(for controllers) function that invokes the same function within its child
-packages, resulting in a `main.go` like:
-
-```go
-import (
- "time"
-
- "sigs.k8s.io/controller-runtime/pkg/client/config"
- "sigs.k8s.io/controller-runtime/pkg/manager"
- "sigs.k8s.io/controller-runtime/pkg/manager/signals"
-
- crossplaneapis "github.com/crossplane/crossplane/apis"
-
- fcpapis "github.com/crossplane/provider-fcp/apis"
- "github.com/crossplane/provider-fcp/pkg/controller"
-)
-
-func main() {
- cfg, err := config.GetConfig()
- if err != nil {
- panic(err)
- }
-
- mgr, err := manager.New(cfg, manager.Options{SyncPeriod: 1 * time.Hour})
- if err != nil {
- panic(err)
- }
-
- if err := crossplaneapis.AddToScheme(mgr.GetScheme()); err != nil {
- panic(err)
- }
-
- if err := fcpapis.AddToScheme(mgr.GetScheme()); err != nil {
- panic(err)
- }
-
- if err := controller.SetupWithManager(mgr); err != nil {
- panic(err)
- }
-
- panic(mgr.Start(signals.SetupSignalHandler()))
-}
-```
-
-## In Review
-
-In this guide we walked through the process of defining the resource kinds and
-controllers necessary to build support for new managed infrastructure; possibly
-even a completely new infrastructure provider. Please do not hesitate to [reach
-out] to the Crossplane maintainers and community for help designing and
-implementing support for new managed services. We would highly value any
-feedback you may have about the development process!
-
-
-
-[TBS Episode 18]: https://www.youtube.com/watch?v=rvQ8N0u3rkE&t=7s
-[What Makes a Crossplane Infrastructure Resource]: #what-makes-a-crossplane-infrastructure-resource
-[managed resource]: ../introduction/managed-resources.md
-[`CloudMemorystoreInstance`]: https://github.com/crossplane/provider-gcp/blob/85a6ed3c669a021f1d61be51b2cbe2714b0bc70b/apis/cache/v1beta1/cloudmemorystore_instance_types.go#L184
-[`ProviderConfig`]: https://github.com/crossplane/provider-gcp/blob/be5aaf6/apis/v1beta1/providerconfig_types.go#L39
-[watching the API server]: https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
-[controller-runtime]: https://github.com/kubernetes-sigs/controller-runtime
-[crossplane-runtime]: https://github.com/crossplane/crossplane-runtime/
-[golden path]: https://charity.wtf/2018/12/02/software-sprawl-the-golden-path-and-scaling-teams-with-agency/
-[API Conventions]: https://github.com/kubernetes/community/blob/c6e1e89a/contributors/devel/sig-architecture/api-conventions.md
-[kubebuilder book]: https://book.kubebuilder.io/
-[resources]: https://kubebuilder.io/cronjob-tutorial/gvks.html#kinds-and-resources
-[kinds]: https://kubebuilder.io/cronjob-tutorial/gvks.html#kinds-and-resources
-[objects]: https://kubernetes.io/docs/concepts/#kubernetes-objects
-[comment marker]: https://kubebuilder.io/reference/markers.html
-[comment markers]: https://kubebuilder.io/reference/markers.html
-[`resource.Managed`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/resource#Managed
-[`managed.Reconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#Reconciler
-[`managed.NewReconciler`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#NewReconciler
-[`managed.ExternalConnecter`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalConnecter
-[`managed.ExternalClient`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalClient
-[`ResourceSpec`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ResourceSpec
-[`ResourceStatus`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ResourceStatus
-[`ProviderSpec`]: https://godoc.org/github.com/crossplane/crossplane-runtime/apis/core/v1alpha1#ProviderSpec
-['managed.ExternalConnecter`]: https://godoc.org/github.com/crossplane/crossplane-runtime/pkg/reconciler/managed#ExternalConnecter
-[opening a Crossplane issue]: https://github.com/crossplane/crossplane/issues/new/choose
-[`GroupVersionKind`]: https://godoc.org/k8s.io/apimachinery/pkg/runtime/schema#GroupVersionKind
-[`reconcile.Reconciler`]: https://godoc.org/sigs.k8s.io/controller-runtime/pkg/reconcile#Reconciler
-[favor]: https://github.com/crossplane/crossplane/issues/452
-[reach out]: https://github.com/crossplane/crossplane#get-involved
-[crossplane org]: https://github.com/crossplane
-[`angryjet`]: https://github.com/crossplane/crossplane-tools
-[Managed Resource API Patterns]: ../design/one-pager-managed-resource-api-design.md
-[Crossplane CLI]: https://github.com/crossplane/crossplane-cli#quick-start-stacks
-[`angryjet` documentation]: https://github.com/crossplane/crossplane-tools/blob/master/README.md
diff --git a/docs/v0.14/faqs/faqs.md b/docs/v0.14/faqs/faqs.md
deleted file mode 100644
index d3128cb4..00000000
--- a/docs/v0.14/faqs/faqs.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: FAQ
-toc: true
-weight: 1200
----
-
-# Frequently Asked Questions (FAQs)
-
-### Where did the name Crossplane come from?
-
-Crossplane is the fusing of cross-cloud control plane. We wanted to use a noun
-that refers to the entity responsible for connecting different cloud providers
-and acts as control plane across them. Cross implies “cross-cloud” and “plane”
-brings in “control plane”.
-
-### What's up with popsicle?
-
-We believe in a multi-flavor cloud.
-
-### Related Projects
-See [Related Projects].
-
-[Related Projects]: related_projects.md
diff --git a/docs/v0.14/faqs/related_projects.md b/docs/v0.14/faqs/related_projects.md
deleted file mode 100644
index 87f652fc..00000000
--- a/docs/v0.14/faqs/related_projects.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: Related Projects
-toc: true
-weight: 1201
-indent: true
----
-
-# Related Projects
-
-While there are many projects that address similar issues, none of them
-encapsulate the full use case that Crossplane addresses. This list is not
-exhaustive and is not meant to provide a deep analysis of the following
-projects, but instead to motivate why Crossplane was created.
-
-## Open Service Broker and Service Catalog
-
-The [Open Service Broker] and the [Kubernetes Service Catalog] are able to
-dynamically provision cloud services from Kubernetes. As a result it shares
-similar goals with Crossplane. However, service broker does not have the
-ability to define, compose, and publish your own infrastructure resources to
-the Kubernetes API in a no-code way. Crossplane goes further by enabling
-infrastructure operators to hide infrastructure complexity and include policy
-guardrails, with a team-centric approach and a strong separation of concerns,
-so applications can easily and safely consume the infrastructure they need,
-using any tool that works with the Kubernetes API. Solutions like the [GCP
-implementation of Open Service Broker][GCP OSB] have been deprecated in favor
-of a more Kubernetes-native solution, but one that is Google-specific and
-closed source.
-
-## GCP Config Connector
-
-The [GCP Config Connector] is the GCP replacement for Open Service Broker, and
-implements a set of Kubernetes controllers that are able to provision managed
-services in GCP. It defines a set of CRDs for managed services like CloudSQL,
-and controllers that can provision them via their cloud APIs. It is similar to
-Crossplane in that it can provision managed services in GCP. Crossplane goes
-further by enabling you to provision managed services from any cloud
-provider and the ability to define, compose, and publish your own
-infrastructure resources in a no-code way. Crossplane supports a team-centric
-approach with a strong separation of concerns, that enables applications to
-easily and safely consume the infrastructure they need, using any tool that
-works with the Kubernetes API. GCP Config Connector is closed-source.
-
-## AWS Service Operator
-
-The [AWS Service Operator] is a recent project that implements a set of
-Kubernetes controllers that are able to provision managed services in AWS. It
-defines a set of CRDs for managed services like DynamoDB, and controllers that
-can provision them via AWS CloudFormation. It is similar to Crossplane in that
-it can provision managed services in AWS. Crossplane goes further by
-enabling you to provision managed services from any cloud provider and the
-ability to define, compose, and publish your own infrastructure API types in
-Kubernetes in a no-code way. Crossplane supports a team-centric approach with a
-strong separation of concerns, that enables applications to easily and safely
-consume the infrastructure they need, using any tool that works with the
-Kubernetes API.
-
-## AWS CloudFormation, GCP Deployment Manager, and Others
-
-These products offer a declarative model for deploying and provisioning
-infrastructure in each of the respective cloud providers. They only work for
-one cloud provider, are generally closed source, and offer little or no
-extensibility points, let alone being able to extend the Kubernetes API to
-provide your own infrastructure abstractions in a no-code way. We have
-considered using some of these products as a way to implement resource
-controllers in Crossplane. These projects use an Infrastructure as Code
-approach to management, while Crossplane offers an API-driven control plane.
-
-## Terraform and Pulumi
-
-[Terraform] and [Pulumi] are tools for provisioning infrastructure across cloud
-providers that offer a declarative configuration language with support for
-templating, composability, referential integrity and dependency management.
-Terraform can declaratively manage any compatible API and perform changes when
-the tool is run by a human or in a deployment pipeline. Terraform is an
-Infrastructure as Code tool, while Crossplane offers an API-driven control
-plane.
-
-
-
-[Open Service Broker]: https://www.openservicebrokerapi.org/
-[Kubernetes Service Catalog]: https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/
-[GCP OSB]: https://cloud.google.com/kubernetes-engine/docs/concepts/google-cloud-platform-service-broker
-[GCP Config Connector]: https://cloud.google.com/config-connector/docs/overview
-[AWS Service Operator]: https://github.com/awslabs/aws-service-operator
-[Terraform]: https://www.terraform.io/
-[Pulumi]: https://www.pulumi.com/
diff --git a/docs/v0.14/getting-started/compose-infrastructure.md b/docs/v0.14/getting-started/compose-infrastructure.md
deleted file mode 100644
index 241173a7..00000000
--- a/docs/v0.14/getting-started/compose-infrastructure.md
+++ /dev/null
@@ -1,391 +0,0 @@
----
-title: Compose Infrastructure
-toc: true
-weight: 4
-indent: true
----
-
-# Compose Infrastructure
-
-In the [last section] we learned that Crossplane can be extended by installing
-_providers_, which add support for managed resources. A managed resource is a
-Kubernetes custom resource that offers a high fidelity representation of an
-infrastructure primitive, like an SQL instance or a firewall rule. Crossplane
-goes beyond simply modelling infrastructure primitives as custom resources - it
-enables you to define new custom resources with schemas of your choosing. These
-resources are composed of managed resources, allowing you to define and offer
-resources that group and abstract infrastructure primitives. We call these
-"composite resources" (XRs).
-
-XRs are always cluster scoped - they exist outside of any namespace. This allows
-an XR to represent infrastructure that might be consumed from several different
-namespaces. This is often true for VPC networks - an infrastructure operator may
-wish to define a VPC network XR and an SQL instance XR, only the latter of which
-may be managed by application operators. The application operators are
-restricted to their team's namespace, but their SQL instances should all be
-attached to the VPC network that the infrastructure operator manages. Crossplane
-enables scenarios like this by allowing the infrastructure operator to offer
-their application operators a _composite resource claim_ (XRC). An XRC is a
-namespaced proxy for an XR; the schema of an XRC is identical to that of its
-corresponding XR. When an application operator creates an XRC, a corresponding
-backing XR is created automatically.
-
-We use two special Crossplane resources to define and configure new XRs and
-XRCs:
-
-- A `CompositeResourceDefinition` (XRD) _defines_ a new kind of composite
- resource, including its schema. An XRD may optionally _offer_ a claim.
-- A `Composition` specifies which resources a composite resource will be
- composed of, and how they should be configured. You can create multiple
- `Composition` options for each composite resource.
-
-XRDs and Compositions may be packaged and installed as a _configuration_. A
-configuration is a [package] of composition configuration that can easily be
-installed to Crossplane by creating a declarative `Configuration` resource, or
-by using `kubectl crossplane install configuration`. In the examples below we
-will install a configuration that defines a new `CompositePostgreSQLInstance` XR
-that takes a single `storageGB` parameter, and creates a connection `Secret`
-with keys for `username`, `password`, and `endpoint`. A `Configuration` exists
-for each provider that can satisfy a `PostgreSQLInstance`. Let's get started!
-
-## Configure and Claim Your Infrastructure
-
-We will now install a `Configuration` that:
-
-- Defines a `CompositePostgreSQLInstance` XR.
-- Offers a `PostgreSQLInstance` claim (XRC) for said XR.
-- Creates a `Composition` that can satisfy our XR.
-
-
-
-> Note that this configuration will create an RDS instance using your default
-> VPC, which may or may not allow connections from the internet depending on how
-> it is configured. Select the AWS (New VPC) configuration if you wish to create
-> an RDS instance that will allow traffic from the internet.
-
-```console
-kubectl crossplane install configuration crossplane/getting-started-with-aws:master
-```
-
-
-
-
-> Note that this configuration for AWS also includes several networking managed
-> resources that are required to provision a publicly available PostgreSQL
-> instance. Composition enables scenarios such as this, as well as far more
-> complex ones. See the [composition] documentation for more information.
-
-```console
-kubectl crossplane install configuration crossplane/getting-started-with-aws-with-vpc:master
-```
-
-
-
-Crossplane should now be configured to allow us to create a `PostgreSQLInstance`
-claim! You can make sure your `Configuration` installed successfully by running:
-
-```console
-kubectl describe configuration
-```
-
-Make sure you've [setup] a `ProviderConfig` named `default` for your chosen
-provider, then create your XRC to provision a PostgreSQL instance and all the
-supporting infrastructure (VPCs, firewall rules, resource groups, etc) that it
-may need!
-
-
-
-After creating the `PostgreSQLInstance` Crossplane will begin provisioning a
-database instance on your provider of choice. Once provisioning is complete, you
-should see `READY: True` in the output when you run:
-
-```console
-kubectl get postgresqlinstance my-db
-```
-
-> Note: while waiting for the `PostgreSQLInstance` to become ready, you
-> may want to look at other resources in your cluster. The following commands
-> will allow you to view groups of Crossplane resources:
->
-> - `kubectl get claim`: get all resources of all claim kinds, like `PostgreSQLInstance`.
-> - `kubectl get composite`: get all resources that are of composite kind, like `CompositePostgreSQLInstance`.
-> - `kubectl get managed`: get all resources that represent a unit of external
-> infrastructure.
-> - `kubectl get `: get all resources related to ``.
-> - `kubectl get crossplane`: get all resources related to Crossplane.
-
-Try the following command to watch your provisioned resources become ready:
-
-```console
-kubectl get crossplane -l crossplane.io/claim-name=my-db
-```
-
-Once your `PostgreSQLInstance` is ready, you should see a `Secret` in the `default`
-namespace named `db-conn` that contains keys that we defined in XRD. If they were
-filled by the composition, then they should appear:
-
-```console
-$ kubectl describe secrets db-conn
-Name: db-conn
-Namespace: default
-...
-
-Type: connection.crossplane.io/v1alpha1
-
-Data
-====
-password: 27 bytes
-port: 4 bytes
-username: 25 bytes
-endpoint: 45 bytes
-```
-
-## Consume Your Infrastructure
-
-Because connection secrets are written as a Kubernetes `Secret` they can easily
-be consumed by Kubernetes primitives. The most basic building block in
-Kubernetes is the `Pod`. Let's define a `Pod` that will show that we are able to
-connect to our newly provisioned database.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: see-db
- namespace: default
-spec:
- containers:
- - name: see-db
- image: postgres:9.6
- command: ['psql']
- args: ['-c', 'SELECT current_database();']
- env:
- - name: PGDATABASE
- value: postgres
- - name: PGHOST
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: endpoint
- - name: PGUSER
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: username
- - name: PGPASSWORD
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: password
- - name: PGPORT
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: port
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/compose/pod.yaml
-```
-
-This `Pod` simply connects to a PostgreSQL database and prints its name, so you
-should see the following output (or similar) after creating it if you run
-`kubectl logs see-db`:
-
-```SQL
- current_database
-------------------
- postgres
-(1 row)
-```
-
-## Clean Up
-
-To clean up the `Pod`, run:
-
-```console
-kubectl delete pod see-db
-```
-
-To clean up the infrastructure that was provisioned, you can delete the
-`PostgreSQLInstance` XRC:
-
-```console
-kubectl delete postgresqlinstance my-db
-```
-
-> Don't clean up your `Configuration` just yet if you plan to continue on to the
-> next section of the guide! We'll use them again when we deploy an OAM
-> application.
-
-## Next Steps
-
-Now you have seen how to provision and publish more complex infrastructure
-setups. In the [next section] you will learn how to consume infrastructure
-alongside your [OAM] application manifests.
-
-
-
-[last section]: provision-infrastructure.md
-[composition]: ../introduction/composition.md
-[package]: ../introduction/packages.md
-[setup]: install-configure.md
-[next section]: run-applications.md
-[OAM]: https://oam.dev/
diff --git a/docs/v0.14/getting-started/install-configure.md b/docs/v0.14/getting-started/install-configure.md
deleted file mode 100644
index b9058b2b..00000000
--- a/docs/v0.14/getting-started/install-configure.md
+++ /dev/null
@@ -1,380 +0,0 @@
----
-title: Install & Configure
-toc: true
-weight: 2
-indent: true
----
-
-# Install & Configure Crossplane
-
-Crossplane can be easily installed into any existing Kubernetes cluster using
-the regularly published Helm chart. The Helm chart contains all the custom
-resources and controllers needed to deploy and configure Crossplane.
-
-See [Install] and [Configure] docs for installing alternate versions and more
-detailed instructions.
-
-## Get a Kubernetes Cluster
-
-
-For macOS / Linux use the following:
-
-* [Kubernetes cluster]
- * [Kind]
- * [Minikube], minimum version `v0.28+`
- * etc.
-
-* [Helm], minimum version `v3.0.0+`.
-
-
-
-For Windows use the following:
-
-* [Kubernetes cluster]
- * [Kind]
- * [Minikube], minimum version `v0.28+`
- * etc.
-
-* [Helm], minimum version `v3.0.0+`.
-
-
-
-## Check Crossplane Status
-
-```console
-helm list -n crossplane-system
-
-kubectl get all -n crossplane-system
-```
-
-## Install Crossplane CLI
-
-The Crossplane CLI extends `kubectl` with functionality to build, push, and install [Crossplane packages]:
-
-```console
-curl -sL https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/install.sh | sh
-```
-
-## Select Provider
-
-Install and configure a provider for Crossplane to use for infrastructure provisioning:
-
-
-### Install AWS Provider
-
-```console
-kubectl crossplane install provider crossplane/provider-aws:alpha
-```
-
-### Get AWS Account Keyfile
-
-Using an AWS account with permissions to manage RDS databases:
-
-```console
-AWS_PROFILE=default && echo -e "[default]\naws_access_key_id = $(aws configure get aws_access_key_id --profile $AWS_PROFILE)\naws_secret_access_key = $(aws configure get aws_secret_access_key --profile $AWS_PROFILE)" > creds.conf
-```
-
-### Create a Provider Secret
-
-```console
-kubectl create secret generic aws-creds -n crossplane-system --from-file=key=./creds.conf
-```
-
-### Configure the Provider
-
-We will create the following `ProviderConfig` object to configure credentials for AWS
-Provider:
-
-```yaml
-apiVersion: aws.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: default
-spec:
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: aws-creds
- key: key
-```
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/configure/aws/providerconfig.yaml
-```
-
-
-
-
-### Install GCP Provider
-
-```console
-kubectl crossplane install provider crossplane/provider-gcp:alpha
-```
-
-### Get GCP Account Keyfile
-
-```console
-# replace this with your own gcp project id and the name of the service account
-# that will be created.
-PROJECT_ID=my-project
-NEW_SA_NAME=test-service-account-name
-
-# create service account
-SA="${NEW_SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
-gcloud iam service-accounts create $NEW_SA_NAME --project $PROJECT_ID
-
-# enable cloud API
-SERVICE="sqladmin.googleapis.com"
-gcloud services enable $SERVICE --project $PROJECT_ID
-
-# grant access to cloud API
-ROLE="roles/cloudsql.admin"
-gcloud projects add-iam-policy-binding --role="$ROLE" $PROJECT_ID --member "serviceAccount:$SA"
-
-# create service account keyfile
-gcloud iam service-accounts keys create creds.json --project $PROJECT_ID --iam-account $SA
-```
-
-### Create a Provider Secret
-
-```console
-kubectl create secret generic gcp-creds -n crossplane-system --from-file=key=./creds.json
-```
-
-### Configure the Provider
-
-We will create the following `ProviderConfig` object to configure credentials for GCP
-Provider:
-
-```console
-# replace this with your own gcp project id
-PROJECT_ID=my-project
-echo "apiVersion: gcp.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: default
-spec:
- projectID: ${PROJECT_ID}
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: gcp-creds
- key: key" | kubectl apply -f -
-```
-
-
-
-
-### Install Azure Provider
-
-```console
-kubectl crossplane install provider crossplane/provider-azure:alpha
-```
-
-### Get Azure Principal Keyfile
-
-```console
-# create service principal with Owner role
-az ad sp create-for-rbac --sdk-auth --role Owner > "creds.json"
-
-# we need to get the clientId from the json file to add Azure Active Directory
-# permissions.
-if which jq > /dev/null 2>&1; then
- AZURE_CLIENT_ID=$(jq -r ".clientId" < "./creds.json")
-else
- AZURE_CLIENT_ID=$(cat creds.json | grep clientId | cut -c 16-51)
-fi
-
-RW_ALL_APPS=1cda74f2-2616-4834-b122-5cb1b07f8a59
-RW_DIR_DATA=78c8a3c8-a07e-4b9e-af1b-b5ccab50a175
-AAD_GRAPH_API=00000002-0000-0000-c000-000000000000
-
-az ad app permission add --id "${AZURE_CLIENT_ID}" --api ${AAD_GRAPH_API} --api-permissions ${RW_ALL_APPS}=Role ${RW_DIR_DATA}=Role
-az ad app permission grant --id "${AZURE_CLIENT_ID}" --api ${AAD_GRAPH_API} --expires never > /dev/null
-az ad app permission admin-consent --id "${AZURE_CLIENT_ID}"
-```
-
-### Create a Provider Secret
-
-```console
-kubectl create secret generic azure-creds -n crossplane-system --from-file=key=./creds.json
-```
-
-### Configure the Provider
-
-We will create the following `ProviderConfig` object to configure credentials for
-Azure Provider:
-
-```yaml
-apiVersion: azure.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: default
-spec:
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: azure-creds
- key: key
-```
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/configure/azure/providerconfig.yaml
-```
-
-
-
-
-### Install Alibaba Provider
-
-```console
-kubectl crossplane install provider crossplane/provider-alibaba:alpha
-```
-
-### Create a Provider Secret
-
-```console
-# Replace and with your actual key id and key secret.
-kubectl create secret generic alibaba-creds --from-literal=accessKeyId= --from-literal=accessKeySecret= -n crossplane-system
-```
-
-### Configure the Provider
-
-We will create the following `ProviderConfig` object to configure credentials for
-Alibaba Provider:
-
-```yaml
-apiVersion: alibaba.crossplane.io/v1alpha1
-kind: ProviderConfig
-metadata:
- name: default
-spec:
- region: cn-beijing
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: alibaba-creds
- # "key" field does not have any effect right now but it has to be given.
- # See https://github.com/crossplane/crossplane-runtime/issues/215
- key: credentials
-```
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/configure/alibaba/providerconfig.yaml
-```
-
-
-
-
-## Next Steps
-
-Now that you have a provider configured, you can [provision infrastructure].
-
-## More Info
-
-See [Install] and [Configure] docs for installing alternate versions and more
-detailed instructions.
-
-## Uninstall Provider
-
-Let's check whether there are any managed resources before deleting the provider.
-
-```console
-kubectl get managed
-```
-
-If there are any, please delete them first so you don't lose track of them.
-
-```console
-kubectl delete -f provider.yaml
-```
-
-## Uninstall Crossplane
-
-```console
-helm delete crossplane --namespace crossplane-system
-
-kubectl delete namespace crossplane-system
-```
-
-
-
-[provision infrastructure]: provision-infrastructure.md
-[Install]: ../reference/install.md
-[Configure]: ../reference/configure.md
-[Kubernetes cluster]: https://kubernetes.io/docs/setup/
-[Minikube]: https://kubernetes.io/docs/tasks/tools/install-minikube/
-[Helm]: https://docs.helm.sh/using_helm/
-[Kind]: https://kind.sigs.k8s.io/docs/user/quick-start/
-[Crossplane packages]: ../introduction/packages.md
diff --git a/docs/v0.14/getting-started/package-infrastructure.md b/docs/v0.14/getting-started/package-infrastructure.md
deleted file mode 100644
index bd5da3c4..00000000
--- a/docs/v0.14/getting-started/package-infrastructure.md
+++ /dev/null
@@ -1,692 +0,0 @@
----
-title: Package Infrastructure
-toc: true
-weight: 6
-indent: true
----
-
-# Package Infrastructure
-
-In a [previous section] we learned that Crossplane can be configured with new
-composite resources (XRs) that are [composed] of other resources, allowing you
-to define and offer resources that group and abstract infrastructure primitives.
-We use two special Crossplane resources to define and configure new XRs and
-XRCs:
-
-- A `CompositeResourceDefinition` (XRD) _defines_ a new kind of composite
- resource, including its schema. An XRD may optionally _offer_ a claim.
-- A `Composition` specifies which resources a composite resource will be
- composed of, and how they should be configured. You can create multiple
- `Composition` options for each composite resource.
-
-XRDs and Compositions may be [packaged] as a _configuration_, that may easily be
-installed to Crossplane by creating a declarative `Configuration` resource, or
-by using `kubectl crossplane install configuration`. In the examples below we
-will build and push a configuration that defines a new
-`CompositePostgreSQLInstance` XR that takes a single `storageGB` parameter, and
-creates a connection `Secret` with keys for `username`, `password`, and
-`endpoint`.
-
-## Create a Configuration Directory
-
-Our configuration will consist of three files:
-
-* `crossplane.yaml` - Metadata about the configuration.
-* `definition.yaml` - The XRD.
-* `composition.yaml` - The Composition.
-
-Crossplane can create a configuration from any directory with a valid
-`crossplane.yaml` metadata file at its root, and one or more XRDs or
-Compositions. The directory structure does not matter, as long as the
-`crossplane.yaml` file is at the root. Note that a configuration need not
-contain one XRD and one composition - it could include only an XRD, only a
-composition, several compositions, or any combination thereof.
-
-Before we go any further, we must create a directory in which to build our
-configuration:
-
-```console
-mkdir crossplane-config
-cd crossplane-config
-```
-
-We'll create the aforementioned three files in this directory, then build them
-into a package.
-
-## Create CompositeResourceDefinition
-
-First we'll create a `CompositeResourceDefinition` (XRD) to define the schema of
-our `CompositePostgreSQLInstance` and its `PostgreSQLInstance` resource claim.
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1beta1
-kind: CompositeResourceDefinition
-metadata:
- name: compositepostgresqlinstances.database.example.org
-spec:
- group: database.example.org
- names:
- kind: CompositePostgreSQLInstance
- plural: compositepostgresqlinstances
- claimNames:
- kind: PostgreSQLInstance
- plural: postgresqlinstances
- connectionSecretKeys:
- - username
- - password
- - endpoint
- - port
- versions:
- - name: v1alpha1
- served: true
- referenceable: true
- schema:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- parameters:
- type: object
- properties:
- storageGB:
- type: integer
- required:
- - storageGB
- required:
- - parameterss
-```
-
-```console
-curl -OL https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/package/definition.yaml
-```
-
-> You might notice that the XRD we created specifies both "names" and "claim
-> names". This is because the composite resource it defines offers a composite
-> resource claim (XRC).
-
-## Create Compositions
-
-Now we'll specify which managed resources our `CompositePostgreSQLInstance` XR
-and its claim could be composed of, and how they should be configured. We do
-this by defining a `Composition` that can satisfy the XR we defined above. In
-this case, our `Composition` will specify how to provision a public PostgreSQL
-instance on the chosen provider.
-
-
-
-## Build and Push The Configuration
-
-Finally, we'll author our metadata file then build and push our configuration
-so that Crossplane users may install it.
-
-> Note that Crossplane pushes packages to an OCI registry - currently [Docker
-> Hub] by default. You may need to run `docker login` before you are able to
-> push a package.
-
-
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: getting-started-with-aws
- annotations:
- guide: quickstart
- provider: aws
- vpc: default
-```
-
-```console
-curl -OL https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/package/aws/crossplane.yaml
-
-# Set this to the Docker Hub username or OCI registry you wish to use.
-REG=my-package-repo
-
-kubectl crossplane build configuration
-kubectl crossplane push configuration ${REG}/getting-started-with-aws:master
-```
-
-
-
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: getting-started-with-aws-with-vpc
- annotations:
- guide: quickstart
- provider: aws
- vpc: new
-```
-
-```console
-curl -OL https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/package/aws-with-vpc/crossplane.yaml
-
-# Set this to the Docker Hub username or OCI registry you wish to use.
-REG=my-package-repo
-
-kubectl crossplane build configuration
-kubectl crossplane push configuration ${REG}/getting-started-with-aws-with-vpc:master
-```
-
-
-
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: getting-started-with-gcp
- annotations:
- guide: quickstart
- provider: gcp
-```
-
-```console
-curl -OL https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/package/gcp/crossplane.yaml
-
-# Set this to the Docker Hub username or OCI registry you wish to use.
-REG=my-package-repo
-
-kubectl crossplane build configuration
-kubectl crossplane push configuration ${REG}/getting-started-with-gcp:master
-```
-
-
-
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: getting-started-with-azure
- annotations:
- guide: quickstart
- provider: azure
-```
-
-```console
-curl -OL https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/package/azure/crossplane.yaml
-
-# Set this to the Docker Hub username or OCI registry you wish to use.
-REG=my-package-repo
-
-kubectl crossplane build configuration
-kubectl crossplane push configuration ${REG}/getting-started-with-azure:master
-```
-
-
-
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: getting-started-with-alibaba
- annotations:
- guide: quickstart
- provider: alibaba
-```
-
-```console
-curl -OL https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/package/alibaba/crossplane.yaml
-
-# Set this to the Docker Hub username or OCI registry you wish to use.
-REG=my-package-repo
-
-kubectl crossplane build configuration
-kubectl crossplane push configuration ${REG}/getting-started-with-alibaba:master
-```
-
-
-
-
-That's it! You've now built and pushed your package. Take a look at the
-Crossplane [packages] documentation for more information about installing and
-working with packages.
-
-## Clean Up
-
-To clean up, you can simply delete your package directory:
-
-```console
-cd ..
-rm -rf crossplane-config
-```
-
-
-
-[previous section]: compose-infrastructure.md
-[composed]: ../introduction/composition.md
-[composition]: ../introduction/composition.md
-[Docker Hub]: https://hub.docker.com/
-[packages]: ../introduction/packages.md
-[packaged]: ../introduction/packages.md
diff --git a/docs/v0.14/getting-started/provision-infrastructure.md b/docs/v0.14/getting-started/provision-infrastructure.md
deleted file mode 100644
index 553d4e91..00000000
--- a/docs/v0.14/getting-started/provision-infrastructure.md
+++ /dev/null
@@ -1,257 +0,0 @@
----
-title: Provision Infrastructure
-toc: true
-weight: 3
-indent: true
----
-
-# Provision Infrastructure
-
-Crossplane allows you to provision infrastructure anywhere using the Kubernetes
-API. Once you have [installed a provider] and [configured your credentials], you
-can create any infrastructure currently supported by the provider. Let's start
-by provisioning a database on your provider of choice.
-
-Each provider below offers their own flavor of a managed database. When you
-install a provider it extends Crossplane by adding support for several "managed
-resources". A managed resource is a cluster-scoped Kubernetes custom resource
-that represents an infrastructure object, such as a database instance.
-
-
-
-The AWS provider supports provisioning an [RDS] instance via the `RDSInstance`
-managed resource it adds to Crossplane.
-
-```yaml
-apiVersion: database.aws.crossplane.io/v1beta1
-kind: RDSInstance
-metadata:
- name: rdspostgresql
-spec:
- forProvider:
- dbInstanceClass: db.t2.small
- masterUsername: masteruser
- allocatedStorage: 20
- engine: postgres
- engineVersion: "9.6"
- skipFinalSnapshotBeforeDeletion: true
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: aws-rdspostgresql-conn
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/provision/aws.yaml
-```
-
-Creating the above instance will cause Crossplane to provision an RDS instance
-on AWS. You can view the progress with the following command:
-
-```console
-kubectl get rdsinstance rdspostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can take a look at its connection secret that is referenced under `spec.writeConnectionSecretToRef`:
-
-```console
-kubectl describe secret aws-rdspostgresql-conn -n crossplane-system
-```
-
-You can then delete the `RDSInstance`:
-
-```console
-kubectl delete rdsinstance rdspostgresql
-```
-
-
-
-
-The GCP provider supports provisioning a [CloudSQL] instance with the
-`CloudSQLInstance` managed resource it adds to Crossplane.
-
-```yaml
-apiVersion: database.gcp.crossplane.io/v1beta1
-kind: CloudSQLInstance
-metadata:
- name: cloudsqlpostgresql
-spec:
- forProvider:
- databaseVersion: POSTGRES_9_6
- region: us-central1
- settings:
- tier: db-custom-1-3840
- dataDiskType: PD_SSD
- dataDiskSizeGb: 10
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: cloudsqlpostgresql-conn
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/provision/gcp.yaml
-```
-
-Creating the above instance will cause Crossplane to provision a CloudSQL
-instance on GCP. You can view the progress with the following command:
-
-```console
-kubectl get cloudsqlinstance cloudsqlpostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can take a look at its connection secret that is referenced under `spec.writeConnectionSecretToRef`:
-
-```console
-kubectl describe secret cloudsqlpostgresql-conn -n crossplane-system
-```
-
-You can then delete the `CloudSQLInstance`:
-
-```console
-kubectl delete cloudsqlinstance cloudsqlpostgresql
-```
-
-
-
-
-The Azure provider supports provisioning an [Azure Database for PostgreSQL]
-instance with the `PostgreSQLServer` managed resource it adds to Crossplane.
-
-> Note: provisioning an Azure Database for PostgreSQL requires the presence of a
-> [Resource Group] in your Azure account. We go ahead and provision a new
-> `ResourceGroup` here in case you do not already have a suitable one in your
-> account.
-
-```yaml
-apiVersion: azure.crossplane.io/v1alpha3
-kind: ResourceGroup
-metadata:
- name: sqlserverpostgresql-rg
-spec:
- location: West US 2
----
-apiVersion: database.azure.crossplane.io/v1beta1
-kind: PostgreSQLServer
-metadata:
- name: sqlserverpostgresql
-spec:
- forProvider:
- administratorLogin: myadmin
- resourceGroupNameRef:
- name: sqlserverpostgresql-rg
- location: West US 2
- sslEnforcement: Disabled
- version: "9.6"
- sku:
- tier: GeneralPurpose
- capacity: 2
- family: Gen5
- storageProfile:
- storageMB: 20480
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: sqlserverpostgresql-conn
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/provision/azure.yaml
-```
-
-Creating the above instance will cause Crossplane to provision a PostgreSQL
-database instance on Azure. You can view the progress with the following
-command:
-
-```console
-kubectl get postgresqlserver sqlserverpostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can take a look at its connection secret that is referenced under `spec.writeConnectionSecretToRef`:
-
-```console
-kubectl describe secret sqlserverpostgresql-conn -n crossplane-system
-```
-
-You can then delete the `PostgreSQLServer`:
-
-```console
-kubectl delete postgresqlserver sqlserverpostgresql
-kubectl delete resourcegroup sqlserverpostgresql-rg
-```
-
-
-
-
-The Alibaba provider supports provisioning an [ApsaraDB for RDS] instance with
-the `RDSInstance` managed resource it adds to Crossplane.
-
-```yaml
-apiVersion: database.alibaba.crossplane.io/v1alpha1
-kind: RDSInstance
-metadata:
- name: rdspostgresql
-spec:
- forProvider:
- engine: PostgreSQL
- engineVersion: "9.4"
- dbInstanceClass: rds.pg.s1.small
- dbInstanceStorageInGB: 20
- securityIPList: "0.0.0.0/0"
- masterUsername: "test123"
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: alibaba-rdspostgresql-conn
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/provision/alibaba.yaml
-```
-
-Creating the above instance will cause Crossplane to provision an RDS instance
-on Alibaba. You can view the progress with the following command:
-
-```console
-kubectl get rdsinstance rdspostgresql
-```
-
-When provisioning is complete, you should see `READY: True` in the output. You
-can take a look at its connection secret that is referenced under `spec.writeConnectionSecretToRef`:
-
-```console
-kubectl describe secret alibaba-rdspostgresql-conn -n crossplane-system
-```
-
-You can then delete the `RDSInstance`:
-
-```console
-kubectl delete rdsinstance rdspostgresql
-```
-
-
-
-
-## Next Steps
-
-Now that you have seen how to provision individual managed resources, let's take
-a look at how we can compose several managed resources into new resources with
-APIs of our choosing in the [next section].
-
-
-
-[installed a provider]: install-configure.md
-[configured your credentials]: install-configure.md
-[RDS]: https://aws.amazon.com/rds/
-[CloudSQL]: https://cloud.google.com/sql
-[Azure Database for PostgreSQL]: https://azure.microsoft.com/en-us/services/postgresql/
-[Resource Group]: https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal#what-is-a-resource-group
-[ApsaraDB for RDS]: https://www.alibabacloud.com/product/apsaradb-for-rds-postgresql
-[next section]: compose-infrastructure.md
diff --git a/docs/v0.14/getting-started/run-applications-dash.png b/docs/v0.14/getting-started/run-applications-dash.png
deleted file mode 100644
index 5390190b..00000000
Binary files a/docs/v0.14/getting-started/run-applications-dash.png and /dev/null differ
diff --git a/docs/v0.14/getting-started/run-applications-diagram.jpg b/docs/v0.14/getting-started/run-applications-diagram.jpg
deleted file mode 100644
index 16037640..00000000
Binary files a/docs/v0.14/getting-started/run-applications-diagram.jpg and /dev/null differ
diff --git a/docs/v0.14/getting-started/run-applications-flights.png b/docs/v0.14/getting-started/run-applications-flights.png
deleted file mode 100644
index c7d3b8d0..00000000
Binary files a/docs/v0.14/getting-started/run-applications-flights.png and /dev/null differ
diff --git a/docs/v0.14/getting-started/run-applications.md b/docs/v0.14/getting-started/run-applications.md
deleted file mode 100644
index 5736be45..00000000
--- a/docs/v0.14/getting-started/run-applications.md
+++ /dev/null
@@ -1,482 +0,0 @@
----
-title: Run Applications
-toc: true
-weight: 5
-indent: true
----
-
-# Run Applications
-
-Crossplane strives to be the best Kubernetes add-on to provision and manage the
-infrastructure and services your applications need directly from kubectl. A huge
-part of this mission is arriving at an elegant, flexible way to model and manage
-cloud native applications. Crossplane allows your team to deploy and run
-applications using the [Open Application Model] (OAM).
-
-OAM is a team-centric model for cloud native apps. Like Crossplane, OAM focuses
-on the different people who might be involved in the deployment of a cloud
-native application. In this getting started guide:
-
-* _Infrastructure Operators_ provide the infrastructure applications need.
-* _Application Developers_ build and supply the components of an application.
-* _Application Operators_ compose, deploy, and run application configurations.
-
-We'll play the roles of each of these team members as we deploy an application -
-Service Tracker - that consists of several services. One of these services, the
-`data-api`, is backed by a managed PostgreSQL database that is provisioned
-on-demand by Crossplane.
-
-![Service Tracker Diagram]
-
-> This guide follows on from the previous one in which we covered defining,
-> [composing], and offering infrastructure. You'll need to have defined and
-> offered a PostgreSQLInstance with at least one working Composition in order
-> to create the OAM application we'll use in this guide.
-
-## Infrastructure Operator
-
-### Install workloads and traits
-
-As the infrastructure operator our work is almost done - we defined, published,
-and composed the infrastructure that our application developer and operator
-teammates will use in the previous guide. One task remains, which is to define
-the [_workloads_] and [_traits_] that our platform supports.
-
-OAM applications consist of workloads, each of which may be modified by traits.
-The infrastructure operator may choose which workloads and traits by creating
-or deleting `WorkloadDefinitions` and `TraitDefinitions` like below:
-
-```yaml
----
-apiVersion: core.oam.dev/v1alpha2
-kind: WorkloadDefinition
-metadata:
- name: postgresqlinstances.database.example.org
-spec:
- definitionRef:
- name: postgresqlinstances.database.example.org
----
-# The OAM controller needs RBAC access to reconcile any non-core workloads.
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- labels:
- rbac.oam.dev/aggregate-to-controller: "true"
- name: oam:claim:postgresqlinstancesdatabase.example.org:aggregate-to-controller
-rules:
-- apiGroups:
- - database.example.org
- resources:
- - postgresqlinstances
- verbs:
- - '*'
-```
-
-Run the following command to add support for all the workloads and traits required
-by this guide:
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/run/definitions.yaml
-```
-
-## Application Developer
-
-### Publish Application Components
-
-Now we'll play the role of the application developer. Our Service Tracker
-application consists of a UI service, four API services, and a PostgreSQL
-database. Under the Open Application Model application developers define
-[_components_] that application operators may compose into applications, which
-produce workloads. Creating components allows us as application developers to
-communicate any fundamental, suggested, or optional properties of our services
-and their infrastructure claims.
-
-```yaml
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: data-api-database
-spec:
- workload:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstance
- metadata:
- name: app-postgresql
- spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- guide: quickstart
- parameters:
- - name: database-secret
- description: Secret to which to write PostgreSQL database connection details.
- required: true
- fieldPaths:
- - spec.writeConnectionSecretToRef.name
- - name: database-provider
- description: |
- Cloud provider that should be used to create a PostgreSQL database.
- Either alibaba, aws, azure, or gcp.
- fieldPaths:
- - spec.compositionSelector.matchLabels.provider
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: data-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: data-api
- spec:
- containers:
- - name: data-api
- image: artursouza/rudr-data-api:0.50
- env:
- - name: DATABASE_USER
- fromSecret:
- key: username
- - name: DATABASE_PASSWORD
- fromSecret:
- key: password
- - name: DATABASE_HOSTNAME
- fromSecret:
- key: endpoint
- - name: DATABASE_PORT
- fromSecret:
- key: port
- - name: DATABASE_NAME
- value: postgres
- - name: DATABASE_DRIVER
- value: postgresql
- ports:
- - name: http
- containerPort: 3009
- protocol: TCP
- livenessProbe:
- exec:
- command: [wget, -q, http://127.0.0.1:3009/status, -O, /dev/null, -S]
- parameters:
- - name: database-secret
- description: Secret from which to read PostgreSQL connection details.
- required: true
- fieldPaths:
- - spec.containers[0].env[0].fromSecret.name
- - spec.containers[0].env[1].fromSecret.name
- - spec.containers[0].env[2].fromSecret.name
- - spec.containers[0].env[3].fromSecret.name
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: flights-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: flights-api
- spec:
- containers:
- - name: flights-api
- image: sonofjorel/rudr-flights-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3003
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: quakes-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: quakes-api
- spec:
- containers:
- - name: quakes-api
- image: sonofjorel/rudr-quakes-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3012
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: service-tracker-ui
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: web-ui
- spec:
- containers:
- - name: service-tracker-ui
- image: sonofjorel/rudr-web-ui:0.49
- env:
- - name: FLIGHT_API_ROOT
- - name: WEATHER_API_ROOT
- - name: QUAKES_API_ROOT
- ports:
- - name: http
- containerPort: 8080
- protocol: TCP
- parameters:
- - name: flights-uri
- description: URI at which the flights service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
- - name: weather-uri
- description: URI at which the weather service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[1].value
- - name: quakes-uri
- description: URI at which the quakes service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[2].value
----
-apiVersion: core.oam.dev/v1alpha2
-kind: Component
-metadata:
- name: weather-api
-spec:
- workload:
- apiVersion: core.oam.dev/v1alpha2
- kind: ContainerizedWorkload
- metadata:
- name: weather-api
- spec:
- containers:
- - name: weather-api
- image: sonofjorel/rudr-weather-api:0.49
- env:
- - name: DATA_SERVICE_URI
- ports:
- - name: http
- containerPort: 3015
- protocol: TCP
- parameters:
- - name: data-uri
- description: URI at which the data service is serving
- required: true
- fieldPaths:
- - spec.containers[0].env[0].value
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/run/components.yaml
-```
-
-Each of the above components describes a particular kind of workload. The
-Service Tracker application consists of two kinds of workload:
-
-* A [`ContainerizedWorkload`] is a long-running containerized process.
-* A `PostgreSQLInstance` is a PostgreSQL instance and database.
-
-All OAM components configure a kind of workload, and any kind of Kubernetes
-resource may act as an OAM workload as long as an infrastructure operator has
-allowed it to by authoring a `WorkloadDefinition`.
-
-## Application Operator
-
-### Run The Application
-
-Finally, we'll play the role of an application operator and tie together the
-application components and infrastructure that our application developer and
-infrastructure operator team-mates have published. In OAM this is done by
-authoring an [_application configuration_]:
-
-```yaml
-apiVersion: core.oam.dev/v1alpha2
-kind: ApplicationConfiguration
-metadata:
- name: service-tracker
-spec:
- components:
- - componentName: data-api-database
- parameterValues:
- - name: database-secret
- value: tracker-database-secret
- - componentName: data-api
- parameterValues:
- - name: database-secret
- value: tracker-database-secret
- - componentName: flights-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: flights-api
- spec:
- replicaCount: 2
- - componentName: quakes-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: quakes-api
- spec:
- replicaCount: 2
- - componentName: weather-api
- parameterValues:
- - name: data-uri
- value: "http://data-api.default.svc.cluster.local:3009/"
- traits:
- - trait:
- apiVersion: core.oam.dev/v1alpha2
- kind: ManualScalerTrait
- metadata:
- name: weather-api
- spec:
- replicaCount: 2
- - componentName: service-tracker-ui
- parameterValues:
- - name: flights-uri
- value: "http://flights-api.default.svc.cluster.local:3003/"
- - name: weather-uri
- value: "http://weather-api.default.svc.cluster.local:3015/"
- - name: quakes-uri
- value: "http://quakes-api.default.svc.cluster.local:3012/"
-```
-
-```console
-kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/run/appconfig.yaml
-```
-
-This application configuration names each of components the application
-developer created earlier to produce workloads. The application operator may (or
-in some cases _must_) provide parameter values for a component in order to
-override or specify certain configuration values. Component parameters represent
-configuration settings that the component author - the application developer -
-deemed to be of interest to application operators.
-
-```yaml
-- componentName: data-api-database
- parameterValues:
- - name: database-provider
- value: azure
-```
-
-> If you created Compositions for more than one provider in the previous guide
-> you can add the above parameter to the `data-api-database` component to choose
-> which cloud provider the Service Tracker's database should run on.
-
-You might notice that some components include a [`ManualScalerTrait`]. Traits
-augment the workload produced by a component with additional features, allowing
-application operators to make decisions about the configuration of a component
-without having to involve the developer. The `ManualScalerTrait` allows an
-application operator to specify how many replicas should exist of any scalable
-kind of workload.
-
-> Note that the OAM spec also includes the concept of an _application scope_.
-> Crossplane does not yet support scopes.
-
-## Use The Application
-
-Finally, we'll open and use the Service Tracker application we just deployed.
-
-
-
-If you deployed Service Tracker to a managed cluster like AKS, ACK, EKS, or GKE
-with support for load balancer Services you should be able to browse to the IP
-of the `web-ui` service on port 8080 - for example .
-
-```console
-kubectl get svc web-ui -o=jsonpath={.status.loadBalancer.ingress[0].ip}
-```
-
-
-
-
-If you're using a cluster that doesn't support load balancer Services, like Kind
-or Minikube you can use a port forward instead, and connect to
-
-
-```console
-kubectl port-forward deployment/web-ui 8080
-```
-
-
-
-
-You should see the Service Tracker dashboard in your browser. Hit 'Refresh Data'
-for each of the services to ensure the Service Tracker web UI can connect to its
-various data API services and populate its PostgreSQL database:
-
-![Service Tracker Dashboard]
-
-If everything was successful you should be able to browse to Flights,
-Earthquakes, or Weather to see what's going on in the world today:
-
-![Service Tracker Flights]
-
-## Clean Up
-
-To shut down your application, simply run:
-
-```console
-kubectl delete applicationconfiguration service-tracker
-```
-
-If you also wish to delete the components, workload definitions, and trait
-definitions we created in this guide, run:
-
-```console
-kubectl delete -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/run/components.yaml
-kubectl delete -f https://raw.githubusercontent.com/crossplane/crossplane/release-0.14/docs/snippets/run/definitions.yaml
-```
-
-[Open Application Model]: https://oam.dev/
-[composing]: compose-infrastructure.md
-[Service Tracker Diagram]: run-applications-diagram.jpg
-[_workloads_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/3.workload.md
-[_traits_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/6.traits.md
-[_components_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/4.component.md
-[_application configuration_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/7.application_configuration.md
-[`ContainerizedWorkload`]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/core/workloads/containerized_workload/containerized_workload.md
-[`ManualScalerTrait`]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/core/traits/manual_scaler_trait.md
-[_application scope_]: https://github.com/oam-dev/spec/blob/1.0.0-alpha2/5.application_scopes.md
-[Service Tracker Dashboard]: run-applications-dash.png
-[Service Tracker Flights]: run-applications-flights.png
diff --git a/docs/v0.14/guides/argocd.md b/docs/v0.14/guides/argocd.md
deleted file mode 100644
index 7ff668fe..00000000
--- a/docs/v0.14/guides/argocd.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Argo CD
-toc: true
-weight: 201
-indent: true
-redirect_to: https://aws.amazon.com/blogs/opensource/connecting-aws-managed-services-to-your-argo-cd-pipeline-with-open-source-crossplane/
----
diff --git a/docs/v0.14/guides/guides.md b/docs/v0.14/guides/guides.md
deleted file mode 100644
index 2dbb6064..00000000
--- a/docs/v0.14/guides/guides.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: Guides
-toc: true
-weight: 200
----
-
-# Guides
-
-Because of Crossplane's standardization on the Kubernetes API, it integrates
-well with many other projects. Below is a collection of guides and tutorials that
-demonstrate how to use Crossplane with a variety tools and projects often used
-with Kubernetes plus some deep dive content on Crossplane itself!
-
-- [Argo CD] - use GitOps to provision managed services with Crossplane and Argo CD.
-- [Knative] - use managed services provisioned by Crossplane in your Knative services.
-- [Okteto] - use managed services in your Okteto development workflow.
-- [Open Policy Agent] - set global policy on provisioning cloud resources with Crossplane and OPA.
-- [OpenFaaS] - consume managed services with for your serverless functions.
-- [Provider Internals] - translate provider APIs into managed resource CRDs and explore managed resource API patterns & best practices.
-- [Velero] - backup and restore your Crossplane infrastructure resources.
-
-
-
-[Velero]: https://www.youtube.com/watch?v=eV_2QoMRqGw&list=PL510POnNVaaYFuK-B_SIUrpIonCtLVOzT&index=18&t=183s
-[Argo CD]: https://aws.amazon.com/blogs/opensource/connecting-aws-managed-services-to-your-argo-cd-pipeline-with-open-source-crossplane/
-[Open Policy Agent]: https://github.com/crossplane/tbs/tree/master/episodes/14
-[Knative]: https://github.com/crossplane/tbs/tree/master/episodes/15
-[OpenFaaS]: https://github.com/crossplane/tbs/tree/master/episodes/13
-[Okteto]: https://github.com/crossplane/tbs/tree/master/episodes/10
-[Provider Internals]: https://github.com/crossplane/tbs/tree/master/episodes/7
diff --git a/docs/v0.14/guides/knative.md b/docs/v0.14/guides/knative.md
deleted file mode 100644
index ddb0953b..00000000
--- a/docs/v0.14/guides/knative.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Knative
-toc: true
-weight: 202
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/15
----
diff --git a/docs/v0.14/guides/okteto.md b/docs/v0.14/guides/okteto.md
deleted file mode 100644
index 3cede639..00000000
--- a/docs/v0.14/guides/okteto.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Okteto
-toc: true
-weight: 203
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/10
----
diff --git a/docs/v0.14/guides/opa.md b/docs/v0.14/guides/opa.md
deleted file mode 100644
index 9e0abc8d..00000000
--- a/docs/v0.14/guides/opa.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Open Policy Agent
-toc: true
-weight: 204
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/14
----
diff --git a/docs/v0.14/guides/openfaas.md b/docs/v0.14/guides/openfaas.md
deleted file mode 100644
index d7c3bcac..00000000
--- a/docs/v0.14/guides/openfaas.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: OpenFaaS
-toc: true
-weight: 205
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/13
----
diff --git a/docs/v0.14/guides/provider-internals.md b/docs/v0.14/guides/provider-internals.md
deleted file mode 100644
index bc178a17..00000000
--- a/docs/v0.14/guides/provider-internals.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Provider Internals
-toc: true
-weight: 206
-indent: true
-redirect_to: https://github.com/crossplane/tbs/tree/master/episodes/7
----
diff --git a/docs/v0.14/guides/upgrading-to-v0.14.md b/docs/v0.14/guides/upgrading-to-v0.14.md
deleted file mode 100644
index 5c62c487..00000000
--- a/docs/v0.14/guides/upgrading-to-v0.14.md
+++ /dev/null
@@ -1,166 +0,0 @@
----
-title: Upgrading to v0.14
-toc: true
-weight: 210
-indent: true
----
-
-# Upgrading to v0.14
-
-Crossplane made a small handful of breaking changes in v0.14. The most broadly
-impactful change was updating the `CompositeResourceDefinition` (XRD) schema to
-support defining multiple versions of a composite resource (XR) at once. This
-guide covers how to upgrade from v0.13 of Crossplane to v0.14.
-
-- [Updating CompositeResourceDefinitions](#updating-compositeresourcedefinitions)
-- [Updating Packages](#updating-packages)
-
-## Updating CompositeResourceDefinitions
-
-In v0.14 the schema of XRD was updated to support defining multiple versions of
-an XR. This update requires manual update steps. To upgrade from v0.13 to v0.14
-you must:
-
-1. Ensure you have up-to-date YAML representations of all of your XRDs.
-1. `helm upgrade` your Crossplane release.
-1. Update and apply all of your XRDs.
-
-Note that Crossplane will not actively reconcile your XRs between steps 2 and 3,
-and you will see some errors in the events and logs, but your managed resources
-(and thus infrastructure) will continue to run. Follow the below steps in order
-to update your XRDs for v0.14:
-
-1. Rename `spec.crdSpecTemplate` to `spec.versions`.
-1. Move `spec.versions.group` to `spec.group`.
-1. Move `spec.versions.names` to `spec.names`.
-1. Rename `spec.versions.version` to `spec.versions.name`
-1. Rename `spec.versions.validation` (if set) to `spec.versions.schema`.
-1. Rename `spec.versions.additionalPrinterColumns[].JSONPath` (if set) to
- `spec.versions.additionalPrinterColumns[].jsonPath`.
-1. Set `spec.versions.served` to `true`.
-1. Set `spec.versions.referenceable` to `true`.
-1. Make `spec.versions` a single element array.
-
-For example, the below XRD:
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: CompositeResourceDefinition
-metadata:
- name: compositepostgresqlinstances.database.example.org
-spec:
- claimNames:
- kind: PostgreSQLInstance
- plural: postgresqlinstances
- connectionSecretKeys:
- - username
- - password
- - endpoint
- - port
- crdSpecTemplate:
- group: database.example.org
- version: v1alpha1
- names:
- kind: CompositePostgreSQLInstance
- plural: compositepostgresqlinstances
- validation:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- parameters:
- type: object
- properties:
- storageGB:
- type: integer
- required:
- - storageGB
- required:
- - parameters
-```
-
-Would become:
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1alpha1
-kind: CompositeResourceDefinition
-metadata:
- name: compositepostgresqlinstances.database.example.org
-spec:
- group: database.example.org
- names:
- kind: CompositePostgreSQLInstance
- plural: compositepostgresqlinstances
- claimNames:
- kind: PostgreSQLInstance
- plural: postgresqlinstances
- connectionSecretKeys:
- - username
- - password
- - endpoint
- - port
- versions:
- - name: v1alpha1
- served: true
- referenceable: true
- schema:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- parameters:
- type: object
- properties:
- storageGB:
- type: integer
- required:
- - storageGB
- required:
- - parameters
-```
-
-## Updating Packages
-
-A minor breaking change was made to on-disk package types
-(`meta.pkg.crossplane.io`). In v0.13, the `spec.crossplane` field was present to
-specify a compatible Crossplane version range, but it was not honored by the
-package manager when packages were installed. The field was refactored to
-`spec.crossplane.version` meaning that packages that previously specified
-`spec.crossplane` will fail to parse when building with the Crossplane CLI or
-installing into a Crossplane Kubernetes cluster. If `spec.crossplane` was not
-specified, packages compatible with Crossplane v0.13 will continue to be
-compatible in v0.14. This is true for both `Provider` and `Configuration`
-packages.
-
-The following example shows how a `Configuration` package that specified
-`spec.crossplane` can be updated to specify Crossplane version constraints that
-will be honored by the package manager in v0.14:
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: my-configuration
-spec:
- crossplane: ">=v0.13.0"
-```
-
-Would become:
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: my-configuration
-spec:
- crossplane:
- version: ">=v0.13.0"
-```
-
-Please note that while `spec.dependsOn` is also a valid field in on-disk package
-types, it is not yet honored by the package manager and will be ignored at
-installation time.
diff --git a/docs/v0.14/guides/velero.md b/docs/v0.14/guides/velero.md
deleted file mode 100644
index ebec433a..00000000
--- a/docs/v0.14/guides/velero.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Velero
-toc: true
-weight: 207
-indent: true
-redirect_to: https://www.youtube.com/watch?v=eV_2QoMRqGw&list=PL510POnNVaaYFuK-B_SIUrpIonCtLVOzT&index=18&t=183s
----
diff --git a/docs/v0.14/introduction/composition-concepts.png b/docs/v0.14/introduction/composition-concepts.png
deleted file mode 100644
index 75327226..00000000
Binary files a/docs/v0.14/introduction/composition-concepts.png and /dev/null differ
diff --git a/docs/v0.14/introduction/composition-provisioning.png b/docs/v0.14/introduction/composition-provisioning.png
deleted file mode 100644
index a07aac66..00000000
Binary files a/docs/v0.14/introduction/composition-provisioning.png and /dev/null differ
diff --git a/docs/v0.14/introduction/composition.md b/docs/v0.14/introduction/composition.md
deleted file mode 100644
index 80ea4840..00000000
--- a/docs/v0.14/introduction/composition.md
+++ /dev/null
@@ -1,803 +0,0 @@
----
-title: Composing Infrastructure
-toc: true
-weight: 103
-indent: true
----
-
-# Composing Infrastructure
-
-Crossplane allows infrastructure operators to define and compose new kinds of
-infrastructure resources then offer them for the application operators they
-support to use, all without writing any code.
-
-Infrastructure providers extend Crossplane, enabling it to manage a wide array
-of infrastructure resources like Azure SQL servers and AWS ElastiCache clusters.
-Infrastructure composition allows infrastructure operators to define, share, and
-reuse new kinds of infrastructure resources that are _composed_ of these
-infrastructure resources. Infrastructure operators may configure one or more
-compositions of any defined resource, and may publish any defined resource to
-their application operators, who may then declare that their application
-requires that kind of resource.
-
-Composition can be used to build a catalogue of kinds and configuration classes
-of infrastructure that fit the needs and opinions of your organisation. As an
-infrastructure operator you might define your own `MySQLInstance` resource. This
-resource would allow your application operators to configure only the settings
-that _your_ organisation needs - perhaps engine version and storage size. All
-other settings are deferred to a selectable composition representing a
-configuration class like "production" or "staging". Compositions can hide
-infrastructure complexity and include policy guardrails so that applications can
-easily and safely consume the infrastructure they need, while conforming to your
-organisational best-practices.
-
-> Note that composition is an **alpha** feature of Crossplane. Refer to [Current
-> Limitations] for information on functionality that is planned but not yet
-> implemented.
-
-## Concepts
-
-![Infrastructure Composition Concepts]
-
-A _Composite Resource_ (XR) is a special kind of custom resource that is
-composed of other resources. Its schema is user-defined. The
-`CompositeMySQLInstance` in the above diagram is a composite resource. The kind
-of a composite resource is configurable - the `Composite` prefix is not
-required.
-
-A `Composition` specifies how Crossplane should reconcile a composite
-infrastructure resource - i.e. what infrastructure resources it should compose.
-For example the Azure `Composition` configures Crossplane to reconcile a
-`CompositeMySQLInstance` by creating and managing the lifecycle of an Azure
-`MySQLServer` and `MySQLServerFirewallRule`.
-
-A _Composite Resource Claim_ (XRC) for an resource declares that an application
-requires particular kind of infrastructure, as well as specifying how to
-configure it. The `MySQLInstance` resources in the above diagram declare that
-the application pods each require a `CompositeMySQLInstance`. As with composite
-resources, the kind of the claim is configurable. Offering a claim is optional.
-
-A `CompositeResourceDefinition` (XRD) defines a new kind of composite resource,
-and optionally the claim it offers. The `CompositeResourceDefinition` in the
-above diagram defines the `CompositeMySQLInstance` composite resource, and its
-corresponding `MySQLInstance` claim.
-
-> Note that composite resources and compositions are _cluster scoped_ - they
-> exist outside of any Kubernetes namespace. A claim is a namespaced proxy for a
-> composite resource. This enables an RBAC model under which application
-> operators may only interact with infrastructure via resource claims.
-
-## Defining Infrastructure
-
-New kinds of infrastructure resource are defined by an infrastructure operator.
-There are three steps to this process:
-
-1. Define your composite resource, and optionally the claim it offers.
-1. Specify one or more possible ways your composite resource may be composed.
-
-### Define your Composite Resource
-
-Composite resources are defined by a `CompositeResourceDefinition`:
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1beta1
-kind: CompositeResourceDefinition
-metadata:
- # XRDs follow the constraints of CRD names. They must be named
- # ., per the plural and group names configured by the
- # crdSpecTemplate below.
- name: compositemysqlinstances.example.org
-spec:
- # Composite resources may optionally expose a connection secret - a Kubernetes
- # Secret containing all of the details a pod might need to connect to the
- # resource. Resources that wish to expose a connection secret must declare
- # what keys they support. These keys form a 'contract' - any composition that
- # intends to be compatible with this resource must compose resources that
- # supply these connection secret keys.
- connectionSecretKeys:
- - username
- - password
- - hostname
- - port
- # You can specify a default Composition resource to be selected if there is
- # no composition selector or reference was supplied on the Custom Resource.
- defaultCompositionRef:
- name: example-azure
- # An enforced composition will be selected for all instances of this type and
- # will override any selectors and references.
- #enforcedCompositionRef:
- # name: securemysql.acme.org
- group: example.org
- # The defined kind of composite resource.
- names:
- kind: CompositeMySQLInstance
- plural: compositemysqlinstances
- # The kind of claim this composite resource offers. Optional - omit the claim
- # names if you don't wish to offer a claim for this composite resource. Must
- # be different from the composite resource's kind. The established convention
- # is for the claim kind to represent what the resource is, conceptually. e.g.
- # 'MySQLInstance', not `MySQLInstanceClaim`.
- claimNames:
- kind: MySQLInstance
- plural: mysqlinstances
- # A composite resource may be served at multiple versions simultaneously, but
- # all versions must have identical schemas; Crossplane does not yet support
- # conversion between different version schemas.
- versions:
- - name: v1alpha1
- # Served specifies whether this version should be exposed via the API
- # server's REST API.
- served: true
- # Referenceable specifies whether this version may be referenced by a
- # Composition. Exactly one version may be referenceable by Compositions, and
- # that version must be served. The referenceable version will always be the
- # storage version of the underlying CRD.
- referenceable: true
- # This schema defines the configuration fields that the composite resource
- # supports. It uses the same structural OpenAPI schema as a Kubernetes CRD
- # - for example, this resource supports a spec.parameters.version enum.
- # The following fields are reserved for Crossplane's use, and will be
- # overwritten if included in this validation schema:
- #
- # - spec.resourceRef
- # - spec.resourceRefs
- # - spec.claimRef
- # - spec.writeConnectionSecretToRef
- # - status.conditions
- schema:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- parameters:
- type: object
- properties:
- version:
- description: MySQL engine version
- type: string
- enum: ["5.6", "5.7"]
- storageGB:
- type: integer
- location:
- description: Geographic location of this MySQL server.
- type: string
- required:
- - version
- - storageGB
- - location
- required:
- - parameters
-```
-
-Refer to the Kubernetes documentation on [structural schemas] for full details
-on how to configure the `openAPIV3Schema` for your composite resource.
-
-`kubectl describe` can be used to confirm that a new composite
-resource was successfully defined. Note the `Established` condition and events,
-which indicate the process was successful.
-
-```console
-$ kubectl describe xrd compositemysqlinstances.example.org
-
-Name: compositemysqlinstances.example.org
-Namespace:
-Labels:
-Annotations: API Version: apiextensions.crossplane.io/v1beta1
-Kind: CompositeResourceDefinition
-Metadata:
- Creation Timestamp: 2020-05-15T05:30:44Z
- Generation: 1
- Resource Version: 1418120
- Self Link: /apis/apiextensions.crossplane.io/v1beta1/compositeresourcedefinitions/compositemysqlinstances.example.org
- UID: f8fedfaf-4dfd-4b8a-8228-6af0f4abd7a0
-Spec:
- Connection Secret Keys:
- username
- password
- hostname
- port
- Default Composition Ref:
- Name: example-azure
- Group: example.org
- Names:
- Kind: CompositeMySQLInstance
- List Kind: CompositeMySQLInstanceList
- Plural: compositemysqlinstances
- Singular: compositemysqlinstance
- Claim Names:
- Kind: MySQLInstance
- List Kind: MySQLInstanceList
- Plural: mysqlinstances
- Singular: mysqlinstance
- Versions:
- Name: v1alpha1
- Served: true
- Referenceable: true
- Schema:
- openAPIV3Schema:
- Properties:
- Spec:
- Parameters:
- Properties:
- Location:
- Description: Geographic location of this MySQL server.
- Type: string
- Storage GB:
- Type: integer
- Version:
- Description: MySQL engine version
- Enum:
- 5.6
- 5.7
- Type: string
- Required:
- version
- storageGB
- location
- Type: object
- Required:
- parameters
- Type: object
- Type: object
- Version: v1alpha1
-Status:
- Conditions:
- Last Transition Time: 2020-05-15T05:30:45Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
- Last Transition Time: 2020-05-15T05:30:45Z
- Reason: Created CRD and started controller
- Status: True
- Type: Established
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal ApplyCompositeResourceDefinition 4m10s apiextension/compositeresourcedefinition.apiextensions.crossplane.io waiting for CustomResourceDefinition to be established
- Normal RenderCustomResourceDefinition 55s (x8 over 4m10s) apiextension/compositeresourcedefinition.apiextensions.crossplane.io Rendered CustomResourceDefinition
- Normal ApplyCompositeResourceDefinition 55s (x7 over 4m9s) apiextension/compositeresourcedefinition.apiextensions.crossplane.io Applied CustomResourceDefinition and (re)started composite controller
-```
-
-### Specify How Your Resource May Be Composed
-
-Once a new kind of composite resource is defined Crossplane must be instructed
-how to reconcile that kind of resource. This is done by authoring a
-`Composition`.
-
-A `Composition`:
-
-* Declares one kind of composite resource that it satisfies.
-* Specifies a "base" configuration for one or more composed resources.
-* Specifies "patches" that overlay configuration values from an instance of the
- composite resource onto each "base".
-
-Multiple compositions may satisfy a particular kind of composite resource, and
-the author of a composite resource (or resource claim) may select which
-composition will be used. This allows an infrastructure operator to offer their
-application operators a choice between multiple opinionated classes of
-infrastructure, allowing them to explicitly specify only some configuration. An
-infrastructure operator may offer their application operators the choice between
-an "Azure" and a "GCP" composition when creating a `MySQLInstance` for example,
-Or they may offer a choice between a "production" and a "staging" composition.
-They can also offer a default composition in case application operators do not
-supply a composition selector or enforce a specific composition in order to
-override the composition choice of users for all instances. In all cases, the
-application operator may configure any value supported by the composite
-resource's schema, with all other values being deferred to the composition.
-
-The below `Composition` satisfies the `CompositeMySQLInstance` defined in the
-previous section by composing an Azure SQL server, firewall rule, and resource
-group:
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1beta1
-kind: Composition
-metadata:
- name: example-azure
- labels:
- purpose: example
- provider: azure
-spec:
- # This Composition declares that it satisfies the CompositeMySQLInstance
- # resource defined above - i.e. it patches "from" a CompositeMySQLInstance.
- # Note that the version in apiVersion must be the referenceable version of the
- # XRD.
- compositeTypeRef:
- apiVersion: example.org/v1alpha1
- kind: CompositeMySQLInstance
- # This Composition reconciles a CompositeMySQLInstance by patching from
- # the CompositeMySQLInstance "to" new instances of the infrastructure
- # resources below. These resources may be the managed resources of an
- # infrastructure provider such as provider-azure, or other composite
- # resources.
- resources:
- # A CompositeMySQLInstance that uses this Composition will be composed of an
- # Azure ResourceGroup. The "base" for this ResourceGroup specifies the base
- # configuration that may be extended or mutated by the patches below.
- - base:
- apiVersion: azure.crossplane.io/v1alpha3
- kind: ResourceGroup
- spec: {}
- # Patches copy or "overlay" the value of a field path within the composite
- # resource (the CompositeMySQLInstance) to a field path within the composed
- # resource (the ResourceGroup). In the below example any labels and
- # annotations will be propagated from the CompositeMySQLInstance to the
- # ResourceGroup, as will the location.
- patches:
- - fromFieldPath: "metadata.labels"
- toFieldPath: "metadata.labels"
- - fromFieldPath: "metadata.annotations"
- toFieldPath: "metadata.annotations"
- - fromFieldPath: "spec.parameters.location"
- toFieldPath: "spec.location"
- # Sometimes it is necessary to "transform" the value from the composite
- # resource into a value suitable for the composed resource, for example an
- # Azure based composition may represent geographical locations differently
- # from a GCP based composition that satisfies the same composite resource.
- # This can be done by providing an optional array of transforms, such as
- # the below that will transform the MySQLInstance spec.parameters.location
- # value "us-west" into the ResourceGroup spec.location value "West US".
- transforms:
- - type: map
- map:
- us-west: West US
- us-east: East US
- au-east: Australia East
- # A MySQLInstance that uses this Composition will also be composed of an
- # Azure MySQLServer.
- - base:
- apiVersion: database.azure.crossplane.io/v1beta1
- kind: MySQLServer
- spec:
- forProvider:
- # When this MySQLServer is created it must specify a ResourceGroup in
- # which it will exist. The below resourceGroupNameSelector corresponds
- # to the spec.forProvider.resourceGroupName field of the MySQLServer.
- # It selects a ResourceGroup with a matching controller reference.
- # Two resources that are part of the same composite resource will have
- # matching controller references, so this MySQLServer will always
- # select the ResourceGroup above. If this Composition included more
- # than one ResourceGroup they could be differentiated by matchLabels.
- resourceGroupNameSelector:
- matchControllerRef: true
- administratorLogin: notadmin
- sslEnforcement: Disabled
- sku:
- tier: GeneralPurpose
- capacity: 8
- family: Gen5
- storageProfile:
- backupRetentionDays: 7
- geoRedundantBackup: Disabled
- writeConnectionSecretToRef:
- namespace: crossplane-system
- patches:
- - fromFieldPath: "metadata.labels"
- toFieldPath: "metadata.labels"
- - fromFieldPath: "metadata.annotations"
- toFieldPath: "metadata.annotations"
- - fromFieldPath: "metadata.uid"
- toFieldPath: "spec.writeConnectionSecretToRef.name"
- transforms:
- # Transform the value from the CompositeMySQLInstance using Go string
- # formatting. This can be used to prefix or suffix a string, or to
- # convert a number to a string. See https://golang.org/pkg/fmt/ for more
- # detail.
- - type: string
- string:
- fmt: "%s-mysqlserver"
- - fromFieldPath: "spec.parameters.version"
- toFieldPath: "spec.forProvider.version"
- - fromFieldPath: "spec.parameters.location"
- toFieldPath: "spec.forProvider.location"
- transforms:
- - type: map
- map:
- us-west: West US
- us-east: East US
- au-east: Australia East
- - fromFieldPath: "spec.parameters.storageGB"
- toFieldPath: "spec.forProvider.storageProfile.storageMB"
- # Transform the value from the CompositeMySQLInstance by multiplying it by
- # 1024 to convert Gigabytes to Megabytes.
- transforms:
- - type: math
- math:
- multiply: 1024
- # In addition to a base and patches, this composed MySQLServer declares that
- # it can fulfil the connectionSecretKeys contract required by the definition
- # of the CompositeMySQLInstance. This MySQLServer writes a connection secret
- # with a username, password, and endpoint that may be used to connect to it.
- # These connection details will also be exposed via the composite resource's
- # connection secret. Exactly one composed resource must provide each secret
- # key, but different composed resources may provide different keys.
- connectionDetails:
- - fromConnectionSecretKey: username
- - fromConnectionSecretKey: password
- # The name of the required CompositeMySQLInstance connection secret key
- # can be supplied if it is different from the connection secret key
- # exposed by the MySQLServer.
- - name: hostname
- fromConnectionSecretKey: endpoint
- # In some cases it may be desirable to inject a fixed connection secret
- # value, for example to expose fixed, non-sensitive connection details
- # like standard ports that are not published to the composed resource's
- # connection secret.
- - name: port
- value: "3306"
- # A CompositeMySQLInstance that uses this Composition will also be composed
- # of an Azure MySQLServerFirewallRule.
- - base:
- apiVersion: database.azure.crossplane.io/v1alpha3
- kind: MySQLServerFirewallRule
- spec:
- forProvider:
- resourceGroupNameSelector:
- matchControllerRef: true
- serverNameSelector:
- matchControllerRef: true
- properties:
- startIpAddress: 10.10.0.0
- endIpAddress: 10.10.255.254
- virtualNetworkSubnetIdSelector:
- name: sample-subnet
- patches:
- - fromFieldPath: "metadata.labels"
- toFieldPath: "metadata.labels"
- - fromFieldPath: "metadata.annotations"
- toFieldPath: "metadata.annotations"
- # Some composite resources may be "dynamically provisioned" - i.e. provisioned
- # on-demand to satisfy an application's claim for infrastructure. The
- # writeConnectionSecretsToNamespace field configures the default value used
- # when dynamically provisioning a composite resource; it is explained in more
- # detail below.
- writeConnectionSecretsToNamespace: crossplane-system
-```
-
-Field paths reference a field within a Kubernetes object via a simple string.
-API conventions describe the syntax as "standard JavaScript syntax for accessing
-that field, assuming the JSON object was transformed into a JavaScript object,
-without the leading dot, such as metadata.name". Array indices are specified via
-square braces while object fields may be specified via a period or via square
-braces.Kubernetes field paths do not support advanced features of JSON paths,
-such as `@`, `$`, or `*`. For example given the below `Pod`:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: example-pod
- annotations:
- example.org/a: example-annotation
-spec:
- containers:
- - name: example-container
- image: example:latest
- command: [example]
- args: ["--debug", "--example"]
-```
-
-* `metadata.name` would contain "example-pod"
-* `metadata.annotations['example.org/a']` would contain "example-annotation"
-* `spec.containers[0].name` would contain "example-container"
-* `spec.containers[0].args[1]` would contain "--example"
-
-> Note that Compositions provide _intentionally_ limited functionality when
-> compared to powerful templating and composition tools like Helm or Kustomize.
-> This allows a Composition to be a schemafied Kubernetes-native resource that
-> can be stored in and validated by the Kubernetes API server at authoring time
-> rather than invocation time.
-
-## Using Composite Resources
-
-![Infrastructure Composition Provisioning]
-
-Crossplane offers several ways for both infrastructure operators and application
-operators to use the composite resource they've defined and offered:
-
-1. Only infrastructure operators can create or manage a composite resource that
- does not offer a composite resource claim.
-1. Infrastructure operators can also create composite resources that offer a
- claim. This allows an application operator to create a claim that
- specifically requests the composite resource the infrastructure operator
- created.
-1. Application operators can create a composite resource claim (if the composite
- resource offers one), and a composite resource will be provisioned on-demand.
-
-Options one and two are frequently referred to as "static provisioning", while
-option three is known as "dynamic provisioning".
-
-> Note that infrastructure operator focused Crossplane concepts are cluster
-> scoped - they exist outside any namespace. Crossplane assumes infrastructure
-> operators will have similar RBAC permissions to cluster administrators, and
-> will thus be permitted to manage cluster scoped resources. Application
-> operator focused Crossplane concepts are namespaced. Crossplane assumes
-> application operators will be permitted access to the namespace(s) in which
-> their applications run, and not to cluster scoped resources.
-
-### Creating and Managing Composite Resources
-
-An infrastructure operator may wish to author a composite resource of a kind
-that offers a claim so that an application operator may later author a claim for
-that exact resource. This pattern is useful for resources that may take several
-minutes to provision - the infrastructure operator can keep a pool of resources
-available in advance in order to ensure claims may be instantly satisfied.
-
-In some cases an infrastructure operator may wish to use Crossplane to model a
-composite that they do not wish to allow application operators to provision.
-Consider a `VPCNetwork` composite resource that creates an AWS VPC network with
-an internet gateway, route table, and several subnets. Defining this resource as
-a composite allows the infrastructure operator to easily reuse their
-configuration, but it does not make sense in their organisation to allow
-application operators to create "supporting infrastructure" like a VPC network.
-
-In both of the above scenarios the infrastructure operator may statically
-provision a composite resource; i.e. author it directly rather than via its
-corresponding resource claim. The `CompositeMySQLInstance` composite resource
-defined above could be authored as follows:
-
-```yaml
-apiVersion: example.org/v1alpha1
-kind: CompositeMySQLInstance
-metadata:
- # Composite resources are cluster scoped, so there's no need for a namespace.
- name: example
-spec:
- # The schema of the spec.parameters object is defined by the earlier example
- # of an CompositeResourceDefinition. The location, storageGB, and version fields
- # are patched onto the ResourceGroup, MySQLServer, and MySQLServerFirewallRule
- # that this MySQLInstance composes.
- parameters:
- location: au-east
- storageGB: 20
- version: "5.7"
- # Support for a compositionRef is automatically injected into the schema of
- # all defined composite resources. This allows the resource
- # author to explicitly reference a Composition that this composite resource
- # should use - in this case the earlier example-azure Composition. Note that
- # it is also possible to select a composition by labels - see the below
- # MySQLInstance for an example of this approach.
- compositionRef:
- name: example-azure
- # Support for a writeConnectionSecretToRef is automatically injected into the
- # schema of all defined composite resources. This allows the
- # resource to write a connection secret containing any details required to
- # connect to it - in this case the hostname, username, and password. Composite
- # resource authors may omit this reference if they do not need or wish to
- # write these details.
- writeConnectionSecretToRef:
- namespace: infra-secrets
- name: example-mysqlinstance
-```
-
-Any updates to the `CompositeMySQLInstance` will be immediately reconciled with
-the resources it composes. For example if more storage were needed an update to
-the `spec.parameters.storageGB` field would immediately be propagated to the
-`spec.forProvider.storageProfile.storageMB` field of the composed `MySQLServer`
-due to the relationship established between these two fields by the patches
-configured in the `example-azure` `Composition`.
-
-`kubectl describe` may be used to examine a composite resource. Note the
-`Synced` and `Ready` conditions below. The former indicates that Crossplane is
-successfully reconciling the composite resource by updating the composed
-resources. The latter indicates that all composed resources are also indicating
-that they are in condition `Ready`, and therefore the composite resource should
-be online and ready to use. More detail about the health and configuration of
-the composite resource can be determined by describing each composite resource.
-The kinds and names of each composed resource are exposed as "Resource Refs" -
-for example `kubectl describe mysqlserver example-zrpgr` will describe the
-detailed state of the composed Azure `MySQLServer`.
-
-```console
-$ kubectl describe compositemysqlinstance.example.org
-
-Name: example
-Namespace:
-Labels:
-Annotations: API Version: example.org/v1alpha1
-Kind: CompositeMySQLInstance
-Metadata:
- Creation Timestamp: 2020-05-15T06:53:16Z
- Generation: 4
- Resource Version: 1425809
- Self Link: /apis/example.org/v1alpha1/compositemysqlinstances/example
- UID: f654dd52-fe0e-47c8-aa9b-235c77505674
-Spec:
- Composition Ref:
- Name: example-azure
- Parameters:
- Location: au-east
- Storage GB: 20
- Version: 5.7
- Reclaim Policy: Delete
- Resource Refs:
- API Version: azure.crossplane.io/v1alpha3
- Kind: ResourceGroup
- Name: example-wspmk
- UID: 4909ab46-95ef-4ba7-8f7a-e1d9ee1a6b23
- API Version: database.azure.crossplane.io/v1beta1
- Kind: MySQLServer
- Name: example-zrpgr
- UID: 3afb903e-32db-4834-a6e7-31249212dca0
- API Version: database.azure.crossplane.io/v1alpha3
- Kind: MySQLServerFirewallRule
- Name: example-h4zjn
- UID: 602c8412-7c33-4338-a3af-78166c17b1a0
- Write Connection Secret To Ref:
- Name: example-mysqlinstance
- Namespace: infra-secrets
-Status:
- Conditions:
- Last Transition Time: 2020-05-15T06:56:46Z
- Reason: Resource is available for use
- Status: True
- Type: Ready
- Last Transition Time: 2020-05-15T06:53:16Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal SelectComposition 10s (x7 over 3m40s) composite/compositemysqlinstances.example.org Successfully selected composition
- Normal PublishConnectionSecret 10s (x7 over 3m40s) composite/compositemysqlinstances.example.org Successfully published connection details
- Normal ComposeResources 10s (x7 over 3m40s) composite/compositemysqlinstances.example.org Successfully composed resources
-```
-
-### Creating a Composite Resource Claim
-
-Composite resource claims represent an application's need for a particular kind
-of composite resource, for example the above `MySQLInstance`. Claims are a proxy
-for the kind of resource they require, allowing application operators to
-provision and consume infrastructure. An claim may request pre-existing,
-statically provisioned infrastructure or it may dynamically provision a
-composite resource on-demand.
-
-The below claim explicitly requests the `CompositeMySQLInstance` authored in the
-previous example:
-
-```yaml
-# The MySQLInstance always has the same API group and version as the
-# resource it requires. Its kind is always suffixed with .
-apiVersion: example.org/v1alpha1
-kind: MySQLInstance
-metadata:
- # Infrastructure claims are namespaced.
- namespace: default
- name: example
-spec:
- # The schema of the spec.parameters object is defined by the earlier example
- # of an CompositeResourceDefinition. The location, storageGB, and version fields
- # are patched onto the ResourceGroup, MySQLServer, and MySQLServerFirewallRule
- # composed by the required MySQLInstance.
- parameters:
- location: au-east
- storageGB: 20
- version: "5.7"
- # Support for a resourceRef is automatically injected into the schema of all
- # resource claims. The resourceRef requests a CompositeMySQLInstance
- # explicitly.
- resourceRef:
- apiVersion: example.org/v1alpha1
- kind: CompositeMySQLInstance
- name: example
- # Support for a writeConnectionSecretToRef is automatically injected into the
- # schema of all published infrastructure claim resources. This allows
- # the resource to write a connection secret containing any details required to
- # connect to it - in this case the hostname, username, and password.
- writeConnectionSecretToRef:
- name: example-mysqlinstance
-```
-
-A claim may omit the `resourceRef` and instead include a `compositionRef` (as in
-the previous `CompositeMySQLInstance` example) or a `compositionSelector` in
-order to trigger dynamic provisioning. A claim that does not include a reference
-to an existing composite resource will have a suitable composite resource
-provisioned on demand:
-
-```yaml
-apiVersion: example.org/v1alpha1
-kind: MySQLInstance
-metadata:
- namespace: default
- name: example
-spec:
- parameters:
- location: au-east
- storageGB: 20
- version: "5.7"
- # Support for a compositionSelector is automatically injected into the schema
- # of all published infrastructure claim resources. This selector selects
- # the example-azure composition by its labels.
- compositionSelector:
- matchLabels:
- purpose: example
- provider: azure
- writeConnectionSecretToRef:
- name: example-mysqlinstance
-```
-
-> Note that compositionSelector labels can form a shared language between the
-> infrastructure operators who define compositions and the application operators
-> who require composite resources. Compositions could be labelled by zone, size,
-> or purpose in order to allow application operators to request a class of
-> composite resource by describing their needs such as "east coast, production".
-
-Like composite resources, claims can be examined using `kubectl describe`.
-The `Synced` and `Ready` conditions have the same meaning as the `MySQLInstance`
-above. The "Resource Ref" indicates the name of the composite resource that was
-either explicitly required, or in the case of the below claim dynamically
-provisioned.
-
-```console
-$ kubectl describe mysqlinstanceclaim.example.org example
-
-Name: example
-Namespace: default
-Labels:
-Annotations: API Version: example.org/v1alpha1
-Kind: MySQLInstance
-Metadata:
- Creation Timestamp: 2020-05-15T07:08:11Z
- Finalizers:
- finalizer.apiextensions.crossplane.io
- Generation: 3
- Resource Version: 1428420
- Self Link: /apis/example.org/v1alpha1/namespaces/default/mysqlinstances/example
- UID: d87e9580-9d2e-41a7-a198-a39851815840
-Spec:
- Composition Selector:
- Match Labels:
- Provider: azure
- Purpose: example
- Parameters:
- Location: au-east
- Storage GB: 20
- Version: 5.7
- Resource Ref:
- API Version: example.org/v1alpha1
- Kind: CompositeMySQLInstance
- Name: default-example-8t4tb
- Write Connection Secret To Ref:
- Name: example-mysqlinstance
-Status:
- Conditions:
- Last Transition Time: 2020-05-15T07:26:49Z
- Reason: Resource is available for use
- Status: True
- Type: Ready
- Last Transition Time: 2020-05-15T07:08:11Z
- Reason: Successfully reconciled resource
- Status: True
- Type: Synced
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal ConfigureCompositeResource 8m23s claim/compositemysqlinstances.example.org Successfully configured composite resource
- Normal BindCompositeResource 8m23s (x7 over 8m23s) claim/compositemysqlinstances.example.org Composite resource is not yet ready
- Normal BindCompositeResource 4m53s (x4 over 23m) claim/compositemysqlinstances.example.org Successfully bound composite resource
- Normal PropagateConnectionSecret 4m53s (x4 over 23m) claim/compositemysqlinstances.example.org Successfully propagated connection details from composite resource
-```
-
-## Current Limitations
-
-Composite resources are an alpha feature of Crossplane. At present the below
-functionality is planned but not yet implemented:
-
-* Updates to a composite resource are immediately applied to the resources it
- composes, but updates to a claim are not yet applied to the composite resource
- that was allocated to satisfy the claim. In a future release of Crossplane
- updating a claim will update its allocated composite resource.
-* Only three transforms are currently supported - string format, multiplication,
- and map. Crossplane intends to limit the set of supported transforms, and will
- add more as clear use cases appear.
-* Compositions are mutable, and updating a composition causes all composite
- resources that use that composition to be updated accordingly. A future
- release of Crossplane may alter this behaviour.
-
-[Current Limitations]: #current-limitations
-[Infrastructure Composition Concepts]: composition-concepts.png
-[structural schemas]: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#specifying-a-structural-schema
-[Infrastructure Composition Provisioning]: composition-provisioning.png
diff --git a/docs/v0.14/introduction/crossplane-concepts.png b/docs/v0.14/introduction/crossplane-concepts.png
deleted file mode 100644
index 7ae3b0a9..00000000
Binary files a/docs/v0.14/introduction/crossplane-concepts.png and /dev/null differ
diff --git a/docs/v0.14/introduction/managed-resources.md b/docs/v0.14/introduction/managed-resources.md
deleted file mode 100644
index 0f0f4f72..00000000
--- a/docs/v0.14/introduction/managed-resources.md
+++ /dev/null
@@ -1,270 +0,0 @@
----
-title: Managed Resources
-toc: true
-weight: 102
-indent: true
----
-
-# Managed Resources
-
-## Overview
-
-Managed resources are the Crossplane representation of the cloud
-[provider][provider] resources and they are considered primitive low level
-custom resources that can be used directly to provision external cloud resources
-for an application or as part of an infrastructure composition.
-
-For example, `RDSInstance` in AWS Provider corresponds to an actual RDS Instance
-in AWS. There is a one-to-one relationship and the changes on managed resources
-are reflected directly on the corresponding resource in the provider.
-
-You can browse [API Reference][api-reference] to discover all available managed
-resources.
-
-## Syntax
-
-Crossplane API conventions extend the Kubernetes API conventions for the schema
-of Crossplane managed resources. Following is an example of `RDSInstance`:
-
-```yaml
-apiVersion: database.aws.crossplane.io/v1beta1
-kind: RDSInstance
-metadata:
- name: foodb
-spec:
- forProvider:
- dbInstanceClass: db.t2.small
- masterUsername: root
- allocatedStorage: 20
- engine: mysql
- writeConnectionSecretToRef:
- name: mysql-secret
- namespace: crossplane-system
- providerConfigRef:
- name: default
- reclaimPolicy: Delete
-```
-
-In Kubernetes, `spec` top field represents the desired state of the user.
-Crossplane adheres to that and has its own conventions about how the fields
-under `spec` should look like.
-
-* `writeConnectionSecretToRef`: A reference to the secret that you want this
- managed resource to write its connection secret that you'd be able to mount to
- your pods in the same namespace. For `RDSInstance`, this secret would contain
- `endpoint`, `username` and `password`.
-
-* `providerConfigRef`: Reference to the `ProviderConfig` resource that will
- provide information regarding authentication of Crossplane to the provider.
- `ProviderConfig` resources refer to `Secret` and potentially contain other
- information regarding authentication. The `providerConfigRef` is defaulted to
- a `ProviderConfig` named `default` if omitted.
-
-* `deletionPolicy`: Enum to specify whether the actual cloud resource should be
- deleted when this managed resource is deleted in Kubernetes API server.
- Possible values are `Delete` (the default) and `Orphan`.
-
-* `forProvider`: While the rest of the fields relate to how Crossplane should
- behave, the fields under `forProvider` are solely used to configure the actual
- external resource. In most of the cases, the field names correspond to the
- what exists in provider's API Reference.
-
- The objects under `forProvider` field can get huge depending on the provider
- API. For example, GCP `ServiceAccount` has only a few fields while GCP
- `CloudSQLInstance` has over 100 fields that you can configure.
-
-### Versioning
-
-Crossplane closely follows the [Kubernetes API versioning
-conventions][api-versioning] for the CRDs that it deploys. In short, for
-`vXbeta` and `vX` versions, you can expect that either automatic migration or
-instructions for manual migration will be provided when a new version of that
-CRD schema is released.
-
-### Grouping
-
-In general, managed resources are high fidelity resources meaning they will
-provide parameters and behaviors that are provided by the external resource API.
-This applies to grouping of resources, too. For example, `Queue` appears under
-`sqs` API group in AWS,so, its `APIVersion` and `Kind` look like the following:
-
-```yaml
-apiVersion: sqs.aws.crossplane.io/v1beta1
-kind: Queue
-```
-
-## Behavior
-
-As a general rule, managed resource controllers try not to make any decision
-that is not specified by the user in the desired state since managed resources
-are the lowest level primitives that operate directly on the cloud provider
-APIs.
-
-### Continuous Reconciliation
-
-Crossplane providers continuously reconcile the managed resource to achieve the
-desired state. The parameters under `spec` are considered the one and only
-source of truth for the external resource. This means that if someone changed a
-configuration in the UI of the provider, like AWS Console, Crossplane will
-change it back to what's given under `spec`.
-
-#### Immutable Properties
-
-There are configuration parameters in external resources that cloud providers do
-not allow to be changed. If the corresponding field in the managed resource is
-changed by the user, Crossplane submits the new desired state to the provider
-and returns the error, if any. For example, in AWS, you cannot change the region
-of an `RDSInstance`.
-
-Some infrastructure tools such as Terraform delete and recreate the resource to
-accommodate those changes but Crossplane does not take that route. Unless the
-managed resource is deleted and its `reclaimPolicy` is `Delete`, its controller
-never deletes the external resource in the provider.
-
-> Immutable fields are marked as `immutable` in Crossplane codebase but
-Kubernetes does not yet have immutable field notation in CRDs.
-
-### External Name
-
-By default the name of the managed resource is used as the name of the external
-cloud resource that will show up in your cloud console. To specify a different
-external name, Crossplane has a special annotation to represent the name of the
-external resource. For example, I would like to have a `CloudSQLInstance` with
-an external name that is different than its managed resource name:
-
-```yaml
-apiVersion: database.gcp.crossplane.io/v1beta1
-kind: CloudSQLInstance
-metadata:
- name: foodb
- annotations:
- crossplane.io/external-name: my-special-db
-spec:
- ...
-```
-
-When you create this managed resource, you will see that the name of
-`CloudSQLInstance` in GCP console will be `my-special-db`.
-
-If the annotation is not given, Crossplane will fill it with the name of the
-managed resource by default. In cases where provider doesn't allow you to name
-the resource, like AWS VPC, the controller creates the resource and sets
-external annotation to be the name that the cloud provider chose. So, you would
-see something like `vpc-28dsnh3` as the value of `crossplane.io/external-name`
-annotation of your AWS `VPC` resource even if you added your own custom external
-name during creation.
-
-### Late Initialization
-
-For some of the optional fields, users rely on the default that the cloud
-provider chooses for them. Since Crossplane treats the managed resource as the
-source of the truth, values of those fields need to exist in `spec` of the
-managed resource. So, in each reconciliation, Crossplane will fill the value of
-a field that is left empty by the user but is assigned a value by the provider.
-For example, there could be two fields like `region` and `availabilityZone` and
-you might want to give only `region` and leave the availability zone to be
-chosen by the cloud provider. In that case, if the provider assigns an
-availability zone, Crossplane gets that value and fills `availabilityZone`. Note
-that if the field is already filled, the controller won't override its value.
-
-### Deletion
-
-When a deletion request is made for a managed resource, its controller starts
-the deletion process immediately. However, the managed resource is kept in the
-Kubernetes API (via a finalizer) until the controller confirms the external
-resource in the cloud is gone. So you can be sure that if the managed resource
-is deleted, then the external cloud resource is also deleted. Any errors that
-happen during deletion will be added to the `status` of the managed resource, so
-you can troubleshoot any issues.
-
-## Dependencies
-
-In many cases, an external resource refers to another one for a specific
-configuration. For example, you could want your Azure Kubernetes cluster in a
-specific Virtual Network. External resources have specific fields for these
-relations, however, they usually require the information to be supplied in
-different formats. In Azure MySQL, you might be required to enter only the name
-of the Virtual Network while in Azure Kubernetes, it could be required to enter
-a string in a specific format that includes other information such as resource
-group name.
-
-In Crossplane, users have 3 fields to refer to another resource. Here is an
-example from Azure MySQL managed resource referring to a Azure Resource Group:
-
-```yaml
-spec:
- forProvider:
- resourceGroupName: foo-res-group
- resourceGroupNameRef:
- name: resourcegroup
- resourceGroupNameSelector:
- matchLabels:
- app: prod
-```
-
-In this example, the user provided only a set of labels to select a
-`ResourceGroup` managed resource that already exists in the cluster via
-`resourceGroupNameSelector`. Then after a specific `ResourceGroup` is selected,
-`resourceGroupNameRef` is filled with the name of that `ResourceGroup` managed
-resource. Then in the last step, Crossplane fills the actual `resourceGroupName`
-field with whatever format Azure accepts it. Once a dependency is resolved, the
-controller never changes it.
-
-Users are able to specify any of these three fields:
-
-- Selector to select via labels
-- Reference to point to a determined managed resource
-- Actual value that will be submitted to the provider
-
-It's important to note that in case a reference exists, the managed resource
-does not create the external resource until the referenced object is ready. In
-this example, creation call of Azure MySQL Server will not be made until
-referenced `ResourceGroup` has its `status.condition` named `Ready` to be true.
-
-## Importing Existing Resources
-
-If you have some resources that are already provisioned in the cloud provider,
-you can import them as managed resources and let Crossplane manage them. What
-you need to do is to enter the name of the external resource as well as the
-required fields on the managed resource. For example, let's say I have a GCP
-Network provisioned from GCP console and I would like to migrate it to
-Crossplane. Here is the YAML that I need to create:
-
-```yaml
-apiVersion: compute.gcp.crossplane.io/v1beta1
-kind: Network
-metadata:
- name: foo-network
- annotations:
- crossplane.io/external-name: existing-network
-spec:
- providerConfigRef:
- name: default
-```
-
-Crossplane will check whether a GCP Network called `existing-network` exists,
-and if it does, then the optional fields under `forProvider` will be filled with
-the values that are fetched from the provider.
-
-Note that if a resource has required fields, you must fill those fields or the
-creation of the managed resource will be rejected. So, in those cases, you will
-need to enter the name of the resource as well as the required fields as
-indicated in the [API Reference][api-reference] documentation.
-
-## Backup and Restore
-
-Crossplane adheres to Kubernetes conventions as much as possible and one of the
-advantages we gain is backup & restore ability with tools that work with native
-Kubernetes types, like [Velero][velero].
-
-If you'd like to backup and restore manually, you can simply export them and
-save YAMLs in your file system. When you reload them, as we've discovered in
-import section, their `crosssplane.io/external-name` annotation and required
-fields are there and those are enough to import a resource. The tool you're
-using needs to store `annotations` and `spec` fields, which most tools do
-including Velero.
-
-[api-versioning]: https://kubernetes.io/docs/reference/using-api/api-overview/#api-versioning
-[velero]: https://velero.io/
-[api-reference]: api-docs/overview.md
-[provider]: provider.md
diff --git a/docs/v0.14/introduction/overview.md b/docs/v0.14/introduction/overview.md
deleted file mode 100644
index 6c8b72de..00000000
--- a/docs/v0.14/introduction/overview.md
+++ /dev/null
@@ -1,131 +0,0 @@
----
-title: Introduction
-toc: true
-weight: 100
----
-
-# Overview
-
-Crossplane introduces multiple building blocks that enable you to provision,
-compose, and consume infrastructure using the Kubernetes API. These individual
-concepts work together to allow for powerful separation of concern between
-different personas in an organization, meaning that each member of a team
-interacts with Crossplane at an appropriate level of abstraction.
-
-![Crossplane Concepts]
-
-The diagram above illustrates a common workflow using most of Crossplane's
-functionality.
-
-An infrastructure operator...
-
-1. Installs Crossplane and one or more [providers] (in this case
- [provider-azure]) as [packages]. This enables provisioning of external
- infrastructure from the Kubernetes cluster.
-2. Defines a new `CompositeMySQLInstance` composite resource and a corresponding
- `MySQLInstance` resource claim by authoring a `CompositeResourceDefinition`.
-3. Creates a `Composition` that instructs Crossplane how to render one or more
- managed resources installed by providers in response to the creation of the
- composite resource. In this case the `Composition` specifies that Azure
- `MySQLServer` and `MySQLFirewallRule` [managed resources] should be created
- to satisfy a `CompositeMySQLInstance`.
-
-An application developer...
-
-1. Creates an [OAM] `Component` for their service that specifies that they wish
- to be run as an OAM `ContainerizedWorkload`.
-2. Creates an OAM `Component` for their MySQL database that can be satisfied by
- the `MySQLInstance` resource claim.
-
-An application operator...
-
-1. Creates an OAM `ApplicationConfiguration`, which is comprised of the two
- `Component` types that were defined by the application developer, and a
- `ManualScalerTrait` trait to modify the replicas in the
- `ContainerizedWorkload`. In response, Crossplane translates the OAM types
- into Kubernetes-native types, in this case a `Deployment` and `Service` for
- the `ContainerizedWorkload` component, and a `MySQLServer` and
- `MySQLFirewallRule` for the `MySQLInstance` component.
-2. Crossplane provisions the external infrastructure and makes the connection
- information available to the application, allowing it to connect to and
- consume the MySQL database on Azure.
-
-The concepts used in this workflow are explained in greater detail below and in
-their individual documentation.
-
-## Packages
-
-Packages allow Crossplane to be extended to include new functionality. This
-typically looks like bundling a set of Kubernetes [CRDs] and [controllers] that
-represent and manage external infrastructure (i.e. a provider), then installing
-them into a cluster where Crossplane is running. Crossplane handles making sure
-any new CRDs do not conflict with existing ones, as well as manages the RBAC and
-security of new packages. Packages are not strictly required to be providers,
-but it is the most common use-case for packages at this time.
-
-## Providers
-
-Providers are packages that enable Crossplane to provision infrastructure on an
-external service. They bring CRDs (i.e. managed resources) that map one-to-one
-to external infrastructure resources, as well as controllers to manage the
-life-cycle of those resources. You can read more about providers, including how
-to install and configure them, in the [providers documentation].
-
-## Managed Resources
-
-Managed resources are Kubernetes custom resources that represent infrastructure
-primitives. Managed resources with an API version of `v1beta1` or higher support
-every field that the cloud provider does for the given resource. You can find
-the Managed Resources and their API specifications for each provider on
-[doc.crds.dev] and learn more in the [managed resource documentation].
-
-## Composite Resources
-
-A composite resource (XR) is a special kind of custom resource that is defined
-by a `CompositeResourceDefinition`. It composes one or more managed resources
-into a higher level infrastructure unit. Composite resources are infrastructure
-operator facing, but may optionally offer an application developer facing
-composite resource claim that acts as a proxy for a composite resource. You can
-learn more about all of these concepts in the [composition documentation].
-
-## OAM
-
-Crossplane supports application management as the Kubernetes implementation of
-the [Open Application Model]. As such, Crossplane currently implements the
-following OAM API types as Kubernetes custom resources.
-
-* `WorkloadDefinition`: defines the kind of components that an application
- developer can use in an application, along with the component's schema.
- * Crossplane also implements the core `ContainerizedWorkload` type.
- Infrastructure owners may define any resource as a workload type by
- referencing it in a `WorkloadDefinition`.
-* `Component`: describe functional units that may be instantiated as part of a
- larger distributed application. For example, each micro-service in an
- application is described as a `Component`.
-* `Trait`: a discretionary runtime overlay that augments a component workload
- type with additional features. It represents an opportunity for those in the
- application operator role to make specific decisions about the configuration
- of components, without having to involve the developer.
- * Crossplane also implements the core `ManualScalerTrait` type.
-* `ApplicationConfiguration`: includes one or more component instances, each
- represented by a component definition that defines how an instance of a
- component spec should be deployed.
-
-For more information, take a look at the [OAM documentation].
-
-
-
-[Crossplane Concepts]: crossplane-concepts.png
-[providers]: #providers
-[provider-azure]: https://github.com/crossplane/provider-azure
-[packages]: #packages
-[managed resources]: #managed-resources
-[OAM]: #oam
-[CRDs]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[controllers]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-controllers
-[providers documentation]: providers.md
-[doc.crds.dev]: https://doc.crds.dev
-[managed resources documentation]: managed-resources.md
-[composition documentation]: composition.md
-[Open Application Model]: https://oam.dev/
-[OAM documentation]: oam.md
diff --git a/docs/v0.14/introduction/packages.md b/docs/v0.14/introduction/packages.md
deleted file mode 100644
index 687cfbc9..00000000
--- a/docs/v0.14/introduction/packages.md
+++ /dev/null
@@ -1,256 +0,0 @@
----
-title: Packages
-toc: true
-weight: 104
-indent: true
----
-
-# Crossplane Packages
-
-Crossplane packages are opinionated [OCI images] that contain a stream of YAML
-that can be parsed by the Crossplane package manager. Crossplane packages come
-in two varieties: [Providers] and Configurations. Ultimately, the primary
-purposes of Crossplane packages are as follows:
-
-- **Convenient Distribution**: Crossplane packages can be pushed to or installed
- from any OCI-compatible registry.
-- **Version Upgrade**: Crossplane can update packages in-place, meaning that you
- can pick up support for new resource types or controller bug-fixes without
- modifying your existing infrastructure.
-- **Permissions**: Crossplane allocates permissions to packaged controllers in a
- manner that ensures they will not maliciously take over control of existing
- resources owned by other packages. Installing CRDs via packages also allows
- Crossplane itself to manage those resources, allowing for powerful
- [composition] features to be enabled.
-- **Dependency Management**: In future releases, Crossplane will be able to
- resolve dependencies between packages, automatically installing a package's
- dependencies if they are not present in the cluster.
-
-## Building a Package
-
-As stated above, Crossplane packages are just opinionated OCI images, meaning
-they can be constructed using any tool that outputs files that comply the the
-OCI specification. However, constructing packages using the Crossplane CLI is a
-more streamlined experience, as it will perform build-time checks on your
-packages to ensure that they are compliant with the Crossplane [package format].
-
-Providers and Configurations vary in the types of resources they may contain in
-their packages. All packages must have a `crossplane.yaml` file in the root
-directory with package contents. The `crossplane.yaml` contains the package's
-metadata, which governs how Crossplane will install the package.
-
-### Provider Packages
-
-A Provider package contains a `crossplane.yaml` with the following format:
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Provider
-metadata:
- name: provider-gcp
-spec:
- controller:
- image: crossplane/provider-gcp-controller:master
-```
-
-> Note: The `meta.pkg.crossplane.io` group does contain custom resources that
-> may be installed into the cluster. They are strictly used as metadata in a
-> Crossplane package.
-
-The `spec.controller.image` fields specifies that the `Provider` desires for a
-`Deployment` to be created with the provided image. It is important to note that
-this image is separate from the package image itself. In the case above, it is
-an image containing the `provider-gcp` controller binary.
-
-A Provider package may optionally contain one or more CRDs. These CRDs will be
-installed prior to the creation of the Provider's `Deployment`. Crossplane will
-not install _any_ CRDs for a package unless it can determine that _all_ CRDs can
-be installed. This guards against multiple Providers attempting to reconcile the
-same CRDs. Crossplane will also create a `ServiceAccount` with permissions to
-reconcile these CRDs and it will be assigned to the controller `Deployment`.
-
-For an example Provider package, see [provider-gcp].
-
-To build a Provider package, navigate to the package root directory and execute
-the following command:
-
-```
-kubectl crossplane build provider
-```
-
-If the Provider package is valid, you will see a file with the `.xpkg`
-extension.
-
-### Configuration Packages
-
-A Configuration package contains a `crossplane.yaml` with the following format:
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1alpha1
-kind: Configuration
-metadata:
- name: my-org-infra
-```
-
-Currently, the only purpose of a Configuration's `crossplane.yaml` is to declare
-that it is in fact a Configuration package type. However, future releases will
-include additional fields for functionality such as specifying dependencies on
-Provider packages.
-
-A Configuration package may also specify one or more of
-`CompositeResourceDefinition` and `Composition` types. These resources will be
-installed and will be solely owned by the Configuration package. No other
-package will be able to modify them.
-
-To build a Configuration package, navigate to the package root directory and
-execute the following command:
-
-```
-kubectl crossplane build configuration
-```
-
-If the Provider package is valid, you will see a file with the `.xpkg`
-extension.
-
-## Pushing a Package
-
-Crossplane packages can be pushed to any OCI-compatible registry. If a specific
-registry is not specified they will be pushed to Docker Hub.
-
-To push a Provider package, execute the following command:
-
-```
-kubectl crossplane push provider crossplane/provider-gcp:master
-```
-
-To push a Configuration package, execute the following command:
-
-```
-kubectl crossplane push configuration crossplane/my-org-infra:master
-```
-
-> Note: Both of the above commands assume a single `.xpkg` file exists in the
-> directory. If multiple exist or you would like to specify a package in a
-> different directory, you can supply the `-f` flag with the path to the
-> package.
-
-## Installing a Package
-
-Packages can be installed into a Crossplane cluster using the Crossplane CLI.
-
-To install a Provider package, execute the following command:
-
-```
-kubectl crossplane install provider crossplane/provider-gcp:master
-```
-
-To install a Configuration package, execute the following command:
-
-```
-kubectl crossplane install configuration crossplane/my-org-infra:master
-```
-
-Packages can also be installed manually by creating a `Provider` or
-`Configuration` object directly. The preceding commands would result in the
-creation of the following two resources, which could have been authored by hand:
-
-```yaml
-apiVersion: pkg.crossplane.io/v1beta1
-kind: Provider
-metadata:
- name: provider-gcp
-spec:
- package: crossplane/provider-gcp:master
- revisionActivationPolicy: Automatic
- revisionHistoryLimit: 1
-```
-
-```yaml
-apiVersion: pkg.crossplane.io/v1beta1
-kind: Configuration
-metadata:
- name: provider-gcp
-spec:
- package: crossplane/provider-gcp:master
- revisionActivationPolicy: Automatic
- revisionHistoryLimit: 1
-```
-
-> Note: These types differ from the `Provider` and `Configuration` types we saw
-> earlier. They exist in the `pkg.crossplane.io` group rather than the
-> `meta.pkg.crossplane.io` group and are actual custom resources created in the
-> cluster.
-
-The `spec.revisionActivationPolicy` and `spec.revisionHistoryLimit` fields are
-explained in the following section.
-
-## Upgrading a Package
-
-Once a package is installed, Crossplane makes it easy to upgrade to a new
-version. Controlling this functionality is accomplished via the three `spec`
-fields shown above. They are explained in detail below.
-
-### spec.package
-
-This is the package image that we built, pushed, and are asking Crossplane to
-install. The tag we specify here is important. Crossplane will periodically
-check if the installed image matches the digest of the image in the remote
-registry. If it does not, Crossplane will create a new _Revision_ (either
-`ProviderRevision` or `ConfigurationRevision`). If you do not wish Crossplane to
-ever update your packages without explicitly instructing it to do so, you should
-consider specifying a tag which you know will not have the underlying contents
-change unexpectedly (e.g. a specific semantic version, such as `v0.1.0`) or, for
-an even stronger guarantee, providing the image with a `@sha256` extension
-instead of a tag.
-
-### spec.revisionActivationPolicy
-
-Valid values: `Automatic` or `Manual` (default: `Automatic`)
-
-This field determines what Crossplane does when a new revision is created, be it
-manually by you specifying a new tag in the `spec.package` field, or
-automatically if a general tag such as `latest` or `master` is used and the
-underlying contents change. When a new revision is created for a package, it can
-either be `Active` or `Inactive`.
-
-An `Active` package revision attempts to become the _controller_ of all
-resources it installs. There can only be one controller of a resource, so if two
-`Active` revisions both install the same resource, one will fail to install
-until the other cedes control.
-
-An `Inactive` package revision attempts to become the _owner_ of all resource it
-installs. There can be an arbitrary number of owners of a resource, so multiple
-`Inactive` revisions and a single `Active` revision can exist for a resource.
-Importantly, an `Inactive` package revision will not perform any auxiliary
-actions (such as creating a `Deployment` in the case of a `Provider`), meaning
-we will not encounter a situation where two revisions are fighting over
-reconciling a resource.
-
-### spec.revisionHistoryLimit
-
-Valid values: any integer, disabled by explicitly setting to `0` (default `1`)
-
-When a revision transitions from `Inactive` to `Active`, its revision number
-gets set to one greater than the largest revision number of all revisions for
-its package. Therefore, as the number of revisions increases, the least recently
-`Active` revision will have the lowest revision number. Crossplane will garbage
-collect old `Inactive` revisions if they fall outside the
-`spec.revisionHistoryLimit`. For instance, if my revision history limit is `3`
-and I currently have three old `Inactive` revisions and one `Active` revision,
-when I upgrade the next time, the new revision will be given the highest
-revision number when it becomes `Active`, the previously `Active` revision will
-become `Inactive`, and the oldest `Inactive` revision will be garbage collected.
-
-> Note: In the case that `spec.revisionActivationPolicy: Manual` and you upgrade
-> enough times (but do not make `Active` the new revisions), it is possible that
-> activating a newer revision could cause the previously `Active` revision to
-> immediately be garbage collected if it is outside the
-> `spec.revisionHistoryLimit`.
-
-
-
-[OCI images]: https://github.com/opencontainers/image-spec
-[Providers]: providers.md
-[composition]: composition.md
-[package format]: https://github.com/crossplane/crossplane/blob/1aa83092172bdf0d2ed64754d33517c612ff7368/design/one-pager-package-format-v2.md
-[provider-gcp]: https://github.com/crossplane/provider-gcp/tree/master/package
diff --git a/docs/v0.14/introduction/providers.md b/docs/v0.14/introduction/providers.md
deleted file mode 100644
index 284a3cc3..00000000
--- a/docs/v0.14/introduction/providers.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-title: Providers
-toc: true
-weight: 101
-indent: true
----
-
-# Providers
-
-Providers extend Crossplane to enable infrastructure resource provisioning. In
-order to provision a resource, a Custom Resource Definition (CRD) needs to be
-registered in your Kubernetes cluster and its controller should be watching the
-Custom Resources those CRDs define. Provider packages contain many Custom
-Resource Definitions and their controllers.
-
-Here is the list of current providers:
-
-### AWS Provider
-
-* [GitHub][provider-aws]
-* [API Reference][aws-reference]
-
-### GCP Provider
-
-* [GitHub][provider-gcp]
-* [API Reference][gcp-reference]
-
-### Azure Provider
-
-* [GitHub][provider-azure]
-* [API Reference][azure-reference]
-
-### Rook Provider
-
-* [GitHub][provider-rook]
-* [API Reference][rook-reference]
-
-### Alibaba Cloud Provider
-
-* [GitHub][provider-alibaba]
-* [API Reference][alibaba-reference]
-
-## Installing Providers
-
-The core Crossplane controller can install provider controllers and CRDs for you
-through its own provider packaging mechanism, which is triggered by the
-application of a `Provider` resource. For example, in order to request
-installation of the `provider-aws` package, apply the following resource to the
-cluster where Crossplane is running:
-
-```yaml
-apiVersion: pkg.crossplane.io/v1beta1
-kind: Provider
-metadata:
- name: provider-aws
-spec:
- package: crossplane/provider-aws:master"
-```
-
-The field `spec.package` is where you refer to the container image of the
-provider. Crossplane Package Manager will unpack that container, register CRDs
-and set up necessary RBAC rules and then start the controllers.
-
-There are a few other ways to to trigger the installation of provider packages:
-
-* As part of Crossplane Helm chart by adding the following statement to your
- `helm install` command: `--set
- provider.packages={crossplane/provider-aws:master}`.
-* Using the Crossplane CLI: `kubectl crossplane install provider
- crossplane/provider-aws:master`
-
-You can uninstall a provider by deleting the `ClusterPackageInstall` resource
-you've created.
-
-## Configuring Providers
-
-In order to authenticate with the external provider API, the provider
-controllers need to have access to credentials. It could be an IAM User for AWS,
-a Service Account for GCP or a Service Principal for Azure. Every provider has a
-type called `ProviderConfig` that has information about how to authenticate to
-the provider API. An example `ProviderConfig` resource for AWS looks like the
-following:
-
-```yaml
-apiVersion: aws.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: aws-provider
-spec:
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: aws-creds
- key: key
-```
-
-You can see that there is a reference to a key in a specific `Secret`. The value
-of that key should contain the credentials that the controller will use. The
-documentation of each provider should give you an idea of how that credentials
-blob should look like. See [Getting Started][getting-started] guide for more
-details.
-
-The following is an example usage of Azure `ProviderConfig`, referenced by a
-`RDSInstance`:
-
-```yaml
-apiVersion: database.aws.crossplane.io/v1beta1
-kind: RDSInstance
-metadata:
- name: prod-sql
-spec:
- providerConfigRef: prod-acc
- ...
-```
-
-The AWS provider controller will use that provider for this instance of
-`RDSInstance`. Since every resource has its own reference to a `ProviderConfig`,
-you can have multiple `ProviderConfig` resources in your cluster referenced by
-different resources. When no `providerConfigRef` is specified, the `RDSInstance`
-will attempt to use a `ProviderConfig` named `default`.
-
-
-
-[provider-aws]: https://github.com/crossplane/provider-aws
-[aws-reference]: https://doc.crds.dev/github.com/crossplane/provider-aws
-[provider-gcp]: https://github.com/crossplane/provider-gcp
-[gcp-reference]: https://doc.crds.dev/github.com/crossplane/provider-gcp
-[provider-azure]: https://github.com/crossplane/provider-azure
-[azure-reference]: https://doc.crds.dev/github.com/crossplane/provider-azure
-[provider-rook]: https://github.com/crossplane/provider-rook
-[rook-reference]: https://doc.crds.dev/github.com/crossplane/provider-rook
-[provider-alibaba]: https://github.com/crossplane/provider-alibaba
-[alibaba-reference]: https://doc.crds.dev/github.com/crossplane/provider-alibaba
-[getting-started]: ../getting-started/install-configure.md
diff --git a/docs/v0.14/media/arch.png b/docs/v0.14/media/arch.png
deleted file mode 100644
index 8205e62e..00000000
Binary files a/docs/v0.14/media/arch.png and /dev/null differ
diff --git a/docs/v0.14/media/banner.png b/docs/v0.14/media/banner.png
deleted file mode 100644
index 0a495e1d..00000000
Binary files a/docs/v0.14/media/banner.png and /dev/null differ
diff --git a/docs/v0.14/media/crossplane-overview.png b/docs/v0.14/media/crossplane-overview.png
deleted file mode 100644
index 87c25a89..00000000
Binary files a/docs/v0.14/media/crossplane-overview.png and /dev/null differ
diff --git a/docs/v0.14/media/logo.svg b/docs/v0.14/media/logo.svg
deleted file mode 100644
index 3af90369..00000000
--- a/docs/v0.14/media/logo.svg
+++ /dev/null
@@ -1,310 +0,0 @@
-
-
-
diff --git a/docs/v0.14/reference/configure.md b/docs/v0.14/reference/configure.md
deleted file mode 100644
index 45c4934c..00000000
--- a/docs/v0.14/reference/configure.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Configure
-toc: true
-weight: 302
-indent: true
----
-
-# Configure Your Cloud Provider Account
-
-In order for Crossplane to be able to manage resources in a specific cloud
-provider, you will need to create an account for Crossplane to use. Use the
-links below for cloud-specific instructions to create an account that can be
-used throughout the guides:
-
-* [Google Cloud Platform (GCP) Service Account]
-* [Microsoft Azure Service Principal]
-* [Amazon Web Services (AWS) IAM User]
-
-Once you have configured your cloud provider account, you can get started
-provisioning resources!
-
-
-
-[Google Cloud Platform (GCP) Service Account]: ../cloud-providers/gcp/gcp-provider.md
-[Microsoft Azure Service Principal]: ../cloud-providers/azure/azure-provider.md
-[Amazon Web Services (AWS) IAM User]: ../cloud-providers/aws/aws-provider.md
diff --git a/docs/v0.14/reference/install.md b/docs/v0.14/reference/install.md
deleted file mode 100644
index 3e2187a7..00000000
--- a/docs/v0.14/reference/install.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: Install
-toc: true
-weight: 301
-indent: true
----
-
-# Install Crossplane
-
-Crossplane can be easily installed into any existing Kubernetes cluster using
-the regularly published Helm chart. The Helm chart contains all the custom
-resources and controllers needed to deploy and configure Crossplane.
-
-## Pre-requisites
-
-* [Kubernetes cluster], minimum version `v1.16.0+`
-* [Helm], minimum version `v3.0.0+`.
-
-## Installation
-
-Helm charts for Crossplane are currently published to the `alpha` and `master`
-channels. In the future, `beta` and `stable` will also be available.
-
-### Alpha
-
-The alpha channel is the most recent release of Crossplane that is considered
-ready for testing by the community.
-
-```console
-kubectl create namespace crossplane-system
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-### Master
-
-The `master` channel contains the latest commits, with all automated tests
-passing. `master` is subject to instability, incompatibility, and features may
-be added or removed without much prior notice. It is recommended to use one of
-the more stable channels, but if you want the absolute newest Crossplane
-installed, then you can use the `master` channel.
-
-To install the Helm chart from master, you will need to pass the specific
-version returned by the `search` command:
-
-```console
-kubectl create namespace crossplane-system
-helm repo add crossplane-master https://charts.crossplane.io/master/
-helm search repo crossplane-master --devel
-
-helm install crossplane --namespace crossplane-system crossplane-master/crossplane --devel --version
-```
-
-## Uninstalling the Chart
-
-To uninstall/delete the `crossplane` deployment:
-
-```console
-helm delete crossplane --namespace crossplane-system
-```
-
-That command removes all Kubernetes components associated with Crossplane,
-including all the custom resources and controllers.
-
-## Configuration
-
-The following tables lists the configurable parameters of the Crossplane chart
-and their default values.
-
-| Parameter | Description | Default |
-| --- | --- | --- |
-| `image.repository` | Image | `crossplane/crossplane` |
-| `image.tag` | Image tag | `master` |
-| `image.pullPolicy` | Image pull policy | `Always` |
-| `imagePullSecrets` | Names of image pull secrets to use | `dockerhub` |
-| `replicas` | The number of replicas to run for the Crossplane and RBAC Manager (if enabled) pods | `1` |
-| `deploymentStrategy` | The deployment strategy for the Crossplane and RBAC Manager (if enabled) pods | `RollingUpdate` |
-| `priorityClassName` | Priority class name for Crossplane and RBAC Manager (if enabled) pods | `""` |
-| `resourcesCrossplane.limits.cpu` | CPU resource limits for Crossplane | `100m` |
-| `resourcesCrossplane.limits.memory` | Memory resource limits for Crossplane | `512Mi` |
-| `resourcesCrossplane.requests.cpu` | CPU resource requests for Crossplane | `100m` |
-| `resourcesCrossplane.requests.memory` | Memory resource requests for Crossplane | `256Mi` |
-| `packageCache.medium` | Storage medium for package cache. `Memory` means volume will be backed by tmpfs, which can be useful for development. | `""` |
-| `packageCache.sizeLimit` | Size limit for package cache. If medium is `Memory` then maximum usage would be the minimum of this value the sum of all memory limits on containers in the Crossplane pod. | `5Mi` |
-| `packageCache.pvc` | Name of the PersistentVolumeClaim to be used as the package cache. Providing a value will cause the default emptyDir volume to not be mounted. | `""` |
-| `resourcesRBACManager.limits.cpu` | CPU resource limits for RBAC Manager | `100m` |
-| `resourcesRBACManager.limits.memory` | Memory resource limits for RBAC Manager | `512Mi` |
-| `resourcesRBACManager.requests.cpu` | CPU resource requests for RBAC Manager | `100m` |
-| `resourcesRBACManager.requests.memory` | Memory resource requests for RBAC Manager | `256Mi` |
-| `rbacManager.deploy` | Deploy RBAC Manager and its required roles | `true` |
-| `rbacManager.managementPolicy`| The extent to which the RBAC manager will manage permissions. `All` indicates to manage all Crossplane controller and user roles. `Basic` indicates to only manage Crossplane controller roles and the `crossplane-admin`, `crossplane-edit`, and `crossplane-view` user roles. | `All` |
-| `alpha.oam.enabled` | Deploy the `crossplane/oam-kubernetes-runtime` Helm chart | `false` |
-| `provider.packages` | The list of Provider packages to install together with Crossplane | `[]` |
-
-### Command Line
-
-You can pass the settings with helm command line parameters. Specify each
-parameter using the `--set key=value[,key=value]` argument to `helm install`.
-For example, the following command will install Crossplane with an image pull
-policy of `IfNotPresent`.
-
-```console
-helm install --namespace crossplane-system crossplane-alpha/crossplane --set image.pullPolicy=IfNotPresent
-```
-
-### Settings File
-
-Alternatively, a yaml file that specifies the values for the above parameters
-(`values.yaml`) can be provided while installing the chart.
-
-```console
-helm install crossplane --namespace crossplane-system crossplane-alpha/crossplane -f values.yaml
-```
-
-Here are the sample settings to get you started.
-
-```yaml
-replicas: 1
-
-deploymentStrategy: RollingUpdate
-
-image:
- repository: crossplane/crossplane
- tag: alpha
- pullPolicy: Always
-
-imagePullSecrets:
-- dockerhub
-```
-
-
-
-[Kubernetes cluster]: https://kubernetes.io/docs/setup/
-[Minikube]: https://kubernetes.io/docs/tasks/tools/install-minikube/
-[Helm]: https://docs.helm.sh/using_helm/
diff --git a/docs/v0.14/reference/learn_more.md b/docs/v0.14/reference/learn_more.md
deleted file mode 100644
index 75bd883e..00000000
--- a/docs/v0.14/reference/learn_more.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: Learn More
-toc: true
-weight: 304
-indent: true
----
-
-# Learn More
-
-If you have any questions, please drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us]!
-
-***Learn more about using Crossplane***
- - [Latest Design Docs](https://github.com/crossplane/crossplane/tree/master/design)
- - [Roadmap](https://github.com/crossplane/crossplane/blob/master/ROADMAP.md)
- - [Crossplane Architecture](https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit?usp=sharing)
- - [GitLab deploys into multiple clouds from kubectl using Crossplane](https://about.gitlab.com/2019/05/20/gitlab-first-deployed-kubernetes-api-to-multiple-clouds/)
- - [CNCF Talks & Community Presentations](https://www.youtube.com/playlist?list=PL510POnNVaaZJj9OG6PbgsZvgYbhwJRyE)
- - [Software Engineering Daily - Intro Podcast](https://softwareengineeringdaily.com/2019/01/02/crossplane-multicloud-control-plane-with-bassam-tabbara/)
-
-***Writing Kubernetes controllers to extend Crossplane***
- - [Keep the Space Shuttle Flying: Writing Robust Operators](https://www.youtube.com/watch?v=uf97lOApOv8)
- - [Best practices for building Kubernetes Operators](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)
- - [Programming Kubernetes Book](https://www.oreilly.com/library/view/programming-kubernetes/9781492047094/)
- - [Contributor Guide](https://github.com/crossplane/crossplane/blob/master/CONTRIBUTING.md)
-
-***Join the growing Crossplane community and get involved!***
-- Join our [Community Slack](https://slack.crossplane.io/)!
-- Submit an issue on [GitHub](https://github.com/crossplane/crossplane)
-- Attend our bi-weekly [Community Meeting](https://github.com/crossplane/crossplane#community-meeting)
-- Join our bi-weekly live stream: [The Binding Status](https://github.com/crossplane/tbs)
-- Subscribe to our [YouTube Channel](https://www.youtube.com/channel/UC19FgzMBMqBro361HbE46Fw)
-- Drop us a note on Twitter: [@crossplane_io](https://twitter.com/crossplane_io)
-- Email us: [info@crossplane.io](mailto:info@crossplane.io)
-
-
-
-[join-crossplane-slack]: https://slack.crossplane.io
-[contact-us]: https://github.com/crossplane/crossplane#contact
diff --git a/docs/v0.14/reference/overview.md b/docs/v0.14/reference/overview.md
deleted file mode 100644
index 9f3a4a15..00000000
--- a/docs/v0.14/reference/overview.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Reference
-toc: true
-weight: 300
----
-
-# Overview
-
-The reference documentation includes answers to frequently asked questions, information about similar projects, and links to resources that can help you learn more about Crossplane and Kubernetes. If you have additional information that you think would be valuable for the community, please feel free to [open a pull request]() and add it.
-
-1. [Install]
-1. [Configure]
-1. [Troubleshoot]
-1. [Learn More]
-
-
-
-[Install]: install.md
-[Configure]: configure.md
-[Troubleshoot]: troubleshoot.md
-[Learn More]: learn_more.md
diff --git a/docs/v0.14/reference/troubleshoot.md b/docs/v0.14/reference/troubleshoot.md
deleted file mode 100644
index 8b5ee2d9..00000000
--- a/docs/v0.14/reference/troubleshoot.md
+++ /dev/null
@@ -1,144 +0,0 @@
----
-title: Troubleshoot
-toc: true
-weight: 303
-indent: true
----
-
-# Troubleshooting
-
-* [Using the trace command]
-* [Resource Status and Conditions]
-* [Crossplane Logs]
-* [Pausing Crossplane]
-* [Deleting a Resource Hangs]
-
-## Using the trace command
-
-The [Crossplane CLI] trace command provides a holistic view for a particular
-object and related ones to ease debugging and troubleshooting process. It finds
-the relevant Crossplane resources for a given one and provides detailed
-information as well as an overview indicating what could be wrong.
-
-Usage:
-```
-kubectl crossplane trace TYPE[.GROUP] NAME [-n| --namespace NAMESPACE] [--kubeconfig KUBECONFIG] [-o| --outputFormat dot]
-```
-
-Examples:
-```
-# Trace a KubernetesApplication
-kubectl crossplane trace KubernetesApplication wordpress-app-83f04457-0b1b-4532-9691-f55cf6c0da6e -n app-project1-dev
-
-# Trace a MySQLInstance
-kubectl crossplane trace MySQLInstance wordpress-mysql-83f04457-0b1b-4532-9691-f55cf6c0da6e -n app-project1-dev
-```
-
-For more information, see [the trace command documentation].
-
-## Resource Status and Conditions
-
-Most Crossplane resources have a `status` section that can represent the current
-state of that particular resource. Running `kubectl describe` against a
-Crossplane resource will frequently give insightful information about its
-condition. For example, to determine the status of a MySQLInstance resource
-claim, run:
-
-```shell
-kubectl -n app-project1-dev describe mysqlinstance mysql-claim
-```
-
-This should produce output that includes:
-
-```console
-Status:
- Conditions:
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Managed claim is waiting for managed resource to become bindable
- Status: False
- Type: Ready
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Successfully reconciled managed resource
- Status: True
- Type: Synced
-```
-
-Most Crossplane resources set exactly two condition types; `Ready` and `Synced`.
-`Ready` represents the availability of the resource itself - whether it is
-creating, deleting, available, unavailable, binding, etc. `Synced` represents
-the success of the most recent attempt to 'reconcile' the _desired_ state of the
-resource with its _actual_ state. The `Synced` condition is the first place you
-should look when a Crossplane resource is not behaving as expected.
-
-## Crossplane Logs
-
-The next place to look to get more information or investigate a failure would be
-in the Crossplane pod logs, which should be running in the `crossplane-system`
-namespace. To get the current Crossplane logs, run the following:
-
-```shell
-kubectl -n crossplane-system logs -lapp=crossplane
-```
-
-Remember that much of Crossplane's functionality is provided by Stacks. You can
-use `kubectl logs` to view Stack logs too, though Stacks may not run in the
-`crossplane-system` namespace.
-
-## Pausing Crossplane
-
-Sometimes, for example when you encounter a bug. it can be useful to pause
-Crossplane if you want to stop it from actively attempting to manage your
-resources. To pause Crossplane without deleting all of its resources, run the
-following command to simply scale down its deployment:
-
-```bash
-kubectl -n crossplane-system scale --replicas=0 deployment/crossplane
-```
-
-Once you have been able to rectify the problem or smooth things out, you can
-unpause Crossplane simply by scaling its deployment back up:
-
-```bash
-kubectl -n crossplane-system scale --replicas=1 deployment/crossplane
-```
-
-Remember that much of Crossplane's functionality is provided by Stacks. You can
-use `kubectl scale` to pause Stack pods too, though Stacks may not run in the
-`crossplane-system` namespace.
-
-## Deleting a Resource Hangs
-
-The resources that Crossplane manages will automatically be cleaned up so as not
-to leave anything running behind. This is accomplished by using finalizers, but
-in certain scenarios the finalizer can prevent the Kubernetes object from
-getting deleted.
-
-To deal with this, we essentially want to patch the object to remove its
-finalizer, which will then allow it to be deleted completely. Note that this
-won't necessarily delete the external resource that Crossplane was managing, so
-you will want to go to your cloud provider's console and look there for any
-lingering resources to clean up.
-
-In general, a finalizer can be removed from an object with this command:
-
-```console
-kubectl patch -p '{"metadata":{"finalizers": []}}' --type=merge
-```
-
-For example, for a Workload object (`workloads.compute.crossplane.io`) named
-`test-workload`, you can remove its finalizer with:
-
-```console
-kubectl patch workloads.compute.crossplane.io test-workload -p '{"metadata":{"finalizers": []}}' --type=merge
-```
-
-
-
-[Using the trace command]: #using-the-trace-command
-[Resource Status and Conditions]: #resource-status-and-conditions
-[Crossplane Logs]: #crossplane-logs
-[Pausing Crossplane]: #pausing-crossplane
-[Deleting a Resource Hangs]: #deleting-a-resource-hangs
-[Crossplane CLI]: https://github.com/crossplane/crossplane-cli
-[the trace command documentation]: https://github.com/crossplane/crossplane-cli/tree/master/docs/trace-command.md
-[Owner References]: https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents
diff --git a/docs/v0.14/release/release-process.md b/docs/v0.14/release/release-process.md
deleted file mode 100644
index 90f7c0f7..00000000
--- a/docs/v0.14/release/release-process.md
+++ /dev/null
@@ -1,257 +0,0 @@
-# Release Process
-
-This document is meant to be a complete end-to-end guide for how to release new
-versions of software for Crossplane and its related projects.
-
-## tl;dr Process Overview
-
-All the details are available in the sections below, but we'll start this guide
-with a very high level sequential overview for how to run the release process.
-These steps apply to all Crossplane projects, all of which utilize [Github
-Actions](https://github.com/features/actions) for pipelines.
-
-1. **feature freeze**: Merge all completed features into master branches of all
- repos to begin "feature freeze" period.
-1. **pin dependencies**: Update the go module in master to depend on stable
- versions of dependencies if needed.
-1. **branch repo**: Create a new release branch using the GitHub UI for the
- repo.
-1. **release branch prep**: Make any release-specific updates on the release
- branch (typically documentation).
-1. **tag release**: Run the `Tag` action on the _release branch_ with the
- desired version (e.g. `v0.14.0`).
-1. **tag next pre-release**: Run the `tag` action on the `master` branch with
- the `rc.0` for the next release (e.g. `v0.15.0-rc.0`).
-1. **build/publish**: Run the `CI` action on the release branch with the version
- that was just tagged.
-1. **verify**: Verify all artifacts have been published successfully, perform
- sanity testing.
-1. **promote**: Run the `Promote` action to promote release to desired
- channel(s).
-1. **release notes**: Publish well authored and complete release notes on
- GitHub.
-1. **announce**: Announce the release on Twitter, Slack, etc.
-
-## Detailed Process
-
-This section will walk through the release process in more fine grained and
-prescriptive detail.
-
-### Feature Freeze
-
-Feature freeze should be performed on all repos. In order to start the feature
-freeze period, the following conditions should be met:
-
-* All expected features should be
- ["complete"](https://github.com/crossplane/crossplane/blob/master/design/one-pager-definition-of-done.md)
- and merged into master. This includes user guides, examples, API
- documentation, and test updates.
-* All issues in the
- [milestone](https://github.com/crossplane/crossplane/milestones) should be
- closed
-* Sanity testing has been performed on `master`
-
-### Pin Dependencies
-
-It is a best practice to release Crossplane projects with "pinned" dependencies
-to specific stable versions. For example, after crossplane-runtime has been
-released, we want to update the main Crossplane repo to use that specific
-released version.
-
-To update a dependency to a specific version, simply edit the `go.mod` file to
-point to the desired version, then run `go mod tidy`.
-
-### Create Release Branch
-
-Creating the release branch can be done within the [GitHub
-UI](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-and-deleting-branches-within-your-repository).
-Basically, you just use the branch selector drop down and type in the name of
-the new release branch, e.g. `release-0.5`. Release branch names always follow
-the convention of `release-[minor-semver]`.
-
-If this is the first ever release branch being created in a repo (uncommon), you
-should also set up branch protection rules for the `release-*` pattern. You can
-find existing examples in the [Crossplane repo
-settings](https://github.com/crossplane/crossplane/settings/branches).
-
-At this point, the `HEAD` commit in the release branch will be our release
-candidate. The build pipeline will automatically be started due to the create
-branch event, so we can start to perform testing on this build. Note that it
-should be the exact same as what is currently in `master` since they are using
-the same commit and have the same tag. Also note that this is not the official
-release build since we have not made the official release tag yet (e.g.
-`v0.5.0`).
-
-### Release Branch Prep
-
-Some repos may not require any release branch prep. This is desirable as it
-reduces the burden of running a new release. If this is the case for the repo
-being released, you may skip this step.
-
-In the core Crossplane repository, we need to update the release branch docs and
-examples to point to the new versions that we will be releasing soon.
-
-* Documentation, such as pinning
- [snippet](https://github.com/crossplane/crossplane/blob/release-0.14/docs/snippets)
- links to the current release branch.
- * searching for `master` will help a lot here
-
-#### Bug Fixes in Release Branch
-
-During our testing of the release candidate, we may find issues or bugs that we
-triage and decide we want to fix before the release goes out. In order to fix a
-bug in the release branch, the following process is recommended:
-
-1. Make the bug fix into `master` first through the normal PR process
- 1. If the applicable code has already been removed from `master` then simply
- fix the bug directly in the release branch by opening a PR directly
- against the release branch
-1. Backport the fix by performing a cherry-pick of the fix's commit hash
- (**not** the merge commit) from `master` into the release branch. For
- example, to backport a fix from master to `v0.5.0`, something like the
- following should be used:
-
- ```console
- git fetch --all
- git checkout -b release-0.5 upstream/release-0.5
- git cherry-pick -x
- ```
-
-1. Open a PR with the cherry-pick commit targeting the release-branch
-
-After all bugs have been fixed and backported to the release branch, we can move
-on to tagging the final release commit.
-
-### Tag Release
-
-Now it's time to run the `Tag` action on the release branch.
-
-Run the tag action by going to the repo's "Actions" tab in the Github UI. You
-will be prompted for the desired branch and the version you are tagging. The
-latest commit on the selected branch will be the commit that is tagged.
-
-### Tag Next Pre-release
-
-The next step is to create the pre-release tag for the `HEAD` commit in
-`master`. This tag serves as an indication of when the release was branched
-from master and is also important for generating future versions of `master`
-builds since that [versioning
-process](https://github.com/upbound/build/blob/master/makelib/common.mk#L182-L196)
-is based on `git describe --tags`.
-
-> NOTE: the `build` submodule uses the latest tag by timestamp on the branch
-> which the commit it is building resides on. If there were no prep commits made
-> on the release branch, then its `HEAD` is even with `master` (i.e. the stable
-> tag and the next pre-release tag will be on the same commit). This means that
-> we must tag the pre-release version _after_ the stable version to ensure
-> subsequent builds use the next pre-release tag as their base. If there are
-> additional commits on the release branch before the stable tag is created,
-> then the pre-release tag could be created first.
-
-To accomplish this, run the `Tag` action for the repo on the `master` branch.
-You will be prompted to enter the `version` for the tag. Since this tag will
-essentially be the start of pre-releases working towards the **next** version,
-the `version` should be the **next** release number, plus a trailing tag to
-indicate it is a pre-release. The current convention is to use `*-rc.0`. For
-example, when we are releasing the `v0.9.0` release and we are ready for master
-to start working towards the **next** release of `v0.10.0`, we would make the
-tag `v0.10.0-rc.0`
-
-After the tag action has succeeded, verify in the [GitHub
-UI](https://github.com/crossplane/crossplane/tags) that the tag was successfully
-applied to the correct commit.
-
-The `master` branch can now be opened for new features since we have a safe
-release branch to continue bug fixes and improvements for the release itself.
-Essentially, `master` is free to now diverge from the release branch.
-
-### Draft Release Notes
-
-We're getting close to starting the official release, so you should take this
-opportunity to draft up the release notes. You can create a [new release draft
-here](https://github.com/crossplane/crossplane/releases/new). Make sure you
-select "This is a pre-release" and hit "Save draft" when you are ready to share
-and collect feedback. Do **not** hit "Publish release" yet.
-
-You can see and follow the template and structure from [previous
-releases](https://github.com/crossplane/crossplane/releases).
-
-### Build and Publish
-
-Run the `CI` action on the release branch. This will build and publish the
-official release with the correct version tag and all of its release artifacts
-will be published.
-
-After the pipeline runs successfully, you should verify that all artifacts have
-been published to:
-
-For all repos:
-* [Docker Hub](https://hub.docker.com/repository/docker/crossplane)
-
-For all repos with Helm charts:
-* [S3 releases bucket](https://releases.crossplane.io/)
-* [Helm chart repository](https://charts.crossplane.io/)
-
-For crossplane/crossplane:
-* [Docs website](https://crossplane.io/docs/latest)
-
-### Promote
-
-If everything looks good with the official versioned release that we just
-published, we can go ahead and run the `Promote` action on the release branch.
-This is a very quick pipeline that doesn't rebuild anything, it simply makes
-metadata changes to the published release to also include the release in the
-channel of your choice.
-
-Currently, we only support the `master` and `alpha` channels.
-
-Run the `Promote` action on the release branch and input the version you would
-like to promote (e.g. `v0.5.0`) and the channel you'd like to promote it to.
-
-* Run `Promote` action for `master` channel on release branch
-* Run `Promote` action for `alpha` channel on release branch
-
-After the `Promote` actions have succeeded, verify on DockerHub and the Helm
-chart repository that the release has been promoted to the right channels.
-
-### Publish Release Notes
-
-Now that the release has been published and verified, you can publish the
-[release notes](https://github.com/crossplane/crossplane/releases) that you
-drafted earlier. After incorporating all feedback, you can now click on the
-"Publish release" button.
-
-This will send an email notification with the release notes to all watchers of
-the repo.
-
-### Announce Release
-
-We have completed the entire release, so it's now time to announce it to the
-world. Using the [@crossplane_io](https://twitter.com/crossplane_io) Twitter
-account, tweet about the new release and blog. You'll see examples from the
-previous releases, such as this tweet for
-[v0.4](https://twitter.com/crossplane_io/status/1189307636350705664).
-
-Post a link to this tweet on the Slack #announcements channel, then copy a link
-to that and post it in the #general channel.
-
-### Patch Releases
-
-We also have the ability to run patch releases to update previous releases that
-have already been published. These patch releases are always run from the last
-release branch, we do **not** create a new release branch for a patch release.
-
-The basic flow is **very** similar to a normal release, but with a few less
-steps. Please refer to details for each step in the sections above.
-
-* Fix any bugs in `master` first and then `cherry-pick -x` to the release branch
- * If `master` has already removed the relevant code then make your fix
- directly in the release branch
-* After all testing on the release branch look good and any docs/tests have been
- updated with the new version number, run the `Tag` action on the release
- branch with the new patch version (e.g. `v0.5.1`)
-* Run the normal `CI` action on the release branch to build and publish the
- release
-* Publish release notes
-* Run `Promote` action to promote the patch release to the `master` and `alpha`
- channels
diff --git a/docs/v0.14/snippets/compose/claim-alibaba.yaml b/docs/v0.14/snippets/compose/claim-alibaba.yaml
deleted file mode 100644
index 2214b1a1..00000000
--- a/docs/v0.14/snippets/compose/claim-alibaba.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstance
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: alibaba
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.14/snippets/compose/claim-aws.yaml b/docs/v0.14/snippets/compose/claim-aws.yaml
deleted file mode 100644
index 9fb5464b..00000000
--- a/docs/v0.14/snippets/compose/claim-aws.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstance
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: aws
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.14/snippets/compose/claim-azure.yaml b/docs/v0.14/snippets/compose/claim-azure.yaml
deleted file mode 100644
index dbf7f70b..00000000
--- a/docs/v0.14/snippets/compose/claim-azure.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstance
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: azure
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.14/snippets/compose/claim-gcp.yaml b/docs/v0.14/snippets/compose/claim-gcp.yaml
deleted file mode 100644
index 9529c617..00000000
--- a/docs/v0.14/snippets/compose/claim-gcp.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstance
-metadata:
- name: my-db
- namespace: default
-spec:
- parameters:
- storageGB: 20
- compositionSelector:
- matchLabels:
- provider: gcp
- writeConnectionSecretToRef:
- name: db-conn
diff --git a/docs/v0.14/snippets/compose/pod.yaml b/docs/v0.14/snippets/compose/pod.yaml
deleted file mode 100644
index 0b65ecef..00000000
--- a/docs/v0.14/snippets/compose/pod.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
- name: see-db
- namespace: default
-spec:
- containers:
- - name: see-db
- image: postgres:9.6
- command: ['psql']
- args: ['-c', 'SELECT current_database();']
- env:
- - name: PGDATABASE
- value: postgres
- - name: PGHOST
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: endpoint
- - name: PGUSER
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: username
- - name: PGPASSWORD
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: password
- - name: PGPORT
- valueFrom:
- secretKeyRef:
- name: db-conn
- key: port
diff --git a/docs/v0.14/snippets/configure/alibaba/providerconfig.yaml b/docs/v0.14/snippets/configure/alibaba/providerconfig.yaml
deleted file mode 100644
index 1a8bdd95..00000000
--- a/docs/v0.14/snippets/configure/alibaba/providerconfig.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
----
-apiVersion: alibaba.crossplane.io/v1alpha1
-kind: ProviderConfig
-metadata:
- name: default
-spec:
- region: cn-beijing
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: alibaba-creds
- key: credentials
diff --git a/docs/v0.14/snippets/configure/aws/providerconfig.yaml b/docs/v0.14/snippets/configure/aws/providerconfig.yaml
deleted file mode 100644
index b00e6860..00000000
--- a/docs/v0.14/snippets/configure/aws/providerconfig.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
----
-apiVersion: aws.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: default
-spec:
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: aws-creds
- key: key
diff --git a/docs/v0.14/snippets/configure/aws/setup.sh b/docs/v0.14/snippets/configure/aws/setup.sh
deleted file mode 100755
index 59d3523c..00000000
--- a/docs/v0.14/snippets/configure/aws/setup.sh
+++ /dev/null
@@ -1,53 +0,0 @@
-#!/usr/bin/env bash
-#
-# This is a helper script that uses ~/.aws/credentials and ~/.aws/config
-# to build an aws provider object
-#
-# aws configuration (credentials and default region) is required for this
-# script
-
-set -e -o pipefail
-
-# change to script directory
-cd "$( cd "$( dirname "${BASH_SOURCE[0]}")" && pwd )"
-
-aws_profile=
-
-while (( "$#" )); do
- if test -z "$2"; then
- echo "invalid value for $1 option"
- exit -1
- fi
- case "$1" in
- -p|--profile)
- aws_profile=$2
- shift 2
- ;;
- *)
- shift
- ;;
- esac
-done
-
-# make sure kubectl is configured
-kubectl cluster-info > /dev/null || echo "KUBECONFIG is not configured properly"
-
-# if aws_profile is not provided, use default
-aws_profile="${aws_profile:-default}"
-
-# retrieve aws profile credentials, save it under 'default' profile, and base64 encode it
-AWS_CREDS_BASE64=$(echo -e "[default]\naws_access_key_id = $(aws configure get aws_access_key_id --profile $aws_profile)\naws_secret_access_key = $(aws configure get aws_secret_access_key --profile $aws_profile)" | base64 | tr -d "\n")
-
-if test -z "$AWS_CREDS_BASE64"; then
- echo "error reading credentials from aws config"
- exit 1
-fi
-
-echo "apiVersion: v1
-data:
- key: $AWS_CREDS_BASE64
-kind: Secret
-metadata:
- name: aws-creds
- namespace: crossplane-system
-type: Opaque" | kubectl apply -f -
\ No newline at end of file
diff --git a/docs/v0.14/snippets/configure/azure/providerconfig.yaml b/docs/v0.14/snippets/configure/azure/providerconfig.yaml
deleted file mode 100644
index 581e277b..00000000
--- a/docs/v0.14/snippets/configure/azure/providerconfig.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
----
-apiVersion: azure.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: default
-spec:
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: azure-creds
- key: key
diff --git a/docs/v0.14/snippets/configure/gcp/credentials.sh b/docs/v0.14/snippets/configure/gcp/credentials.sh
deleted file mode 100755
index 5d2bfbd3..00000000
--- a/docs/v0.14/snippets/configure/gcp/credentials.sh
+++ /dev/null
@@ -1,84 +0,0 @@
-#!/usr/bin/env bash
-#
-# This is a helper script to create a project, service account, and credentials.json
-# file for use in Crossplane GCP examples
-#
-# gcloud is required for use and must be configured with privileges to perform these tasks
-#
-set -e -o pipefail
-ROLES=(roles/iam.serviceAccountUser roles/cloudsql.admin roles/container.admin roles/redis.admin roles/compute.networkAdmin roles/storage.admin)
-SERVICES=(container.googleapis.com sqladmin.googleapis.com redis.googleapis.com compute.googleapis.com servicenetworking.googleapis.com)
-KEYFILE=crossplane-gcp-provider-key.json
-RAND=$RANDOM
-
-if ! command -v gcloud > /dev/null; then
- echo "Please install gcloud: https://cloud.google.com/sdk/install"
- exit 1
-fi
-
-tab () { sed 's/^/ /' ; }
-# list your organizations (if applicable), take note of the specific organization ID you want to use
-# if you have more than one organization (not common)
-gcloud organizations list --format '[box]' 2>&1 | tab
-
-ORGANIZATION_ID=$(gcloud organizations list --format 'value(ID)' --limit 1)
-read -e -p "Choose an Organization ID [$ORGANIZATION_ID]: " PROMPT_ORGANIZATION_ID
-ORGANIZATION_ID=${PROMPT_ORGANIZATION_ID:-$ORGANIZATION_ID}
-
-gcloud projects list --format '[box]' 2>&1 | tab
-
-# create a new id
-EXAMPLE_PROJECT_ID="crossplane-example-$RAND"
-read -e -p "Choose or create a Project ID [$EXAMPLE_PROJECT_ID]: " PROMPT_EXAMPLE_PROJECT_ID
-EXAMPLE_PROJECT_ID=${PROMPT_EXAMPLE_PROJECT_ID:-$EXAMPLE_PROJECT_ID}
-
-EXAMPLE_PROJECT_ID_FOUND=$(gcloud projects list --filter PROJECT_ID="$EXAMPLE_PROJECT_ID" --format="value(PROJECT_ID)")
-
-if [[ -z $EXAMPLE_PROJECT_ID_FOUND ]]; then
- ACCOUNT_ID=$(gcloud beta billing accounts list --format 'value(ACCOUNT_ID)' --limit 1)
- gcloud beta billing accounts list --format '[box]' 2>&1 | tab
- read -e -p "Choose a Billing Account ID [$ACCOUNT_ID]: " PROMPT_ACCOUNT_ID
- ACCOUNT_ID=${PROMPT_ACCOUNT_ID:-$ACCOUNT_ID}
-
- echo -e "\n* Creating Project $EXAMPLE_PROJECT_ID ... "
- gcloud projects create $EXAMPLE_PROJECT_ID --enable-cloud-apis --organization $ORGANIZATION_ID 2>&1 | tab
-
- echo "* Linking Billing Account $ACCOUNT_ID with Project $EXAMPLE_PROJECT_ID ... "
- gcloud beta billing projects link $EXAMPLE_PROJECT_ID --billing-account=$ACCOUNT_ID 2>&1 | tab
-else
- echo -n "\n* Using Project $EXAMPLE_PROJECT_NAME ... $EXAMPLE_PROJECT_ID"
-fi
-
-# enable Kubernetes API
-for service in "${SERVICES[@]}"; do
- # enable Google API
- echo "* Enabling Service $service on $EXAMPLE_PROJECT_ID"
- gcloud --project $EXAMPLE_PROJECT_ID services enable $service 2>&1 | tab
-done
-
-# create service account
-SA_NAME="example-$RAND"
-echo " * Creating a Service Account"
-gcloud --project $EXAMPLE_PROJECT_ID iam service-accounts create $SA_NAME --display-name "Crossplane Example" 2>&1 | tab
-# export service account email
-EXAMPLE_SA="${SA_NAME}@${EXAMPLE_PROJECT_ID}.iam.gserviceaccount.com"
-
-# assign roles
-for role in "${ROLES[@]}"; do
- echo "* Adding Role $role to $EXAMPLE_SA on $EXAMPLE_PROJECT_ID"
- gcloud projects add-iam-policy-binding $EXAMPLE_PROJECT_ID --member "serviceAccount:$EXAMPLE_SA" --role="$role" 2>&1 | tab
-done
-
-# create service account key (this will create a `crossplane-gcp-provider-key.json` file in your current working directory)
-echo " * Creating $EXAMPLE_SA Key File $KEYFILE"
-gcloud --project $EXAMPLE_PROJECT_ID iam service-accounts keys create --iam-account $EXAMPLE_SA $KEYFILE 2>&1 | tab
-
-cat <
-
-Crossplane presents a declarative management style API that covers a wide range of portable abstractions including databases, message queues, buckets, data pipelines, serverless, clusters, and many more coming. It’s based on the declarative resource model of the popular [Kubernetes](https://github.com/kubernetes/kubernetes) project, and applies many of the lessons learned in container orchestration to multicloud workload and resource orchestration.
-
-Crossplane supports a clean separation of concerns between developers and administrators. Developers define workloads without having to worry about implementation details, environment constraints, and policies. Administrators can define environment specifics, and policies. The separation of concern leads to a higher degree of reusability and reduces complexity.
-
-Crossplane includes a workload scheduler that can factor a number of criteria including capabilities, availability, reliability, cost, regions, and performance while deploying workloads and their resources. The scheduler works alongside specialized resource controllers to ensure policies set by administrators are honored.
-
-## Architecture and Vision
-
-The full architecture and vision of the Crossplane project is described in depth in the [architecture document](https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit?usp=sharing). It is the best place to learn more about how Crossplane fits into the Kubernetes ecosystem, the intended use cases, and comparisons to existing projects.
-
-## Table of Contents
-
-* [Quick Start Guide](quick-start.md)
-* [Getting Started](getting-started.md)
- * [Installing Crossplane](install-crossplane.md)
- * [Adding Your Cloud Providers](cloud-providers.md)
- * [Deploying Workloads](deploy.md)
- * [Running Resources](running-resources.md)
- * [Troubleshooting](troubleshoot.md)
-* [Concepts](concepts.md)
-* [FAQs](faqs.md)
-* [Contributing](contributing.md)
diff --git a/docs/v0.2/cloud-providers.md b/docs/v0.2/cloud-providers.md
deleted file mode 100644
index b08530bf..00000000
--- a/docs/v0.2/cloud-providers.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Adding Your Cloud Providers
-toc: true
-weight: 330
-indent: true
----
-# Adding Your Cloud Providers
-
-In order for Crossplane to be able to manage resources across all your clouds, you will need to add your cloud provider credentials to Crossplane.
-Use the links below for specific instructions to add each of the following cloud providers:
-
-* [Google Cloud Platform (GCP)](cloud-providers/gcp/gcp-provider.md)
-* [Microsoft Azure](cloud-providers/azure/azure-provider.md)
-* [Amazon Web Services (AWS)](cloud-providers/aws/aws-provider.md)
diff --git a/docs/v0.2/cloud-providers/aws/aws-provider.md b/docs/v0.2/cloud-providers/aws/aws-provider.md
deleted file mode 100644
index 505a4a1f..00000000
--- a/docs/v0.2/cloud-providers/aws/aws-provider.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# Adding Amazon Web Services (AWS) to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your AWS account to be ready for integration with Crossplane.
-
-## AWS Credentials
-
-### Option 1: aws Command Line Tool
-
-If you have already installed and configured the [`aws` command line tool](https://aws.amazon.com/cli/), you can simply find your AWS credentials file in `~/.aws/credentials`.
-
-### Option 2: AWS Console in Web Browser
-
-If you do not have the `aws` tool installed, you can alternatively log into the [AWS console](https://aws.amazon.com/console/) and export the credentials.
-The steps to follow below are from the [AWS SDK for GO](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/setting-up.html):
-
-1. Open the IAM console.
-1. On the navigation menu, choose Users.
-1. Choose your IAM user name (not the check box).
-1. Open the Security credentials tab, and then choose Create access key.
-1. To see the new access key, choose Show. Your credentials resemble the following:
- - Access key ID: AKIAIOSFODNN7EXAMPLE
- - Secret access key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
-1. To download the key pair, choose Download .csv file.
-
-Then convert the `*.csv` file to the below format and save it to `~/.aws/credentials`:
-
-```
-[default]
-aws_access_key_id = AKIAIOSFODNN7EXAMPLE
-aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
-```
-
-After the steps above, you should have your AWS credentials stored in `~/.aws/credentials`.
diff --git a/docs/v0.2/cloud-providers/azure/azure-provider.md b/docs/v0.2/cloud-providers/azure/azure-provider.md
deleted file mode 100644
index 24dc425e..00000000
--- a/docs/v0.2/cloud-providers/azure/azure-provider.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# Adding Microsoft Azure to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your Azure account to be ready for integration with Crossplane.
-The general steps we will take are summarized below:
-
-* Create a new service principal (account) that Crossplane will use to create and manage Azure resources
-* Add the required permissions to the account
-* Consent to the permissions using an administrator account
-
-## Preparing your Microsoft Azure Account
-
-In order to manage resources in Azure, you must provide credentials for a Azure service principal that Crossplane can use to authenticate.
-This assumes that you have already [set up the Azure CLI client](https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli?view=azure-cli-latest) with your credentials.
-
-Create a JSON file that contains all the information needed to connect and authenticate to Azure:
-
-```console
-# create service principal with Owner role
-az ad sp create-for-rbac --sdk-auth --role Owner > crossplane-azure-provider-key.json
-```
-
-Take note of the `clientID` value from the JSON file that we just created, and save it to an environment variable:
-
-```console
-export AZURE_CLIENT_ID=
-```
-
-Now add the required permissions to the service principal that will allow it to manage the necessary resources in Azure:
-
-```console
-# add required Azure Active Directory permissions
-az ad app permission add --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --api-permissions 1cda74f2-2616-4834-b122-5cb1b07f8a59=Role 78c8a3c8-a07e-4b9e-af1b-b5ccab50a175=Role
-
-# grant (activate) the permissions
-az ad app permission grant --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --expires never
-```
-
-You might see an error similar to the following, but that is OK, the permissions should have gone through still:
-
-```console
-Operation failed with status: 'Conflict'. Details: 409 Client Error: Conflict for url: https://graph.windows.net/e7985bc4-a3b3-4f37-b9d2-fa256023b1ae/oauth2PermissionGrants?api-version=1.6
-```
-
-After these steps are completed, you should have the following file on your local filesystem:
-
-* `crossplane-azure-provider-key.json`
-
-## Grant Consent to Application Permissions
-
-One more step is required to fully grant the permissions to the new service principal.
-From the Azure Portal, you need to grant consent for the permissions using an admin account.
-The steps to perform this action are listed below:
-
-1. `echo ${AZURE_CLIENT_ID}` and note this ID value
-1. Navigate to the Azure Portal: https://portal.azure.com
-1. Click `Azure Active Directory`, or find it in the `All services` list
-1. Click `App registrations (Preview)`
-1. Click on the application from the list where the application (client) ID matches the value from step 1
-1. Click `API permissions`
-1. Click `Grant admin consent for Default Directory`
-1. Click `Yes`
diff --git a/docs/v0.2/cloud-providers/gcp/gcp-provider.md b/docs/v0.2/cloud-providers/gcp/gcp-provider.md
deleted file mode 100644
index 941f273c..00000000
--- a/docs/v0.2/cloud-providers/gcp/gcp-provider.md
+++ /dev/null
@@ -1,99 +0,0 @@
-# Adding Google Cloud Platform (GCP) to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your GCP account to be ready for integration with Crossplane.
-The general steps we will take are summarized below:
-
-* Create a new example project that all resources will be deployed to
-* Enable required APIs such as Kubernetes and CloudSQL
-* Create a service account that will be used to perform GCP operations from Crossplane
-* Assign necessary roles to the service account
-* Enable billing
-
-For your convenience, the specific steps to accomplish those tasks are provided for you below using either the `gcloud` command line tool, or the GCP console in a web browser.
-You can choose whichever you are more comfortable with.
-
-## Option 1: gcloud Command Line Tool
-
-If you have the `gcloud` tool installed, you can run below commands from the example directory.
-It
-Instructions for installing `gcloud` can be found in the [Google docs](https://cloud.google.com/sdk/install).
-
-```bash
-# list your organizations (if applicable), take note of the specific organization ID you want to use
-# if you have more than one organization (not common)
-gcloud organizations list
-
-# create a new project
-export EXAMPLE_PROJECT_NAME=crossplane-example-123
-gcloud projects create $EXAMPLE_PROJECT_NAME --enable-cloud-apis [--organization ORGANIZATION_ID]
-
-# record the PROJECT_ID value of the newly created project
-export EXAMPLE_PROJECT_ID=$(gcloud projects list --filter NAME=$EXAMPLE_PROJECT_NAME --format="value(PROJECT_ID)")
-
-# enable Kubernetes API
-gcloud --project $EXAMPLE_PROJECT_ID services enable container.googleapis.com
-# enable CloudSQL API
-gcloud --project $EXAMPLE_PROJECT_ID services enable sqladmin.googleapis.com
-
-# create service account
-gcloud --project $EXAMPLE_PROJECT_ID iam service-accounts create example-123 --display-name "Crossplane Example"
-# export service account email
-export EXAMPLE_SA="example-123@$EXAMPLE_PROJECT_ID.iam.gserviceaccount.com"
-
-# create service account key (this will create a `crossplane-gcp-provider-key.json` file in your current working directory)
-gcloud --project $EXAMPLE_PROJECT_ID iam service-accounts keys create --iam-account $EXAMPLE_SA crossplane-gcp-provider-key.json
-
-# assign roles
-gcloud projects add-iam-policy-binding $EXAMPLE_PROJECT_ID --member "serviceAccount:$EXAMPLE_SA" --role="roles/iam.serviceAccountUser"
-gcloud projects add-iam-policy-binding $EXAMPLE_PROJECT_ID --member "serviceAccount:$EXAMPLE_SA" --role="roles/cloudsql.admin"
-gcloud projects add-iam-policy-binding $EXAMPLE_PROJECT_ID --member "serviceAccount:$EXAMPLE_SA" --role="roles/container.admin"
-```
-
-## Option 2: GCP Console in a Web Browser
-
-If you chose to use the `gcloud` tool, you can skip this section entirely.
-
-Create a GCP example project which we will use to host our example GKE cluster, as well as our example CloudSQL instance.
-
-- Login into [GCP Console](https://console.cloud.google.com)
-- Create a new project (either stand alone or under existing organization)
-- Create Example Service Account
- - Navigate to: [Create Service Account](https://console.cloud.google.com/iam-admin/serviceaccounts)
- - `Service Account Name`: type "example"
- - `Service Account ID`: leave auto assigned
- - `Service Account Description`: type "Crossplane example"
- - Click `Create` button
- - This should advance to the next section `2 Grant this service account to project (optional)`
- - We will assign this account 3 roles:
- - `Service Account User`
- - `Cloud SQL Admin`
- - `Kubernetes Engine Admin`
- - Click `Create` button
- - This should advance to the next section `3 Grant users access to this service account (optional)`
- - We don't need to assign any user or admin roles to this account for the example purposes, so you can leave following two fields blank:
- - `Service account users role`
- - `Service account admins role`
- - Next, we will create and export service account key
- - Click `+ Create Key` button.
- - This should open a `Create Key` side panel
- - Select `json` for the Key type (should be selected by default)
- - Click `Create`
- - This should show `Private key saved to your computer` confirmation dialog
- - You also should see `crossplane-example-1234-[suffix].json` file in your browser's Download directory
- - Save (copy or move) this file into example (this) directory, with new name `crossplane-gcp-provider-key.json`
-- Enable `Cloud SQL API`
- - Navigate to [Cloud SQL Admin API](https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview)
- - Click `Enable`
-- Enable `Kubernetes Engine API`
- - Navigate to [Kubernetes Engine API](https://console.developers.google.com/apis/api/container.googleapis.com/overview)
- - Click `Enable`
-
-## Enable Billing
-
-No matter what option you chose to configure the previous steps, you will need to enable billing for your account in order to create and use Kubernetes clusters with GKE.
-
-- Go to [GCP Console](https://console.cloud.google.com)
- - Select example project
- - Click `Enable Billing`
-- Go to [Kubernetes Clusters](https://console.cloud.google.com/kubernetes/list)
- - Click `Enable Billing`
diff --git a/docs/v0.2/concepts.md b/docs/v0.2/concepts.md
deleted file mode 100644
index 3e61c23e..00000000
--- a/docs/v0.2/concepts.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: Concepts
-toc: true
-weight: 410
----
-# Concepts
-
-## Control Plane
-
-Crossplane is an open source multicloud control plane that consists of smart controllers that can work across clouds to enable workload portability, provisioning and full-lifecycle management of infrastructure across a wide range of providers, vendors, regions, and offerings.
-The control plane presents a declarative management style API that covers a wide range of portable abstractions that facilitate these goals across disparate environments, clusters, regions, and clouds.
-Crossplane can be thought of as a higher-order orchestrator across cloud providers.
-For convenience, Crossplane can run directly on-top of an existing Kubernetes cluster without requiring any changes, even though Crossplane does not necessarily schedule or run any containers on the host cluster.
-
-## Resources and Workloads
-
-In Crossplane, a *resource* represents an external piece of infrastructure ranging from low level services like clusters and servers, to higher level infrastructure like databases, message queues, buckets, and more.
-Resources are represented as persistent object within the crossplane, and they typically manage one or more pieces of external infrastructure within a cloud provider or cloud offering.
-Resources can also represent local or in-cluster services.
-
-We model *workloads* as schedulable units of work that the user intends to run on a cloud provider.
-Crossplane will support multiple types of workloads including container and serverless.
-You can think of workloads as units that run **your** code and applications.
-Every type of workload has a different kind of payload.
-For example, a container workload can include a set of objects that will be deployed on a managed Kubernetes cluster, or a reference to helm chart, etc.
-A serverless workload could include a function that will run on a serverless managed service.
-Workloads can contain requirements for where and how the workload can run, including regions, providers, affinity, cost, and others that the scheduler can use when assigning the workload.
-
-
-## Resource Claims and Resource Classes
-
-To support workload portability we expose the concept of a resource claim and a resource class.
-A resource claim is a persistent object that captures the desired configuration of a resource from the perspective of a workload or application.
-Its configuration is cloud-provider and cloud-offering independent and it’s free of implementation and/or environmental details.
-A resource claim can be thought of as a request for an actual resource and is typically created by a developer or application owner.
-
-A resource class is configuration that contains implementation details specific to a certain environment or deployment, and policies related to a kind of resource.
-A ResourceClass acts as a template with implementation details and policy for resources that will be dynamically provisioned by the workload at deployment time.
-A resource class is typically created by an admin or infrastructure owner.
-
-
-## Dynamic and Static Provisioning
-
-A resource can be statically or dynamically provisioned.
-Static provisioning is when an administrator creates the resource manually.
-They set the configuration required to provision and manage the corresponding external resource within a cloud provider or cloud offering.
-Once provisioned, resources are available to be bound to resource claims.
-
-Dynamic provisioning is when an resource claim does not find a matching resource and provisions a new one instead.
-The newly provisioned resource is automatically bound to the resource claim.
-To enable dynamic provisioning the administrator needs to create one or more resource class objects.
-
-## Connection Secrets
-
-Workloads reference all the resources the consume in their `resources` section.
-This helps Crossplane setup connectivity between the workload and resource, and create objects that hold connection information.
-For example, for a database provisioned and managed by Crossplane, a secret will be created that contains a connection string, user and password.
-This secret will be propagated to the target cluster so that it can be used by the workload.
diff --git a/docs/v0.2/contributing.md b/docs/v0.2/contributing.md
deleted file mode 100644
index 356dc430..00000000
--- a/docs/v0.2/contributing.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Contributing
-toc: true
-weight: 710
----
-# Contributing
-
-Crossplane is a community driven project and we welcome contributions.
-That includes [opening issues](https://github.com/crossplaneio/crossplane/issues) for improvements you'd like to see as well as submitting changes to the code base.
-
-For more information about the contribution process, please see the [contribution guide](https://github.com/crossplaneio/crossplane/blob/master/CONTRIBUTING.md).
\ No newline at end of file
diff --git a/docs/v0.2/deploy.md b/docs/v0.2/deploy.md
deleted file mode 100644
index 8f611fe6..00000000
--- a/docs/v0.2/deploy.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: Deploying Workloads
-toc: true
-weight: 340
-indent: true
----
-# Deploying Workloads
-
-## Guides
-
-This section will walk you through how to deploy workloads to various cloud provider environments in a highly portable way.
-For detailed instructions on how to deploy workloads to your cloud provider of choice, please visit the following guides:
-
-* [Deploying a Workload on Google Cloud Platform (GCP)](workloads/gcp/wordpress-gcp.md)
-* [Deploying a Workload on Microsoft Azure](workloads/azure/wordpress-azure.md)
-* [Deploying a Workload on Amazon Web Services](workloads/aws/wordpress-aws.md)
-
-## Workload Overview
-
-A workload is a schedulable unit of work and contains a payload as well as defines its requirements for how the workload should run and what resources it will consume.
-This helps Crossplane setup connectivity between the workload and resources, and make intelligent decisions about where and how to provision and manage the resources in their entirety.
-Crossplane's scheduler is responsible for deploying the workload to a target cluster, which in this guide we will also be using Crossplane to deploy within your chosen cloud provider.
-
-This walkthrough also demonstrates Crossplane's concept of a clean "separation of concerns" between developers and administrators.
-Developers define workloads without having to worry about implementation details, environment constraints, and policies.
-Administrators can define environment specifics, and policies.
-The separation of concern leads to a higher degree of reusability and reduces complexity.
-
-During this walkthrough, we will assume two separate identities:
-
-1. Administrator (cluster or cloud) - responsible for setting up credentials and defining resource classes
-2. Application Owner (developer) - responsible for defining and deploying the application and its dependencies
-
-## Workload Example
-
-### Dependency Resource
-
-Let's take a closer look at a dependency resource that a workload will declare:
-
-```yaml
-## WordPress MySQL Database Instance
-apiVersion: storage.crossplane.io/v1alpha1
-kind: MySQLInstance
-metadata:
- name: demo
- namespace: default
-spec:
- classReference:
- name: standard-mysql
- namespace: crossplane-system
- engineVersion: "5.7"
-```
-
-This will request to create a `MySQLInstance` version 5.7, which will be fulfilled by the `standard-mysql` `ResourceClass`.
-Note that the application developer is not aware of any further specifics when it comes to the `MySQLInstance` beyond their requested engine version.
-This enables highly portable workloads, since the environment specific details of the database are defined by the administrator in a `ResourceClass`.
-
-### Workload
-
-Now let's look at the workload itself, which will reference the dependency resource from above, as well as other information such as the target cluster to deploy to.
-
-```yaml
-## WordPress Workload
-apiVersion: compute.crossplane.io/v1alpha1
-kind: Workload
-metadata:
- name: demo
- namespace: default
-spec:
- resources:
- - name: demo
- secretName: demo
- targetCluster:
- name: demo-gke-cluster
- namespace: crossplane-system
- targetDeployment:
- apiVersion: extensions/v1beta1
- kind: Deployment
- metadata:
- name: wordpress
- labels:
- app: wordpress
- spec:
- selector:
- app: wordpress
- strategy:
- type: Recreate
- template:
- metadata:
- labels:
- app: wordpress
- spec:
- containers:
- - name: wordpress
- image: wordpress:4.6.1-apache
- env:
- - name: WORDPRESS_DB_HOST
- valueFrom:
- secretKeyRef:
- name: demo
- key: endpoint
- - name: WORDPRESS_DB_USER
- valueFrom:
- secretKeyRef:
- name: demo
- key: username
- - name: WORDPRESS_DB_PASSWORD
- valueFrom:
- secretKeyRef:
- name: demo
- key: password
- ports:
- - containerPort: 80
- name: wordpress
- targetNamespace: demo
- targetService:
- apiVersion: v1
- kind: Service
- metadata:
- name: wordpress
- spec:
- ports:
- - port: 80
- selector:
- app: wordpress
- type: LoadBalancer
-```
-
-This `Workload` definition contains multiple components that informs Crossplane on how to deploy the workload and its resources:
-
-- Resources: list of the resources required by the payload application
-- TargetCluster: the cluster where the payload application and all its requirements should be deployed
-- TargetNamespace: the namespace on the target cluster
-- Workload Payload:
- - TargetDeployment
- - TargetService
diff --git a/docs/v0.2/faqs.md b/docs/v0.2/faqs.md
deleted file mode 100644
index f8f7083b..00000000
--- a/docs/v0.2/faqs.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: FAQs
-toc: true
-weight: 610
----
-# Frequently Asked Questions (FAQs)
-
-### Where did the name Crossplane come from?
-
-Crossplane is the fusing of cross-cloud control plane. We wanted to use a noun that refers to the entity responsible for connecting different cloud providers and acts as control plane across them. Cross implies “cross-cloud” and “plane” brings in “control plane”.
-
-### What's up with popsicle?
-
-We believe in a multi-flavor cloud.
-
-### Why is Upbound open sourcing this project? What are Upbound’s monetization plans?
-
-Upbound’s mission is to create a more open cloud-computing platform, with more choice and less lock-in. We believe the Crossplane as an important step towards this vision and that it’s going to take a village to solve this problem. We believe that multicloud control plane is a new category of open source software, and it will ultimately disrupt closed source and proprietary models. Upbound aspires to be a commercial provider of a more open cloud-computing platform.
-
-### What kind of governance model will be used for Crossplane?
-
-Crossplane will be an independent project and we plan on making a community driven project and not a vendor driven project. It will have an independent brand, github organization, and an open governance model. It will not be tied to single organization or individual.
-
-### Will Crossplane be donated to an open source foundation?
-
-We don’t know yet. We are open to doing so but we’d like to revisit this after the project has gotten some end-user community traction.
-
-### Does using multicloud mean you will use the lowest common denominator across clouds?
-
-Not necessarily. There are numerous best of breed cloud offerings that run on multiple clouds. For example, CockroachDB and ElasticSearch are world class implementations of platform software and run well on cloud providers. They compete with managed services offered by a cloud provider. We believe that by having an open control plane for them to integrate with, and providing a common API, CLI and UI for all of these services, that more of these offerings will exist and get first-class experience in the cloud.
-
-### How are resources and claims related to PersistentVolumes in Kubernetes?
-
-We modeled resource claims and classes after PersistentVolumes and PersistentVolumeClaims in Kubernetes. We believe many of the lessons learned from managing volumes in Kubernetes apply to managing resources within cloud providers. One notable exception is that we avoided creating a plugin model within Crossplane.
-
-### How is workload scheduling related to pod scheduling in Kubernetes?
-
-We modeled workload scheduling after the Pod scheduler in Kubernetes. We believe many of the lessons learned from Pod scheduling apply to scheduling workloads across cloud providers.
-
-### Can I use Crossplane to consistently provision and manage multiple Kubernetes clusters?
-
-Crossplane includes a portable API for Kubernetes clusters that will include common configuration including node pools, auto-scalers, taints, admission controllers, etc. These will be applied to the specific implementations within the cloud providers like EKS, GKE and AKS. We see the Kubernetes Cluster API to be something that will be used by administrators and not developers.
-
-### Other attempts at building a higher level API on-top of a multitude of inconsistent lower level APIs have not been successful, will Crossplane not have the same issues?
-
-We agree that building a consistent higher level API on top of multitudes of inconsistent lower level API's is well known to be fraught with peril (e.g. dumbing down to lowest common denominator, or resulting in so loosely defined an API as to be impossible to practically develop real portable applications on top of it).
-
-Crossplane follows a different approach here. The portable API extracts the pieces that are common across all implementations, and from the perspective of the workload. The rest of the implementation details are captured in full fidelity by the admin in resource classes. The combination of the two is what results in full configuration that can be deployed. We believe this to be a reasonable tradeoff that avoids the dumbing down to lowest common denominator problem, while still enabling portability.
diff --git a/docs/v0.2/getting-started.md b/docs/v0.2/getting-started.md
deleted file mode 100644
index 78c9241f..00000000
--- a/docs/v0.2/getting-started.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: Getting Started
-toc: true
-weight: 310
----
-# Getting Started
-
-* [Installing Crossplane](install-crossplane.md)
-* [Adding Your Cloud Providers](cloud-providers.md)
-* [Deploying Workloads](deploy.md)
-* [Running Resources](running-resources.md)
-* [Troubleshooting](troubleshoot.md)
\ No newline at end of file
diff --git a/docs/v0.2/install-crossplane.md b/docs/v0.2/install-crossplane.md
deleted file mode 100644
index 9d111a25..00000000
--- a/docs/v0.2/install-crossplane.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: Install
-toc: true
-weight: 320
-indent: true
----
-# Installing Crossplane
-
-Crossplane can be easily installed into any existing Kubernetes cluster using the regularly published Helm chart.
-The Helm chart contains all the custom resources and controllers needed to deploy and configure Crossplane.
-
-## Pre-requisites
-
-* [Kubernetes cluster](https://kubernetes.io/docs/setup/)
- * For example [Minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/), minimum version `v0.28+`
-* [Helm](https://docs.helm.sh/using_helm/), minimum version `v2.9.1+`.
-
-## Installation
-
-Helm charts for Crossplane are currently published to the `alpha` and `master` channels.
-In the future, `beta` and `stable` will also be available.
-
-### Alpha
-
-The alpha channel is the most recent release of Crossplane that is considered ready for testing by the community.
-
-```console
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-### Master
-
-The `master` channel contains the latest commits, with all automated tests passing.
-`master` is subject to instability, incompatibility, and features may be added or removed without much prior notice.
-It is recommended to use one of the more stable channels, but if you want the absolute newest Crossplane installed, then you can use the `master` channel.
-
-To install the Helm chart from master, you will need to pass the specific version returned by the `search` command:
-
-```console
-helm repo add crossplane-master https://charts.crossplane.io/master/
-helm search crossplane
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version
-```
-
-For example:
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version 0.0.0-249.637ccf9
-```
-
-## Uninstalling the Chart
-
-To uninstall/delete the `crossplane` deployment:
-
-```console
-helm delete --purge crossplane
-```
-
-That command removes all Kubernetes components associated with Crossplane, including all the custom resources and controllers.
-
-## Configuration
-
-The following tables lists the configurable parameters of the Crossplane chart and their default values.
-
-| Parameter | Description | Default |
-| ------------------------- | --------------------------------------------------------------- | ------------------------------------------------------ |
-| `image.repository` | Image | `crossplane/crossplane` |
-| `image.tag` | Image tag | `master` |
-| `image.pullPolicy` | Image pull policy | `Always` |
-| `imagePullSecrets` | Names of image pull secrets to use | `dockerhub` |
-| `replicas` | The number of replicas to run for the Crossplane operator | `1` |
-| `deploymentStrategy` | The deployment strategy for the Crossplane operator | `RollingUpdate` |
-
-### Command Line
-
-You can pass the settings with helm command line parameters.
-Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`.
-For example, the following command will install Crossplane with an image pull policy of `IfNotPresent`.
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane --set image.pullPolicy=IfNotPresent
-```
-
-### Settings File
-
-Alternatively, a yaml file that specifies the values for the above parameters (`values.yaml`) can be provided while installing the chart.
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane -f values.yaml
-```
-
-Here are the sample settings to get you started.
-
-```yaml
-replicas: 1
-
-deploymentStrategy: RollingUpdate
-
-image:
- repository: crossplane/crossplane
- tag: master
- pullPolicy: Always
-
-imagePullSecrets:
-- dockerhub
-```
diff --git a/docs/v0.2/media/arch.png b/docs/v0.2/media/arch.png
deleted file mode 100644
index 8205e62e..00000000
Binary files a/docs/v0.2/media/arch.png and /dev/null differ
diff --git a/docs/v0.2/media/banner.png b/docs/v0.2/media/banner.png
deleted file mode 100644
index 0a495e1d..00000000
Binary files a/docs/v0.2/media/banner.png and /dev/null differ
diff --git a/docs/v0.2/media/logo.svg b/docs/v0.2/media/logo.svg
deleted file mode 100644
index 3af90369..00000000
--- a/docs/v0.2/media/logo.svg
+++ /dev/null
@@ -1,310 +0,0 @@
-
-
-
diff --git a/docs/v0.2/postgresql.md b/docs/v0.2/postgresql.md
deleted file mode 100644
index 41436fb9..00000000
--- a/docs/v0.2/postgresql.md
+++ /dev/null
@@ -1,133 +0,0 @@
-# Deploying PostgreSQL Databases
-
-This user guide will walk you through how to deploy a PostgreSQL database across many different environments with a focus on portability and reusability.
-The database will be dynamically provisioned in the cloud provider of your choice at the request of the application developer via a `ResourceClaim` and created with the environment specific information that the administrator providers in a `ResourceClass`.
-The commands in this guide assume you are running from a terminal/shell at the root of the [Crossplane repo](https://github.com/crossplaneio/crossplane/).
-
-## Install Crossplane
-
-The first step will be to install Crossplane by following the steps in the [Crossplane install guide](install-crossplane.md).
-
-## Add Cloud Provider
-
-Next you'll need to add your cloud provider credentials to Crossplane using [these provider specific steps](cloud-providers.md).
-
-After those steps are completed, you should have the cloud provider credentials saved in a file on your local filesystem, for which the path will be stored in the environment variable `PROVIDER_KEY_FILE` in the next section.
-
-## Set Environment Variables
-
-After your cloud provider credentials have been created/added, let's set the following environment variables that have different values for each provider,
-but will allow the rest of the steps to be consistent across all of them.
-You only need to set the variables for your chosen cloud provider, you can ignore the other ones.
-
-### Google Cloud Platform (GCP)
-
-```console
-export PROVIDER=GCP
-export provider=gcp
-export PROVIDER_KEY_FILE=crossplane-${provider}-provider-key.json
-export DATABASE_TYPE=cloudsqlinstances
-export versionfield=databaseVersion
-```
-
-### Microsoft Azure
-
-```console
-export PROVIDER=AZURE
-export provider=azure
-export PROVIDER_KEY_FILE=crossplane-${provider}-provider-key.json
-export DATABASE_TYPE=postgresqlservers
-export versionfield=version
-```
-
-### Amazon Web Services (AWS)
-
-```console
-export PROVIDER=AWS
-export provider=aws
-export PROVIDER_KEY_FILE=~/.aws/credentials
-export DATABASE_TYPE=rdsinstances
-export versionfield=engineVersion
-```
-
-## Create a PostgreSQL Resource Class
-
-Let's create a `ResourceClass` that acts as a "blueprint" that contains the environment specific details of how a general request from the application to create a PostgreSQL database should be fulfilled.
-This is a task that the administrator should complete, since they will have the knowledge and privileges for the specific environment details.
-
-```console
-sed "s/BASE64ENCODED_${PROVIDER}_PROVIDER_CREDS/`cat ${PROVIDER_KEY_FILE}|base64|tr -d '\n'`/g;" cluster/examples/database/${provider}/postgresql/provider.yaml | kubectl create -f -
-kubectl create -f cluster/examples/database/${provider}/postgresql/resource-class.yaml
-```
-
-## Create a PostgreSQL Resource Claim
-
-After the administrator has created the PostgreSQL `ResourceClass` "blueprint", the application developer is now free to create a PostgreSQL `ResourceClaim`.
-This is a general request for a PostgreSQL database to be used by their application and it requires no environment specific information, allowing our applications to express their need for a database in a very portable way.
-
-```console
-kubectl create namespace demo
-kubectl -n demo create -f cluster/examples/database/${provider}/postgresql/resource-claim.yaml
-```
-
-## Check Status of PostgreSQL Provisioning
-
-We can follow along with the status of the provisioning of the database resource with the below commands.
-Note that the first command gives us the status of the `ResourceClaim` (general request for a database by the application),
-and the second command gives the status of the environment specific database resource that Crossplane is provisioning using the `ResourceClass` "blueprint".
-
-```console
-kubectl -n demo get postgresqlinstance -o custom-columns=NAME:.metadata.name,STATUS:.status.bindingPhase,CLASS:.spec.classReference.name,VERSION:.spec.engineVersion,AGE:.metadata.creationTimestamp
-kubectl -n crossplane-system get ${DATABASE_TYPE} -o custom-columns=NAME:.metadata.name,STATUS:.status.bindingPhase,STATE:.status.state,CLASS:.spec.classRef.name,VERSION:.spec.${versionfield},AGE:.metadata.creationTimestamp
-```
-
-## Access the PostgreSQL Database
-
-Once the dynamic provisioning process has finished creating and preparing the database, the status output will look similar to the following:
-
-```console
-> kubectl -n demo get postgresqlinstance -o custom-columns=NAME:.metadata.name,STATUS:.status.bindingPhase,CLASS:.spec.classReference.name,VERSION:.spec.engineVersion,AGE:.metadata.creationTimestamp
-NAME STATUS CLASS VERSION AGE
-cloud-postgresql-claim Bound cloud-postgresql 9.6 2018-12-23T04:00:11Z
-
-> kubectl -n crossplane-system get ${DATABASE_TYPE} -o custom-columns=NAME:.metadata.name,STATUS:.status.bindingPhase,STATE:.status.state,CLASS:.spec.classRef.name,VERSION:.spec.${versionfield},AGE:.metadata.creationTimestamp
-NAME STATUS STATE CLASS VERSION AGE
-postgresql-3ef70bf9-0667-11e9-99e1-080027cf2340 Bound Ready cloud-postgresql 9.6 2018-12-23T04:00:12Z
-```
-
-Note that both the general `postgresqlinstance` `ResourceClaim` and the cloud provider specific PostgreSQL database have the `Bound` status, meaning the dynamic provisioning is done and the resource is ready for consumption.
-
-The connection information will be stored in a secret with the same name as the `ResourceClaim`.
-Since the secret is base64 encoded, we'll need to decode its fields to view them in plain-text.
-To view all the connection information in plain-text, run the following command:
-
-```console
-for r in endpoint username password; do echo -n "${r}: "; kubectl -n demo get secret cloud-postgresql-claim -o jsonpath='{.data.'"${r}"'}' | base64 -D; echo; done
-```
-
-A workload or pod manifest will usually reference this connection information through injecting the secret contents into environment variables in the manifest.
-You can see this in action as an example in the [Azure Workload example](https://github.com/crossplaneio/crossplane/blob/release-0.1/cluster/examples/workloads/wordpress-azure/workload.yaml#L47-L62).
-
-More information about consuming secrets from manifests can be found in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/secret/#use-cases).
-
-## Clean-up
-
-When you are finished with the PostgreSQL instance from this guide, you can clean up all the resources by running the below commands.
-
-First, delete the resource claim, which will start the operation of deleting the PostgreSQL database from your cloud provider.
-
-```console
-kubectl -n demo delete -f cluster/examples/database/${provider}/postgresql/resource-claim.yaml
-```
-
-Next. delete the `ResourceClass` "blueprint":
-
-```console
-kubectl delete -f cluster/examples/database/${provider}/postgresql/resource-class.yaml
-```
-
-Finally, delete the cloud provider credentials from your local environment:
-
-```console
-kubectl delete -f cluster/examples/database/${provider}/postgresql/provider.yaml
-```
diff --git a/docs/v0.2/quick-start.md b/docs/v0.2/quick-start.md
deleted file mode 100644
index 65e3bbf4..00000000
--- a/docs/v0.2/quick-start.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Quick Start Guide
-toc: true
-weight: 210
----
-# Quick Start Guide
-
-This quick start will demonstrate using Crossplane to deploy a portable stateful workload in the cloud provider of your choice.
-It will first dynamically provision a Kubernetes cluster within the cloud provider environment, followed by a stateful application and its database to the same environment.
-The database will also be dynamically provisioned using a managed service hosted by the cloud provider.
-The Workload will be deployed into the target Kubernetes cluster, and be configured to consume the database resource in a completely portable way.
-
-The general steps for this example are as follows:
-
-1. Install Crossplane so it is ready to manage resources on your behalf: [Install Crossplane](install-crossplane.md)
-1. Set up a cloud provider and add it to Crossplane: [Adding a Cloud Provider](cloud-providers.md)
-1. Deploy a portable workload to the cloud provider: [Deploying Workloads](deploy.md)
diff --git a/docs/v0.2/related-projects.md b/docs/v0.2/related-projects.md
deleted file mode 100644
index 273d590c..00000000
--- a/docs/v0.2/related-projects.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: Related Projects
-toc: true
-weight: 510
----
-# Related Projects
-
-While there are many projects that address similar issues, none of them encapsulate the full use case that Crossplane addresses. This list is not exhaustive and is not meant to provide a deep analysis of the following projects, but instead to motivate why Crossplane was created.
-
-## Open Service Broker and Service Catalog
-
-The [Open Service Broker](https://www.openservicebrokerapi.org/) and the [Kubernetes Service Catalog](https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/) are able to dynamically provision managed services in multiple cloud providers from Kubernetes. As a result it shares similar goals with Crossplane. However, service broker is not designed for workload portability, does not have a good separation of concern, and does not offer any integration with workload and resource scheduling. Service brokers can not span multiple cloud providers at once.
-
-## Kubernetes Federation
-
-The [federation-v2](https://github.com/kubernetes-sigs/federation-v2) project offers a single control plane that can span multiple Kubernetes clusters. It’s being incubated in SIG-multicluster. Crossplane shares some of the goals of managing multiple Kubernetes clusters and also the core principles of creating a higher level control plane, scheduler and controllers that span clusters. While the federation-v2 project is scoped to just Kubernetes clusters, Crossplane supports non-container workloads, and orchestrating resources that run as managed services including databases, message queues, buckets, and others. The federation effort focuses on defining Kubernetes objects that can be templatized, and propagated to other Kubernetes clusters. Crossplane focuses on defining portable workload abstractions across cloud providers and offerings. We have considered taking a dependency on the federation-v2 work within Crossplane, although it’s not clear at this point if this would accelerate the Crossplane effort.
-
-## AWS Service Operator
-
-The [AWS Service Operator](https://github.com/awslabs/aws-service-operator) is a recent project that implements a set of Kubernetes controllers that are able to provision managed services in AWS. It defines a set of CRDs for managed services like DynamoDB, and controllers that can provision them via AWS CloudFormation. It is similar to Crossplane in that it can provision managed services in AWS. Crossplane goes a lot further by offering workload portability across cloud multiple cloud providers, separation of concern, and a scheduler for workload and resources.
-
-## AWS CloudFormation, GCP Deployment Manager, and Others
-
-These products offer a declarative model for deploying and provisioning infrastructure in each of the respective cloud providers. They only work for one cloud provider and do not solve the problem of workload portability. These products are generally closed source, and offer little or no extensibility points. We have considered using some of these products as a way to implement resource controllers in Crossplane.
-
-## Terraform
-
-[Terraform](https://www.terraform.io/) is a popular tool for provisioning infrastructure across cloud providers. It offers a declarative configuration language with support for templating, composability, referential integrity and dependency management. Terraform can dynamically provision infrastructure and perform changes when the tool is run by a human. Unlike Crossplane, Terraform does not support workload portability across cloud providers, and does not have any active controllers that can react to failures, or make changes to running infrastructure without human intervention. Terraform attempts to solve multicloud at the tool level, while Crossplane is at the API and control plane level. Terraform is open source under a MPL license, and follows an open core business model, with a number of its features closed source. We are evaluating whether we can use Terraform to accelerate the development of resource controllers in Crossplane.
-
-## Pulumi
-
-[Pulumi](https://www.pulumi.com/) is a product that is based on terraform and uses most of its providers. Instead of using a configuration language, Pulumi uses popular programming languages like Typescript to capture the configuration. At runtime, Pulumi generates a DAG of resources just like terraform and applies it to cloud providers. Pulumi has an early model for workload portability that is implemented using language abstractions. Unlike Crossplane, it does not have any active controllers that can react to failures, or make changes to running infrastructure without human intervention, nor does it support workload scheduling. Pulumi attempts to solve multicloud scenarios at the language level, while Crossplane is at the API and control plane level. Pulumi is open source under a APL2 license but a number of features require using their SaaS offering.
\ No newline at end of file
diff --git a/docs/v0.2/running-resources.md b/docs/v0.2/running-resources.md
deleted file mode 100644
index 47cc3a68..00000000
--- a/docs/v0.2/running-resources.md
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: Running Resources
-toc: true
-weight: 350
-indent: true
----
-# Running Resources
-
-Crossplane enables you to run a number of different resources in a portable and cloud agnostic way, allowing you to author an application that runs without modifications on multiple environments and cloud providers.
-A single Crossplane enables the provisioning and full-lifecycle management of infrastructure across a wide range of providers, vendors, regions, and offerings.
-
-## Guides
-
-The list below contains some direct links to user guides that will walk you through how to deploy specific types of resources into your environments.
-
-* [Workload user guides - WordPress application, MySQL database, Kubernetes cluster](deploy.md#guides)
-* [PostgreSQL database](postgresql.md)
-
-## Running Databases
-
-Database managed services can be statically or dynamically provisioned by Crossplane in AWS, GCP, and Azure.
-An application developer simply has to specify their general need for a database such as MySQL, without any specific knowledge of what environment that database will run in or even what specific type of database it will be at runtime.
-The following sample is all the application developer needs to specify in order to get the correct MySQL database (CloudSQL, RDS, Azure MySQL) provisioned and configured for their application:
-
-```yaml
-apiVersion: storage.crossplane.io/v1alpha1
-kind: MySQLInstance
-metadata:
- name: demo-mysql
-spec:
- classReference:
- name: standard-mysql
- namespace: crossplane-system
- engineVersion: "5.7"
-```
-
-The cluster administrator specifies a resource class that acts as a template with the implementation details and policy specific to the environment that the generic MySQL resource is being deployed to.
-This enables the database to be dynamically provisioned at deployment time without the application developer needing to know any of the details, which promotes portability and reusability.
-An example resource class that will provision a CloudSQL instance in GCP in order to fulfill the applications general MySQL requirement would look like this:
-
-```yaml
-apiVersion: core.crossplane.io/v1alpha1
-kind: ResourceClass
-metadata:
- name: standard-mysql
- namespace: crossplane-system
-parameters:
- tier: db-n1-standard-1
- region: us-west2
- storageType: PD_SSD
-provisioner: cloudsqlinstance.database.gcp.crossplane.io/v1alpha1
-providerRef:
- name: gcp-provider
-reclaimPolicy: Delete
-```
-
-## Running Kubernetes Clusters
-
-Kubernetes clusters are another type of resource that can be dynamically provisioned using a generic resource claim by the application developer and an environment specific resource class by the cluster administrator.
-
-Generic Kubernetes cluster resource claim created by the application developer:
-
-```yaml
-apiVersion: compute.crossplane.io/v1alpha1
-kind: KubernetesCluster
-metadata:
- name: demo-cluster
- namespace: crossplane-system
-spec:
- classReference:
- name: standard-cluster
- namespace: crossplane-system
-```
-
-Environment specific GKE cluster resource class created by the admin:
-
-```yaml
-apiVersion: core.crossplane.io/v1alpha1
-kind: ResourceClass
-metadata:
- name: standard-cluster
- namespace: crossplane-system
-parameters:
- machineType: n1-standard-1
- numNodes: "1"
- zone: us-central1-a
-provisioner: gkecluster.compute.gcp.crossplane.io/v1alpha1
-providerRef:
- name: gcp-provider
-reclaimPolicy: Delete
-```
-
-## Future support
-
-As the project continues to grow with support from the community, support for more resources will be added.
-This includes all of the essential managed services from cloud providers as well as local or in-cluster services that deploy using the operator pattern.
-Crossplane will provide support for serverless, databases, object storage (buckets), analytics, big data, AI, ML, message queues, key-value stores, and more.
\ No newline at end of file
diff --git a/docs/v0.2/troubleshoot.md b/docs/v0.2/troubleshoot.md
deleted file mode 100644
index 05f294f7..00000000
--- a/docs/v0.2/troubleshoot.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: Troubleshooting
-toc: true
-weight: 360
-indent: true
----
-# Troubleshooting
-
-* [Crossplane Logs](#crossplane-logs)
-* [Resource Status and Conditions](#resource-status-and-conditions)
-* [Pausing Crossplane](#pausing-crossplane)
-* [Deleting a Resource Hangs](#deleting-a-resource-hangs)
-
-## Crossplane Logs
-
-The first place to look to get more information or investigate a failure would be in the Crossplane pod logs, which should be running in the `crossplane-system` namespace.
-To get the current Crossplane logs, run the following:
-
-```console
-kubectl -n crossplane-system logs $(kubectl -n crossplane-system get pod -l app=crossplane -o jsonpath='{.items[0].metadata.name}')
-```
-
-## Resource Status and Conditions
-
-All of the objects that represent managed resources such as databases, clusters, etc. have a `status` section that can give good insight into the current state of that particular object.
-In general, simply getting the `yaml` output of a Crossplane object will give insightful information about its condition:
-
-```console
-kubetl get -o yaml
-```
-
-For example, to get complete information about an Azure AKS cluster object, the following command will generate the below sample (truncated) output:
-
-```console
-> kubectl -n crossplane-system get akscluster -o yaml
-...
- status:
- Conditions:
- - LastTransitionTime: 2018-12-04T08:03:01Z
- Message: 'failed to start create operation for AKS cluster aks-demo-cluster:
- containerservice.ManagedClustersClient#CreateOrUpdate: Failure sending request:
- StatusCode=400 -- Please see https://aka.ms/acs-sp-help for more details."'
- Reason: failed to create cluster
- Status: "False"
- Type: Failed
- - LastTransitionTime: 2018-12-04T08:03:14Z
- Message: ""
- Reason: ""
- Status: "False"
- Type: Creating
- - LastTransitionTime: 2018-12-04T09:59:43Z
- Message: ""
- Reason: ""
- Status: "True"
- Type: Ready
- bindingPhase: Bound
- endpoint: crossplane-aks-14af6e93.hcp.centralus.azmk8s.io
- state: Succeeded
-```
-
-We can see a few conditions in that AKS cluster's history.
-It first encountered a failure, then it moved into the `Creating` state, then it finally became `Ready` later on.
-Conditions that have `Status: "True"` are currently active, while conditions with `Status: "False"` happened in the past, but are no longer happening currently.
-
-## Pausing Crossplane
-
-Sometimes, it can be useful to pause Crossplane if you want to stop it from actively attempting to manage your resources, for instance if you have encountered a bug.
-To pause Crossplane without deleting all of its resources, run the following command to simply scale down its deployment:
-
-```console
-kubectl -n crossplane-system scale --replicas=0 deployment/crossplane
-```
-
-Once you have been able to rectify the problem or smooth things out, you can unpause Crossplane simply by scaling its deployment back up:
-
-```console
-kubectl -n crossplane-system scale --replicas=1 deployment/crossplane
-```
-
-## Deleting a Resource Hangs
-
-The resources that Crossplane manages will automatically be cleaned up so as not to leave anything running behind.
-This is accomplished by using finalizers, but in certain scenarios, the finalizer can prevent the Kubernetes object from getting deleted.
-
-To deal with this, we essentially want to patch the object to remove its finalizer, which will then allow it to be deleted completely.
-Note that this won't necessarily delete the external resource that Crossplane was managing, so you will want to go to your cloud provider's console and look there for any lingering resources to clean up.
-
-In general, a finalizer can be removed from an object with this command:
-
-```console
-kubectl patch -p '{"metadata":{"finalizers": []}}' --type=merge
-```
-
-For example, for a Workload object (`workloads.compute.crossplane.io`) named `test-workload`, you can remove its finalizer with:
-
-```console
-kubectl patch workloads.compute.crossplane.io test-workload -p '{"metadata":{"finalizers": []}}' --type=merge
-```
diff --git a/docs/v0.2/workloads/aws/wordpress-aws.md b/docs/v0.2/workloads/aws/wordpress-aws.md
deleted file mode 100644
index 531d0c38..00000000
--- a/docs/v0.2/workloads/aws/wordpress-aws.md
+++ /dev/null
@@ -1,250 +0,0 @@
-# Deploying a WordPress Workload on AWS
-
-This guide walks you through how to use Crossplane to deploy a stateful workload in a portable way on AWS.
-The following components are dynamically provisioned and configured during this guide:
-
-* An EKS Kubernetes cluster
-* An RDS MySQL database
-* A sample WordPress application
-
-## Pre-requisites
-
-Before starting this guide, you should have already [configured your AWS account](../../cloud-providers/aws/aws-provider.md) for use with Crossplane.
-
-You should also have an AWS credentials file at `~/.aws/credentials` already on your local filesystem.
-
-## Administrator Tasks
-
-This section covers tasks performed by the cluster or cloud administrator. These include:
-
-- Importing AWS provider credentials
-- Defining resource classes for cluster and database resources
-- Creating all EKS pre-requisite artifacts
-- Creating a target EKS cluster (using dynamic provisioning with the cluster resource class)
-
-> Note: All artifacts created by the administrator are stored/hosted in the `crossplane-system` namespace, which has
-restricted access, i.e. `Application Owner(s)` should not have access to them.
-
-To successfully follow this guide, make sure your `kubectl` context points to the cluster where `Crossplane` was deployed.
-
-### Configuring EKS Cluster Pre-requisites
-
-EKS cluster deployment is somewhat of an arduous process right now.
-A number of artifacts and configurations need to be set up within the AWS console prior to provisioning an EKS cluster using Crossplane.
-We anticipate that AWS will make improvements on this user experience in the near future.
-
-#### Create a named keypair
-1. Use an existing ec2 key pair or create a new key pair by following [these steps](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)
-1. Export the key pair name as the EKS_WORKER_KEY_NAME environment variable
- ```console
- export EKS_WORKER_KEY_NAME=replace-with-key-name
- ```
-
-#### Create your Amazon EKS Service Role
-[Original Source Guide](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)
-
-1. Open the [IAM console](https://console.aws.amazon.com/iam/).
-1. Choose Roles, then Create role.
-1. Choose EKS from the list of services, then "Allows EKS to manage clusters on your behalf", then Next: Permissions.
-1. Choose Next: Tags.
-1. Choose Next: Review.
-1. For the Role name, enter a unique name for your role, such as eksServiceRole, then choose Create role.
-1. Set the EKS_ROLE_ARN environment variable to the name of your role ARN
- ```console
- export EKS_ROLE_ARN=replace-with-full-role-arn
- ```
-
-#### Create your Amazon EKS Cluster VPC
-[Original Source Guide](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)
-
-1. Open the [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation).
-1. From the navigation bar, select a Region that supports Amazon EKS.
- > Note: Amazon EKS is available in the following Regions at this time:
- > * US West (Oregon) (us-west-2)
- > * US East (N. Virginia) (us-east-1)
- > * EU (Ireland) (eu-west-1)
-
-1. Set the REGION environment variable to your region
- ```console
- export REGION=replace-with-region
- ```
-
-1. Choose Create stack.
-1. For Choose a template, select Specify an Amazon S3 template URL.
-1. Paste the following URL into the text area and choose Next.
- ```
- https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2018-11-07/amazon-eks-vpc-sample.yaml
- ```
-1. On the Specify Details page, fill out the parameters accordingly, and choose Next.
- ```
- * Stack name: Choose a stack name for your AWS CloudFormation stack. For example, you can call it eks-vpc.
- * VpcBlock: Choose a CIDR range for your VPC. You may leave the default value.
- * Subnet01Block: Choose a CIDR range for subnet 1. You may leave the default value.
- * Subnet02Block: Choose a CIDR range for subnet 2. You may leave the default value.
- * Subnet03Block: Choose a CIDR range for subnet 3. You may leave the default value.
- ```
-1. (Optional) On the Options page, tag your stack resources and choose Next.
-1. On the Review page, choose Create.
-1. When your stack is created, select it in the console and choose Outputs.
-1. Using values from outputs, export the following environment variables.
- ```console
- export EKS_VPC=replace-with-eks-vpcId
- export EKS_SUBNETS=replace-with-eks-subnetIds01,replace-with-eks-subnetIds02,replace-with-eks-subnetIds03
- export EKS_SECURITY_GROUP=replace-with-eks-securityGroupId
- ```
-
-#### Create an RDS subnet group
-1. Navigate to the aws console in same region as the EKS clsuter
-1. Navigate to `RDS` service
-1. Navigate to `Subnet groups` in left hand pane
-1. Click `Create DB Subnet Group`
-1. Name your subnet i.e. `eks-db-subnets`
-1. Select the VPC created in the EKS VPC step
-1. Click `Add all subnets related to this VPC`
-1. Click Create
-1. Export the db subnet group name
- ```console
- export RDS_SUBNET_GROUP_NAME=replace-with-DBSubnetgroup-name
- ```
-
-#### Create an RDS Security Group (example only)
-
-> Note: This will make your RDS instance visible from anywhere on the internet.
-This is for **EXAMPLE PURPOSES ONLY** and is **NOT RECOMMENDED** for production system.
-
-1. Navigate to ec2 in the same region as the EKS cluster
-1. Click: security groups
-1. Click `Create Security Group`
-1. Name it, ex. `demo-rds-public-visibility`
-1. Give it a description
-1. Select the same VPC as the EKS cluster.
-1. On the Inbound Rules tab, choose Edit.
- - For Type, choose `MYSQL/Aurora`
- - For Port Range, type `3306`
- - For Source, choose `Anywhere` from drop down or type: `0.0.0.0/0`
-1. Choose Add another rule if you need to add more IP addresses or different port ranges.
-1. Click: Create
-1. Export the security group id
- ```console
- export RDS_SECURITY_GROUP=replace-with-security-group-id
- ```
-
-
-### Deploy all Workload Resources
-
-Now deploy all the workload resources, including the RDS database and EKS cluster with the following commands:
-
-Create provider:
-```console
-sed -e "s|BASE64ENCODED_AWS_PROVIDER_CREDS|`cat ~/.aws/credentials|base64|tr -d '\n'`|g;s|EKS_WORKER_KEY_NAME|$EKS_WORKER_KEY_NAME|g;s|EKS_ROLE_ARN|$EKS_ROLE_ARN|g;s|REGION|$REGION|g;s|EKS_VPC|$EKS_VPC|g;s|EKS_SUBNETS|$EKS_SUBNETS|g;s|EKS_SECURITY_GROUP|$EKS_SECURITY_GROUP|g;s|RDS_SUBNET_GROUP_NAME|$RDS_SUBNET_GROUP_NAME|g;s|RDS_SECURITY_GROUP|$RDS_SECURITY_GROUP|g" cluster/examples/workloads/wordpress-aws/provider.yaml | kubectl create -f -
-```
-
-Create cluster:
-```console
-kubectl create -f cluster/examples/workloads/wordpress-aws/cluster.yaml
-```
-
-It will take a while (~15 minutes) for the EKS cluster to be deployed and become available.
-You can keep an eye on its status with the following command:
-
-```console
-kubectl -n crossplane-system get ekscluster -o custom-columns=NAME:.metadata.name,STATE:.status.state,CLUSTERNAME:.status.clusterName,ENDPOINT:.status.endpoint,LOCATION:.spec.location,CLUSTERCLASS:.spec.classRef.name,RECLAIMPOLICY:.spec.reclaimPolicy
-```
-
-Once the cluster is done provisioning, you should see output similar to the following
-> Note: the `STATE` field is `ACTIVE` and the `ENDPOINT` field has a value):
-
-```console
-NAME STATE CLUSTERNAME ENDPOINT LOCATION CLUSTERCLASS RECLAIMPOLICY
-eks-8f1f32c7-f6b4-11e8-844c-025000000001 ACTIVE https://B922855C944FC0567E9050FCD75B6AE5.yl4.us-west-2.eks.amazonaws.com standard-cluster Delete
-```
-
-## Application Developer Tasks
-
-This section covers tasks performed by an application developer. These include:
-
-- Defining a Workload in terms of Resources and Payload (Deployment/Service) which will be deployed into the target Kubernetes Cluster
-- Defining the resource's dependency requirements, in this case a `MySQL` database
-
-Now that the EKS cluster is ready, let's begin deploying the workload as the application developer:
-
-```console
-kubectl create -f cluster/examples/workloads/wordpress-aws/workload.yaml
-```
-
-This will also take awhile to complete, since the MySQL database needs to be deployed before the WordPress pod can consume it.
-You can follow along with the MySQL database deployment with the following:
-
-```console
-kubectl -n crossplane-system get rdsinstance -o custom-columns=NAME:.metadata.name,STATUS:.status.state,CLASS:.spec.classRef.name,VERSION:.spec.version
-```
-
-Once the `STATUS` column is `available` as seen below, the WordPress pod should be able to connect to it:
-
-```console
-NAME STATUS CLASS VERSION
-mysql-2a0be04f-f748-11e8-844c-025000000001 available standard-mysql
-```
-
-Now we can watch the WordPress pod come online and a public IP address will get assigned to it:
-
-```console
-kubectl -n demo get workload -o custom-columns=NAME:.metadata.name,CLUSTER:.spec.targetCluster.name,NAMESPACE:.spec.targetNamespace,DEPLOYMENT:.spec.targetDeployment.metadata.name,SERVICE-EXTERNAL-IP:.status.service.loadBalancer.ingress[0].ip
-```
-
-When a public IP address has been assigned, you'll see output similar to the following:
-
-```console
-NAME CLUSTER NAMESPACE DEPLOYMENT SERVICE-EXTERNAL-IP
-demo demo-cluster demo wordpress 104.43.240.15
-```
-
-Once WordPress is running and has a public IP address through its service, we can get the URL with the following command:
-
-```console
-echo "http://$(kubectl get workload test-workload -o jsonpath='{.status.service.loadBalancer.ingress[0].ip}')"
-```
-
-Paste that URL into your browser and you should see WordPress running and ready for you to walk through its setup experience. You may need to wait a few minutes for this to become accessible via the AWS load balancer.
-
-## Connecting to your EKSCluster (optional)
-
-Requires:
- * awscli
- * aws-iam-authenticator
-
-Please see [Install instructions](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) section: `Install and Configure kubectl for Amazon EKS`
-
-When the EKSCluster is up and running, you can update your kubeconfig with:
-```console
-aws eks update-kubeconfig --name
-```
-
-Node pool is created after the master is up, so expect a few more minutes to wait, but eventually you can see that nodes joined with:
-```console
-kubectl config use-context
-kubectl get nodes
-```
-
-## Clean-up
-
-First delete the workload, which will delete WordPress and the MySQL database:
-
-```console
-kubectl delete -f cluster/examples/workloads/wordpress-aws/workload.yaml
-```
-
-Then delete the EKS cluster:
-
-```console
-kubectl delete -f cluster/examples/workloads/wordpress-aws/cluster.yaml
-```
-
-Finally, delete the provider credentials:
-
-```console
-kubectl delete -f cluster/examples/workloads/wordpress-aws/provider.yaml
-```
-
-> Note: There may still be an ELB that was not properly cleaned up, and you will need
-to go to EC2 > ELBs and delete it manually.
diff --git a/docs/v0.2/workloads/azure/wordpress-azure.md b/docs/v0.2/workloads/azure/wordpress-azure.md
deleted file mode 100644
index c71ebac8..00000000
--- a/docs/v0.2/workloads/azure/wordpress-azure.md
+++ /dev/null
@@ -1,131 +0,0 @@
-# Deploying a WordPress Workload on Microsoft Azure
-
-This guide will walk you through how to use Crossplane to deploy a stateful workload in a portable way to Azure.
-In this environment, the following components will be dynamically provisioned and configured during this guide:
-
-* AKS Kubernetes cluster
-* Azure MySQL database
-* WordPress application
-
-## Pre-requisites
-
-Before starting this guide, you should have already [configured your Azure account](../../cloud-providers/azure/azure-provider.md) for usage by Crossplane.
-
-- You should have a `crossplane-azure-provider-key.json` file on your local filesystem, preferably at the root of where you cloned the [Crossplane repo](https://github.com/crossplaneio/crossplane).
-- You should have a azure resource group with name `group-westus-1`. If not, change the value of `resourceGroupName` to an existing resource group in `cluster/examples/workloads/wordpress-azure/provider.yaml`
-
-
-
-## Administrator Tasks
-
-This section covers the tasks performed by the cluster or cloud administrator, which includes:
-
-- Import Azure provider credentials
-- Define Resource classes for cluster and database resources
-- Create a target Kubernetes cluster (using dynamic provisioning with the cluster resource class)
-
-**Note**: all artifacts created by the administrator are stored/hosted in the `crossplane-system` namespace, which has
-restricted access, i.e. `Application Owner(s)` should not have access to them.
-
-For the next steps, make sure your `kubectl` context points to the cluster where `Crossplane` was deployed.
-
-- Create the Azure provider object in your cluster:
-
- ```console
- sed "s/BASE64ENCODED_AZURE_PROVIDER_CREDS/`cat crossplane-azure-provider-key.json|base64|tr -d '\n'`/g;" cluster/examples/workloads/wordpress-azure/provider.yaml | kubectl create -f -
- ```
-
-- Next, create the AKS cluster that will eventually be the target cluster for your Workload deployment:
-
- ```console
- kubectl create -f cluster/examples/workloads/wordpress-azure/cluster.yaml
- ```
-
- It will take a while (~15 minutes) for the AKS cluster to be deployed and becoming ready. You can keep an eye on its status with the following command:
-
- ```console
- kubectl -n crossplane-system get akscluster -o custom-columns=NAME:.metadata.name,STATE:.status.state,CLUSTERNAME:.status.clusterName,ENDPOINT:.status.endpoint,LOCATION:.spec.location,CLUSTERCLASS:.spec.classRef.name,RECLAIMPOLICY:.spec.reclaimPolicy
- ```
-
- Once the cluster is done provisioning, you should see output similar to the following (note the `STATE` field is `Succeeded` and the `ENDPOINT` field has a value):
-
- ```console
- NAME STATE CLUSTERNAME ENDPOINT LOCATION CLUSTERCLASS RECLAIMPOLICY
- aks-587762b3-f72b-11e8-bcbe-0800278fedb1 Succeeded aks-587762b3-f72b-11e8-bcbe-080 crossplane-aks-653c32ef.hcp.centralus.azmk8s.io Central US standard-cluster Delete
- ```
-
-To recap the operations that we just performed as the administrator:
-
-- Defined a `Provider` with Microsoft Azure service principal credentials
-- Defined `ResourceClasses` for `KubernetesCluster` and `MySQLInstance`
-- Provisioned (dynamically) an AKS Cluster using the `ResourceClass`
-
-## Application Developer Tasks
-
-This section covers the tasks performed by the application developer, which includes:
-
-- Define Workload in terms of Resources and Payload (Deployment/Service) which will be deployed into the target Kubernetes Cluster
-- Define the dependency resource requirements, in this case a `MySQL` database
-
-Let's begin deploying the workload as the application developer:
-
-- Now that the target AKS cluster is ready, we can deploy the Workload that contains all the Wordpress resources, including the SQL database, with the following single command:
-
- ```console
- kubectl create -f cluster/examples/workloads/wordpress-azure/workload.yaml
- ```
-
- This will also take awhile to complete, since the MySQL database needs to be deployed before the Wordpress pod can consume it.
- You can follow along with the MySQL database deployment with the following:
-
- ```console
- kubectl -n crossplane-system get mysqlserver -o custom-columns=NAME:.metadata.name,STATUS:.status.state,CLASS:.spec.classRef.name,VERSION:.spec.version
- ```
-
- Once the `STATUS` column is `Ready` like below, then the Wordpress pod should be able to connect to it:
-
- ```console
- NAME STATUS CLASS VERSION
- mysql-58425bda-f72d-11e8-bcbe-0800278fedb1 Ready standard-mysql 5.7
- ```
-
-- Now we can watch the Wordpress pod come online and a public IP address will get assigned to it:
-
- ```console
- kubectl get workload -o custom-columns=NAME:.metadata.name,CLUSTER:.spec.targetCluster.name,NAMESPACE:.spec.targetNamespace,DEPLOYMENT:.spec.targetDeployment.metadata.name,SERVICE-EXTERNAL-IP:.status.service.loadBalancer.ingress[0].ip
- ```
-
- When a public IP address has been assigned, you'll see output similar to the following:
-
- ```console
- NAME CLUSTER NAMESPACE DEPLOYMENT SERVICE-EXTERNAL-IP
- test-workload demo-cluster demo wordpress 104.43.240.15
- ```
-
-- Once Wordpress is running and has a public IP address through its service, we can get the URL with the following command:
-
- ```console
- echo "http://$(kubectl get workload test-workload -o jsonpath='{.status.service.loadBalancer.ingress[0].ip}')"
- ```
-
-- Paste that URL into your browser and you should see Wordpress running and ready for you to walk through the setup experience.
-
-## Clean-up
-
-First delete the workload, which will delete Wordpress and the MySQL database:
-
-```console
-kubectl delete -f cluster/examples/workloads/wordpress-azure/workload.yaml
-```
-
-Then delete the AKS cluster:
-
-```console
-kubectl delete -f cluster/examples/workloads/wordpress-azure/cluster.yaml
-```
-
-Finally, delete the provider credentials:
-
-```console
-kubectl delete -f cluster/examples/workloads/wordpress-azure/provider.yaml
-```
diff --git a/docs/v0.2/workloads/gcp/wordpress-gcp.md b/docs/v0.2/workloads/gcp/wordpress-gcp.md
deleted file mode 100644
index f8063ec4..00000000
--- a/docs/v0.2/workloads/gcp/wordpress-gcp.md
+++ /dev/null
@@ -1,194 +0,0 @@
-# Deploying a WordPress Workload on GCP
-
-This guide will walk you through how to use Crossplane to deploy a stateful workload in a portable way to GCP.
-In this environment, the following components will be dynamically provisioned and configured during this guide:
-
-* GKE Kubernetes cluster
-* CloudSQL database
-* WordPress application
-
-## Pre-requisites
-
-Before starting this guide, you should have already [configured your GCP account](../../cloud-providers/gcp/gcp-provider.md) for usage by Crossplane.
-
-You should have a `crossplane-gcp-provider-key.json` file on your local filesystem, preferably at the root of where you cloned the [Crossplane repo](https://github.com/crossplaneio/crossplane).
-
-## Administrator Tasks
-
-This section covers the tasks performed by the cluster or cloud administrator, which includes:
-
-- Import GCP provider credentials
-- Define Resource classes for cluster and database resources
-- Create a target Kubernetes cluster (using dynamic provisioning with the cluster resource class)
-
-**Note**: all artifacts created by the administrator are stored/hosted in the `crossplane-system` namespace, which has
-restricted access, i.e. `Application Owner(s)` should not have access to them.
-
-For the next steps, make sure your `kubectl` context points to the cluster where `Crossplane` was deployed.
-
-- Export Project ID
-
- **NOTE** you can skip this step if you generated GCP Service Account using `gcloud`
- ```bash
- export DEMO_PROJECT_ID=[your-demo-project-id]
- ```
-
-- Patch and Apply `provider.yaml`:
-
- ```bash
- sed "s/BASE64ENCODED_CREDS/`cat key.json|base64 | tr -d '\n'`/g;s/DEMO_PROJECT_ID/$DEMO_PROJECT_ID/g" cluster/examples/workloads/wordpress-gcp/provider.yaml | kubectl create -f -
- ```
-
- - Verify that GCP Provider is in `Ready` state
-
- ```bash
- kubectl -n crossplane-system get providers.gcp.crossplane.io -o custom-columns=NAME:.metadata.name,STATUS:.status.Conditions[0].Type,PROJECT-ID:.spec.projectID
- ```
-
- Your output should look similar to:
- ```bash
- NAME STATUS PROJECT-ID
- gcp-provider Ready [your-project-id]
- ```
-
- - Verify that Resource Classes have been created
-
- ```bash
- kubectl -n crossplane-system get resourceclass -o custom-columns=NAME:metadata.name,PROVISIONER:.provisioner,PROVIDER:.providerRef.name,RECLAIM-POLICY:.reclaimPolicy
- ```
-
- Your output should be:
- ```bash
- NAME PROVISIONER PROVIDER RECLAIM-POLICY
- standard-cluster gkecluster.compute.gcp.crossplane.io/v1alpha1 gcp-provider Delete
- standard-mysql cloudsqlinstance.database.gcp.crossplane.io/v1alpha1 gcp-provider Delete
- ```
-
-- Create a target Kubernetes cluster where `Application Owner(s)` will deploy their `WorkLoad(s)`
-
- As administrator, you will create a Kubernetes cluster leveraging the Kubernetes cluster `ResourceClass` that was created earlier and
- `Crossplane` Kubernetes cluster dynamic provisioning.
-
- ```bash
- kubectl apply -f cluster/examples/workloads/wordpress-gcp/cluster.yaml
- ```
-
- - Verify that Kubernetes Cluster resource was created
-
- ```bash
- kubectl -n crossplane-system get kubernetescluster -o custom-columns=NAME:.metadata.name,CLUSTERCLASS:.spec.classReference.name,CLUSTERREF:.spec.resourceName.name
- ```
-
- Your output should look similar to:
- ```bash
- NAME CLUSTERCLASS CLUSTERREF
- demo-gke-cluster standard-cluster gke-67419e79-f5b3-11e8-9cec-9cb6d08bde99
- ```
-
- - Verify that the target GKE cluster was successfully created
-
- ```bash
- kubectl -n crossplane-system get gkecluster -o custom-columns=NAME:.metadata.name,STATE:.status.state,CLUSTERNAME:.status.clusterName,ENDPOINT:.status.endpoint,LOCATION:.spec.zone,CLUSTERCLASS:.spec.classRef.name,RECLAIMPOLICY:.spec.reclaimPolicy
- ```
-
- Your output should look similar to:
- ```bash
- NAME STATE CLUSTERNAME ENDPOINT LOCATION CLUSTERCLASS RECLAIMPOLICY
- gke-67419e79-f5b3-11e8-9cec-9cb6d08bde99 RUNNING gke-6742fe8d-f5b3-11e8-9cec-9cb6d08bde99 146.148.93.40 us-central1-a standard-cluster Delete
- ```
-
-To recap the operations that we just performed as the administrator:
-
-- Defined a `Provider` with Google Service Account credentials
-- Defined `ResourceClasses` for `KubernetesCluster` and `MySQLInstance`
-- Provisioned (dynamically) a GKE Cluster using the `ResourceClass`
-
-## Application Developer Tasks
-
-This section covers the tasks performed by the application developer, which includes:
-
-- Define Workload in terms of Resources and Payload (Deployment/Service) which will be deployed into the target Kubernetes Cluster
-- Define the dependency resource requirements, in this case a `MySQL` database
-
-Let's begin deploying the workload as the application developer:
-
-- Deploy workload
-
- ```bash
- kubectl apply -f cluster/examples/workloads/wordpress-gcp/workload.yaml
- ```
-
-- Wait for `MySQLInstance` to be in `Bound` State
-
- You can check the status via:
- ```bash
- kubectl get mysqlinstance -o custom-columns=NAME:.metadata.name,VERSION:.spec.engineVersion,STATE:.status.bindingPhase,CLASS:.spec.classReference.name
- ```
-
- Your output should look like:
- ```bash
- NAME VERSION STATE CLASS
- demo 5.7 Bound standard-mysql
- ```
-
- **Note**: to check on the concrete resource type status as `Administrator` you can run:
-
- ```bash
- kubectl -n crossplane-system get cloudsqlinstance -o custom-columns=NAME:.metadata.name,STATUS:.status.state,CLASS:.spec.classRef.name,VERSION:.spec.databaseVersion
- ```
-
- Your output should be similar to:
- ```bash
- NAME STATUS CLASS VERSION
- mysql-2fea0d8e-f5bb-11e8-9cec-9cb6d08bde99 RUNNABLE standard-mysql MYSQL_5_7
- ```
-
-- Wait for `Workload` External IP Address
-
- ```bash
- kubectl get workload -o custom-columns=NAME:.metadata.name,CLUSTER:.spec.targetCluster.name,NAMESPACE:.spec.targetNamespace,DEPLOYMENT:.spec.targetDeployment.metadata.name,SERVICE-EXTERNAL-IP:.status.service.loadBalancer.ingress[0].ip
- ```
- **Note** the `Workload` is defined in Application Owner's (`default`) namespace
-
- Your output should look similar to:
- ```bash
- NAME CLUSTER NAMESPACE DEPLOYMENT SERVICE-EXTERNAL-IP
- demo demo-gke-cluster demo wordpress 35.193.100.113
- ```
-
-- Verify that `WordPress` service is accessible via `SERVICE-EXTERNAL-IP` by:
- - Navigate in your browser to `SERVICE-EXTERNAL-IP`
-
-At this point, you should see the setup page for WordPress in your web browser.
-
-## Clean Up
-
-Once you are done with this example, you can clean up all its artifacts with the following commands:
-
-- Remove `Workload`
-
- ```bash
- kubectl delete -f cluster/examples/workloads/wordpress-gcp/workload.yaml
- ```
-
-- Remove `KubernetesCluster`
-
- ```bash
- kubectl delete -f cluster/examples/workloads/wordpress-gcp/cluster.yaml
- ```
-
-- Remove GCP `Provider` and `ResourceClasses`
-
- ```bash
- kubectl delete -f cluster/examples/workloads/wordpress-gcp/provider.yaml
- ```
-
-- Delete Google Project
-
- ```bash
- # list all your projects
- gcloud projects list
-
- # delete demo project
- gcloud projects delete [demo-project-id]
- ```
diff --git a/docs/v0.3/README.md b/docs/v0.3/README.md
deleted file mode 100644
index 96fb22f0..00000000
--- a/docs/v0.3/README.md
+++ /dev/null
@@ -1,180 +0,0 @@
-# Welcome to Crossplane!
-
-Crossplane is an open source multicloud control plane to manage your
-cloud-native applications and infrastructure across environments, clusters,
-regions and clouds. It enables provisioning and full-lifecycle management
- of applications and managed services from your choice of cloud using `kubectl`.
-
-Crossplane can be installed into an existing Kubernetes cluster to add managed
-service provisioning or deployed as a dedicated control plane for multi-cluster
-management and workload scheduling.
-
-Crossplane enables the community to build and publish Stacks to add more clouds
-and cloud services to Crossplane with support for out-of-tree extensibility and
-independent release schedules. Crossplane includes Stacks for [GCP][stack-gcp],
-[AWS][stack-aws], and [Azure][stack-azure] today.
-
-
-
-Crossplane has four main feature areas that can be used independently:
-1. Crossplane Services - provision managed services from kubectl.
-1. Crossplane Stacks - extend Crossplane with new functionality.
-1. Crossplane Workloads - define complete applications and schedule across
- clusters, regions, and clouds.
-1. Crossplane Clusters - manage multiple Kubernetes clusters from a single
- control plane.
-
-## Crossplane Services
-Crossplane Services supports managed service provisioning
-using `kubectl`. It applies the Kubernetes pattern for Persistent Volume (PV)
-claims and classes to managed service provisioning with support for a strong
-separation of concern between app teams and cluster administrators.
-
-App teams can choose between cloud-specific and portable services including
-managed databases, message queues, buckets, data pipelines, and more to define
-complete applications, build once, and deploy into multiple clouds using
-continuous delivery pipelines or GitOps flows.
-
-Cluster administrators can define self-service policies and best-practice
-configurations to accelerate app delivery and improve security, so app teams can
-focus on delivering their app instead of cloud-specific infrastructure details.
-
-The [Crossplane Services Guide][services-user-guide] explores related concepts and
-shows how to use Crossplane Services to deploy a Wordpress instance that
-securely consumes a managed `MySQLInstance` from GCP, AWS, or Azure from
-`kubectl`.
-
-## Crossplane Stacks
-Stacks extend Crossplane with new functionality and can be
-installed using the [Stack
-Manager][stacks-manager]
-via the [Kubernetes
-API][stack-install-docs]
-or with the [crossplane kubectl
-plugin][crossplane-cli] [`stack install`][crossplane-cli-usage] command.
-
-Crossplane is built on the Kubernetes API machinery as a platform, and Stacks
-simplify extending the Kubernetes API to provision and lifecycle manage apps and
-the managed service infrastructure they depend on, including [Stack security and
-isolation][stack-security-design].
-
-The [Crossplane Stacks Guide][stack-user-guide] shows how to deploy a portable [Wordpress Stack][stack-wordpress-registry]
-into multiple clouds using Infra Stacks including
-[stack-gcp][stack-gcp], [stack-aws][stack-aws], and [stack-azure][stack-azure].
-
-### Infrastructure Stacks
-Infra Stacks like [stack-gcp][stack-gcp], [stack-aws][stack-aws], and [stack-azure][stack-azure]
-extend the Kubernetes API to support managed service provisioning (DBaaS, cache, buckets), secure
-connectivity (VPCs, subnets, peering, ACLs, secrets), and provisioning managed
-Kubernetes clusters on demand to further isolate the blast radius of applications.
-
-Infra Stacks are pre-built and published to the [Stacks
-registry][stack-registry] where they can
-be installed by a Cluster Admin using a
-[`ClusterStackInstall`][stack-install-docs]
-Kubernetes API kind or with the [`stack
-install`][crossplane-cli-usage] command that
-installs a Stacks with permissions to watch resources at a cluster level, across
-all namespaces.
-
-Infra Stacks are covered in both the [Crossplane Services
-Guide][services-user-guide] and the
-[Crossplane Stacks Guide][stack-user-guide].
-
-### Application Stacks
-App Stacks depend on Infra Stacks like
-[stack-gcp][stack-gcp], [stack-aws][stack-aws], and [stack-azure][stack-azure]
-to provide managed services via the Kubernetes API.
-
-App Stacks are pre-built and published to the [Stacks
-registry][stack-registry] where they can
-be installed by an app team using a
-[`StackInstall`][stack-install-docs]
-Kubernetes API kind or with the [`stack
-install`][crossplane-cli-usage] command that
-installs Stacks with permissions only within a single namespace.
-
-The [Crossplane Stacks Guide][stack-user-guide] covers how to deploy a portable
-[Wordpress Stack][stack-wordpress] into multiple clouds using Infra Stacks such
-as [stack-gcp][stack-gcp], [stack-aws][stack-aws], and [stack-azure][stack-azure].
-
-### Build your own Stack
-The [Crossplane Developer Guide][stack-developer-guide] shows how to
-build and extend Infra Stacks and App Stacks.
-
-## Crossplane Workloads
-Crossplane includes an extensible workload scheduler that observes application
-policies to select a suitable target cluster from a pool of available clusters.
-The workload scheduler can be customized to consider a number of criteria including
-capabilities, availability, reliability, cost, regions, and performance while
-deploying workloads and their resources.
-
-Complex workloads can be modeled as a
-[`KubernetesApplication`][k8s-app-design]
-resource as done by the portable [Wordpress Stack][stack-wordpress] which
-automates the lifecycle of a
-[`KubernetesApplication`][k8s-app-design]
-including provisioning and secure connectivity to a managed `MySQLInstance`.
-
-## Crossplane Clusters
-Crossplane supports dynamic provisioning of managed
-Kubernetes clusters from a single control plane with consistent multi-cluster
-best-practice configuration and secure connectivity between target Kubernetes
-clusters and the managed services provisioned for applications. Managed
-Kubernetes clusters can be dynamically provisioned with a `KubernetesCluster`
-resource as done by the portable [Wordpress Stack][stack-wordpress] which
-automates the lifecycle of a `KubernetesCluster`.
-
-## Architecture and Vision
-
-The full architecture and vision of the Crossplane project is described in depth
-in the [architecture document][arch-doc].
-It is the best place to learn more about how Crossplane fits into the Kubernetes
-ecosystem, the intended use cases, and comparisons to existing projects.
-
-## Learn More
-If you have any questions, please drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us]!
-
-* [Quick Start Guide](quick-start.md)
-* [Getting Started](getting-started.md)
-* [Concepts](concepts.md)
-* [API Reference](api.md)
-* [FAQs](faqs.md)
-* [Contributing](contributing.md)
-
-### Next Steps
-Use [stack-gcp][stack-gcp], [stack-aws][stack-aws], and [stack-azure][stack-azure] in the the following guides:
-* [Crossplane Service Guide][services-user-guide] - upgrade an existing Kubernetes cluster
- to support managed service provisioning from kubectl.
-* [Crossplane Stacks Guide][stack-user-guide] - deploy a portable Wordpress Stack into
- multiple clouds.
-
-[Learn more][learn-more] about Crossplane.
-
-
-[services-user-guide]: services-guide.md
-[stack-user-guide]: stacks-guide.md
-[stack-developer-guide]: developer-guide.md
-[stacks-manager]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#terminology
-[crossplane-cli]: https://github.com/crossplaneio/crossplane-cli
-[crossplane-cli-usage]: https://github.com/crossplaneio/crossplane-cli#usage
-[stack-security-design]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-stacks-security-isolation.md
-
-[stack-wordpress-registry]: https://hub.docker.com/r/crossplane/sample-stack-wordpress
-[stack-wordpress]: https://github.com/crossplaneio/sample-stack-wordpress
-
-[stack-gcp]: https://github.com/crossplaneio/stack-gcp
-[stack-aws]: https://github.com/crossplaneio/stack-aws
-[stack-azure]: https://github.com/crossplaneio/stack-azure
-[stack-registry]: https://hub.docker.com/search?q=crossplane&type=image
-[stack-install-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#installation-flow
-
-[k8s-app-design]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-complex-workloads.md#design
-
-[arch-doc]: https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit?usp=sharing
-
-[contact-us]: https://github.com/crossplaneio/crossplane#contact
-[join-crossplane-slack]: https://slack.crossplane.io
-[learn-more]: learn-more.md
-
diff --git a/docs/v0.3/api.md b/docs/v0.3/api.md
deleted file mode 100644
index 2d5c3670..00000000
--- a/docs/v0.3/api.md
+++ /dev/null
@@ -1,121 +0,0 @@
----
-title: API Reference
-toc: true
-weight: 610
----
-# API Reference
-
-Crossplane is configured using a variety of Kubernetes resources. These
-resources are separated into API groups. Core API groups are provided by
-Crossplane, while cloud provider specific API groups are provided by each cloud
-provider's stack.
-
-Each API Group supported by Crossplane is assigned its own individual status to
-reflect the varying maturity and stability. More details about API versioning
-and status in Kubernetes can be found on the Kubernetes [API versioning] page,
-but the key difference between the statuses are summarized below:
-
-* **Alpha:** The API may change in incompatible ways in a later software release
- without notice, recommended for use only in short-lived testing clusters, due
- to increased risk of bugs and lack of long-term support.
-* **Beta:** Support for the overall features will not be dropped, though details
- may change. Support for upgrading or migrating between versions will be
- provided, either through automation or manual steps.
-* **Stable:** Features will appear in released software for many subsequent
- versions and support for upgrading between versions will be provided with
- software automation in the vast majority of scenarios.
-
-## Crossplane
-
-Crossplane is reponsible for all portable resources, including resource claims
-(for example `MySQLInstance`) and portable resource classes (for example
-`MySQLInstanceClass). Crossplane currently supports the following API groups:
-
-API Group | Status | Details
--------- | ------ | -------
-[`cache.crossplane.io/v1alpha1`] | Alpha | Cache service claims and classes.
-[`compute.crossplane.io/v1alpha1`] | Alpha | Compute service resource claims and classes.
-[`database.crossplane.io/v1alpha1`] | Alpha | Database service resource claims and classes.
-[`storage.crossplane.io/v1alpha1`] | Alpha | Blob storage service resource claims and classes.
-[`stacks.crossplane.io/v1alpha1`] | Alpha | Resources for managing Crossplane Stacks.
-[`workload.crossplane.io/v1alpha1`] | Alpha | Resources for managing Crossplane Workloads.
-
-[`cache.crossplane.io/v1alpha1`]: api/crossplaneio/crossplane/cache-crossplane-io-v1alpha1.md
-[`compute.crossplane.io/v1alpha1`]: api/crossplaneio/crossplane/compute-crossplane-io-v1alpha1.md
-[`database.crossplane.io/v1alpha1`]: api/crossplaneio/crossplane/database-crossplane-io-v1alpha1.md
-[`storage.crossplane.io/v1alpha1`]: api/crossplaneio/crossplane/storage-crossplane-io-v1alpha1.md
-[`stacks.crossplane.io/v1alpha1`]: api/crossplaneio/crossplane/stacks-crossplane-io-v1alpha1.md
-[`workload.crossplane.io/v1alpha1`]: api/crossplaneio/crossplane/workload-crossplane-io-v1alpha1.md
-
-## AWS Stack
-
-The AWS Stack is reponsible for all AWS specific resources, including managed
-resources (for example `EKSCluster`), and cloud specific resource classes (for
-example `EKSClusterClass`) The AWS Stack currently supports the following API
-groups:
-
-API Group | Status | Details
--------- | ------ | -------
-[`aws.crossplane.io/v1alpha2`] | Alpha | Core AWS resources.
-[`cache.aws.crossplane.io/v1alpha2`] | Alpha | ElastiCache managed resources and classes.
-[`compute.aws.crossplane.io/v1alpha2`] | Alpha | EKS managed resources and classes.
-[`database.aws.crossplane.io/v1alpha2`] | Alpha | RDS managed resources and classes.
-[`identity.aws.crossplane.io/v1alpha2`] | Alpha | IAM managed resources and classes.
-[`network.aws.crossplane.io/v1alpha2`] | Alpha | VPC managed resources and classes.
-[`storage.aws.crossplane.io/v1alpha2`] | Alpha | S3 managed resources and classes.
-
-[`aws.crossplane.io/v1alpha2`]: api/crossplaneio/stack-aws/aws-crossplane-io-v1alpha2.md
-[`cache.aws.crossplane.io/v1alpha2`]: api/crossplaneio/stack-aws/cache-aws-crossplane-io-v1alpha2.md
-[`compute.aws.crossplane.io/v1alpha2`]: api/crossplaneio/stack-aws/compute-aws-crossplane-io-v1alpha2.md
-[`database.aws.crossplane.io/v1alpha2`]: api/crossplaneio/stack-aws/database-aws-crossplane-io-v1alpha2.md
-[`identity.aws.crossplane.io/v1alpha2`]: api/crossplaneio/stack-aws/identity-aws-crossplane-io-v1alpha2.md
-[`network.aws.crossplane.io/v1alpha2`]: api/crossplaneio/stack-aws/network-aws-crossplane-io-v1alpha2.md
-[`storage.aws.crossplane.io/v1alpha2`]: api/crossplaneio/stack-aws/storage-aws-crossplane-io-v1alpha2.md
-
-## Azure Stack
-
-The Azure Stack is reponsible for all Azure specific resources, including
-managed resources (for example `AKSCluster`), and cloud specific resource
-classes (for example `AKSClusterClass`) The Azure Stack currently supports the
-following API groups:
-
-API Group | Status | Details
--------- | ------ | -------
-[`azure.crossplane.io/v1alpha2`] | Alpha | Core Azure resources.
-[`cache.azure.crossplane.io/v1alpha2`] | Alpha | Azure Redis managed resources and classes.
-[`compute.azure.crossplane.io/v1alpha2`] | Alpha | AKS managed resources and classes.
-[`database.azure.crossplane.io/v1alpha2`] | Alpha | Azure Database managed resources and classes.
-[`network.azure.crossplane.io/v1alpha2`] | Alpha | Virtual network managed resources and classes.
-[`storage.azure.crossplane.io/v1alpha2`] | Alpha | Azure Blob Storage managed resources and classes.
-
-[`azure.crossplane.io/v1alpha2`]: api/crossplaneio/stack-azure/azure-crossplane-io-v1alpha2.md
-[`cache.azure.crossplane.io/v1alpha2`]: api/crossplaneio/stack-azure/cache-azure-crossplane-io-v1alpha2.md
-[`compute.azure.crossplane.io/v1alpha2`]: api/crossplaneio/stack-azure/compute-azure-crossplane-io-v1alpha2.md
-[`database.azure.crossplane.io/v1alpha2`]: api/crossplaneio/stack-azure/database-azure-crossplane-io-v1alpha2.md
-[`network.azure.crossplane.io/v1alpha2`]: api/crossplaneio/stack-azure/network-azure-crossplane-io-v1alpha2.md
-[`storage.azure.crossplane.io/v1alpha2`]: api/crossplaneio/stack-azure/storage-azure-crossplane-io-v1alpha2.md
-
-## GCP Stack
-
-The GCP Stack is reponsible for all GCP specific resources, including managed
-resources (for example `GKECluster`), and cloud specific resource classes (for
-example `GKEClusterClass`) The GCP Stack currently supports the following API
-groups:
-
-API Group | Status | Details
--------- | ------ | -------
-[`gcp.crossplane.io/v1alpha2`] | Alpha | Core GCP resources.
-[`cache.gcp.crossplane.io/v1alpha2`] | Alpha | CloudMemorystore managed resources and classes.
-[`compute.gcp.crossplane.io/v1alpha2`] | Alpha | Compute and Kubernetes Engine managed resources and classes.
-[`database.gcp.crossplane.io/v1alpha2`] | Alpha | CloudSQL managed resources and classes.
-[`servicenetworking.gcp.crossplane.io/v1alpha2`] | Alpha | Service Networking managed resources and classes.
-[`storage.gcp.crossplane.io/v1alpha2`] | Alpha | Cloud Storage managed resources and classes.
-
-[`gcp.crossplane.io/v1alpha2`]: api/crossplaneio/stack-gcp/gcp-crossplane-io-v1alpha2.md
-[`cache.gcp.crossplane.io/v1alpha2`]: api/crossplaneio/stack-gcp/cache-gcp-crossplane-io-v1alpha2.md
-[`compute.gcp.crossplane.io/v1alpha2`]: api/crossplaneio/stack-gcp/compute-gcp-crossplane-io-v1alpha2.md
-[`database.gcp.crossplane.io/v1alpha2`]: api/crossplaneio/stack-gcp/database-gcp-crossplane-io-v1alpha2.md
-[`servicenetworking.gcp.crossplane.io/v1alpha2`]: api/crossplaneio/stack-gcp/servicenetworking-gcp-crossplane-io-v1alpha2.md
-[`storage.gcp.crossplane.io/v1alpha2`]: api/crossplaneio/stack-gcp/storage-gcp-crossplane-io-v1alpha2.md
-
-[API Versioning]: https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-versioning
diff --git a/docs/v0.3/api/crossplaneio/crossplane-runtime/core-crossplane-io-v1alpha1.md b/docs/v0.3/api/crossplaneio/crossplane-runtime/core-crossplane-io-v1alpha1.md
deleted file mode 100644
index 52e0d1a8..00000000
--- a/docs/v0.3/api/crossplaneio/crossplane-runtime/core-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,173 +0,0 @@
-# core.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains core API types used by most Crossplane resources.
-
-This API group contains the following Crossplane resources:
-
-
-## BindingPhase
-
-BindingPhase represents the current binding phase of a resource or claim. Alias of string.
-
-Appears in:
-
-* [BindingStatus](#BindingStatus)
-
-
-## BindingStatus
-
-A BindingStatus represents the bindability and binding status of a resource.
-
-Appears in:
-
-* [ResourceClaimStatus](#ResourceClaimStatus)
-* [ResourceStatus](#ResourceStatus)
-
-
-Name | Type | Description
------|------|------------
-`bindingPhase` | Optional [BindingPhase](#BindingPhase) | Phase represents the binding phase of a managed resource or claim. Unbindable resources cannot be bound, typically because they are currently unavailable, or still being created. Unbound resource are available for binding, and Bound resources have successfully bound to another resource.
-
-
-
-## Condition
-
-A Condition that may apply to a managed resource.
-
-Appears in:
-
-* [ConditionedStatus](#ConditionedStatus)
-
-
-Name | Type | Description
------|------|------------
-`type` | [ConditionType](#ConditionType) | Type of this condition. At most one of each condition type may apply to a resource at any point in time.
-`status` | [core/v1.ConditionStatus](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#conditionstatus-v1-core) | Status of this condition; is it currently True, False, or Unknown?
-`lastTransitionTime` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | LastTransitionTime is the last time this condition transitioned from one status to another.
-`reason` | [ConditionReason](#ConditionReason) | A Reason for this condition's last transition from one status to another.
-`message` | Optional string | A Message containing details about this condition's last transition from one status to another, if any.
-
-
-
-## ConditionReason
-
-A ConditionReason represents the reason a resource is in a condition. Alias of string.
-
-Appears in:
-
-* [Condition](#Condition)
-
-
-## ConditionType
-
-A ConditionType represents a condition a resource could be in. Alias of string.
-
-Appears in:
-
-* [Condition](#Condition)
-
-
-## ConditionedStatus
-
-A ConditionedStatus reflects the observed status of a managed resource. Only one condition of each type may exist.
-
-Appears in:
-
-* [ResourceClaimStatus](#ResourceClaimStatus)
-* [ResourceStatus](#ResourceStatus)
-
-
-Name | Type | Description
------|------|------------
-`conditions` | Optional [[]Condition](#Condition) | Conditions of the resource.
-
-
-
-## NonPortableClassSpecTemplate
-
-NonPortableClassSpecTemplate defines a template that will be used to create the specifications of managed resources dynamically provisioned using a resource class.
-
-
-Name | Type | Description
------|------|------------
-`providerRef` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | ProviderReference specifies the provider that will be used to create, observe, update, and delete managed resources that are dynamically provisioned using this resource class.
-`reclaimPolicy` | Optional [ReclaimPolicy](#ReclaimPolicy) | ReclaimPolicy specifies what will happen to external resources when managed resources dynamically provisioned using this resource class are deleted. "Delete" deletes the external resource, while "Retain" (the default) does not. Note this behaviour is subtly different from other uses of the ReclaimPolicy concept within the Kubernetes ecosystem per https://github.com/crossplaneio/crossplane-runtime/issues/21
-
-
-
-## PortableClass
-
-A PortableClass connects a portable resource claim to a non-portable resource class used for dynamic provisioning.
-
-
-Name | Type | Description
------|------|------------
-`classRef` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | NonPortableClassReference is a reference to a resource class kind that is not portable across cloud providers, such as an RDSInstanceClass.
-
-
-
-## ReclaimPolicy
-
-A ReclaimPolicy determines what should happen to managed resources when their bound resource claims are deleted. Alias of string.
-
-Appears in:
-
-* [NonPortableClassSpecTemplate](#NonPortableClassSpecTemplate)
-* [ResourceSpec](#ResourceSpec)
-
-
-## ResourceClaimSpec
-
-A ResourceClaimSpec defines the desired state of a resource claim.
-
-
-Name | Type | Description
------|------|------------
-`writeConnectionSecretToRef` | Optional [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core) | WriteConnectionSecretToReference specifies the name of a Secret, in the same namespace as this resource claim, to which any connection details for this resource claim should be written. Connection details frequently include the endpoint, username, and password required to connect to the managed resource bound to this resource claim.
-`classRef` | Optional [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core) | A PortableClassReference specifies the name of a portable resource class, in the same namespace as this resource claim, that will be used to dynamically provision a managed resource when the resource claim is created. The specified class kind must be aligned with the resource claim; e.g. a MySQLInstance kind resource claim always refers to a MySQLInstanceClass kind portable resource class. Omit the portable class reference if you wish to bind to a specific managed resource (known as static binding), or to use the default portable class for the resource claim's namespace (if any).
-`resourceRef` | Optional [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | A ResourceReference specifies an existing managed resource, in any namespace, to which this resource claim should attempt to bind. Omit the resource reference to enable dynamic provisioning using a portable resource class; the resource reference will be automatically populated by Crossplane.
-
-
-
-## ResourceClaimStatus
-
-A ResourceClaimStatus represents the observed status of a resource claim.
-
-
-
-
-ResourceClaimStatus supports all fields of:
-
-* [ConditionedStatus](#ConditionedStatus)
-* [BindingStatus](#BindingStatus)
-
-
-## ResourceSpec
-
-A ResourceSpec defines the desired state of a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`writeConnectionSecretToRef` | Optional [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core) | WriteConnectionSecretToReference specifies the name of a Secret, in the same namespace as this managed resource, to which any connection details for this managed resource should be written. Connection details frequently include the endpoint, username, and password required to connect to the managed resource.
-`claimRef` | Optional [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | ClaimReference specifies the resource claim to which this managed resource will be bound. ClaimReference is set automatically during dynamic provisioning. Crossplane does not currently support setting this field manually, per https://github.com/crossplaneio/crossplane-runtime/issues/19
-`classRef` | Optional [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | NonPortableClassReference specifies the non-portable resource class that was used to dynamically provision this managed resource, if any. Crossplane does not currently support setting this field manually, per https://github.com/crossplaneio/crossplane-runtime/issues/20
-`providerRef` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | ProviderReference specifies the provider that will be used to create, observe, update, and delete this managed resource.
-`reclaimPolicy` | Optional [ReclaimPolicy](#ReclaimPolicy) | ReclaimPolicy specifies what will happen to the external resource this managed resource manages when the managed resource is deleted. "Delete" deletes the external resource, while "Retain" (the default) does not. Note this behaviour is subtly different from other uses of the ReclaimPolicy concept within the Kubernetes ecosystem per https://github.com/crossplaneio/crossplane-runtime/issues/21
-
-
-
-## ResourceStatus
-
-ResourceStatus represents the observed state of a managed resource.
-
-
-
-
-ResourceStatus supports all fields of:
-
-* [ConditionedStatus](#ConditionedStatus)
-* [BindingStatus](#BindingStatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/crossplane/cache-crossplane-io-v1alpha1.md b/docs/v0.3/api/crossplaneio/crossplane/cache-crossplane-io-v1alpha1.md
deleted file mode 100644
index d9d78dfc..00000000
--- a/docs/v0.3/api/crossplaneio/crossplane/cache-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# cache.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains portable resource claims for caching services such as Redis clusters.
-
-This API group contains the following Crossplane resources:
-
-* [RedisCluster](#RedisCluster)
-* [RedisClusterClass](#RedisClusterClass)
-
-## RedisCluster
-
-A RedisCluster is a portable resource claim that may be satisfied by binding to a Redis managed resource such as a GCP CloudMemorystore instance or an AWS ReplicationGroup. Despite the name RedisCluster claims may bind to Redis managed resources that are a single node, or not in cluster mode.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.crossplane.io/v1alpha1`
-`kind` | string | `RedisCluster`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [RedisClusterSpec](#RedisClusterSpec) | RedisClusterSpec specifies the desired state of a RedisCluster.
-`status` | [v1alpha1.ResourceClaimStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimstatus) |
-
-
-
-## RedisClusterClass
-
-RedisClusterClass contains a namespace-scoped portable class for RedisCluster
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.crossplane.io/v1alpha1`
-`kind` | string | `RedisClusterClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-
-
-RedisClusterClass supports all fields of:
-
-* [v1alpha1.PortableClass](../crossplane-runtime/core-crossplane-io-v1alpha1.md#portableclass)
-
-
-## RedisClusterSpec
-
-RedisClusterSpec specifies the desired state of a RedisCluster.
-
-Appears in:
-
-* [RedisCluster](#RedisCluster)
-
-
-Name | Type | Description
------|------|------------
-`engineVersion` | string | EngineVersion specifies the desired Redis version.
-
-
-RedisClusterSpec supports all fields of:
-
-* [v1alpha1.ResourceClaimSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimspec)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/crossplane/compute-crossplane-io-v1alpha1.md b/docs/v0.3/api/crossplaneio/crossplane/compute-crossplane-io-v1alpha1.md
deleted file mode 100644
index e89a66f4..00000000
--- a/docs/v0.3/api/crossplaneio/crossplane/compute-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# compute.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains portable resource claims for compute services such as Kubernetes clusters.
-
-This API group contains the following Crossplane resources:
-
-* [KubernetesCluster](#KubernetesCluster)
-* [KubernetesClusterClass](#KubernetesClusterClass)
-
-## KubernetesCluster
-
-A KubernetesCluster is a portable resource claim that may be satisfied by binding to a Kubernetes cluster managed resource such as an AWS EKS cluster or an Azure AKS cluster.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.crossplane.io/v1alpha1`
-`kind` | string | `KubernetesCluster`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [KubernetesClusterSpec](#KubernetesClusterSpec) | KubernetesClusterSpec specifies the desired state of a KubernetesCluster.
-`status` | [v1alpha1.ResourceClaimStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimstatus) |
-
-
-
-## KubernetesClusterClass
-
-KubernetesClusterClass contains a namespace-scoped Class for KubernetesCluster
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.crossplane.io/v1alpha1`
-`kind` | string | `KubernetesClusterClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-
-
-KubernetesClusterClass supports all fields of:
-
-* [v1alpha1.PortableClass](../crossplane-runtime/core-crossplane-io-v1alpha1.md#portableclass)
-
-
-## KubernetesClusterSpec
-
-KubernetesClusterSpec specifies the desired state of a KubernetesCluster.
-
-Appears in:
-
-* [KubernetesCluster](#KubernetesCluster)
-
-
-Name | Type | Description
------|------|------------
-`clusterVersion` | string | ClusterVersion specifies the desired Kubernetes version, e.g. 1.15.
-
-
-KubernetesClusterSpec supports all fields of:
-
-* [v1alpha1.ResourceClaimSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimspec)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/crossplane/database-crossplane-io-v1alpha1.md b/docs/v0.3/api/crossplaneio/crossplane/database-crossplane-io-v1alpha1.md
deleted file mode 100644
index 093f0999..00000000
--- a/docs/v0.3/api/crossplaneio/crossplane/database-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,114 +0,0 @@
-# database.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains portable resource claims for database services such as MySQL or PostgreSQL.
-
-This API group contains the following Crossplane resources:
-
-* [MySQLInstance](#MySQLInstance)
-* [MySQLInstanceClass](#MySQLInstanceClass)
-* [PostgreSQLInstance](#PostgreSQLInstance)
-* [PostgreSQLInstanceClass](#PostgreSQLInstanceClass)
-
-## MySQLInstance
-
-A MySQLInstance is a portable resource claim that may be satisfied by binding to a MySQL managed resource such as an AWS RDS instance or a GCP CloudSQL instance.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.crossplane.io/v1alpha1`
-`kind` | string | `MySQLInstance`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [MySQLInstanceSpec](#MySQLInstanceSpec) | MySQLInstanceSpec specifies the desired state of a MySQLInstance.
-`status` | [v1alpha1.ResourceClaimStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimstatus) |
-
-
-
-## MySQLInstanceClass
-
-MySQLInstanceClass contains a namespace-scoped portable class for MySQLInstance
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.crossplane.io/v1alpha1`
-`kind` | string | `MySQLInstanceClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-
-
-MySQLInstanceClass supports all fields of:
-
-* [v1alpha1.PortableClass](../crossplane-runtime/core-crossplane-io-v1alpha1.md#portableclass)
-
-
-## PostgreSQLInstance
-
-A PostgreSQLInstance is a portable resource claim that may be satisfied by binding to a PostgreSQL managed resource such as an AWS RDS instance or a GCP CloudSQL instance. PostgreSQLInstance is the CRD type for abstract PostgreSQL database instances
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.crossplane.io/v1alpha1`
-`kind` | string | `PostgreSQLInstance`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [PostgreSQLInstanceSpec](#PostgreSQLInstanceSpec) | PostgreSQLInstanceSpec specifies the desired state of a PostgreSQLInstance. PostgreSQLInstance.
-`status` | [v1alpha1.ResourceClaimStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimstatus) |
-
-
-
-## PostgreSQLInstanceClass
-
-PostgreSQLInstanceClass contains a namespace-scoped portable class for PostgreSQLInstance
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.crossplane.io/v1alpha1`
-`kind` | string | `PostgreSQLInstanceClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-
-
-PostgreSQLInstanceClass supports all fields of:
-
-* [v1alpha1.PortableClass](../crossplane-runtime/core-crossplane-io-v1alpha1.md#portableclass)
-
-
-## MySQLInstanceSpec
-
-MySQLInstanceSpec specifies the desired state of a MySQLInstance.
-
-Appears in:
-
-* [MySQLInstance](#MySQLInstance)
-
-
-Name | Type | Description
------|------|------------
-`engineVersion` | string | EngineVersion specifies the desired MySQL engine version, e.g. 5.7.
-
-
-MySQLInstanceSpec supports all fields of:
-
-* [v1alpha1.ResourceClaimSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimspec)
-
-
-## PostgreSQLInstanceSpec
-
-PostgreSQLInstanceSpec specifies the desired state of a PostgreSQLInstance. PostgreSQLInstance.
-
-Appears in:
-
-* [PostgreSQLInstance](#PostgreSQLInstance)
-
-
-Name | Type | Description
------|------|------------
-`engineVersion` | string | EngineVersion specifies the desired PostgreSQL engine version, e.g. 9.6.
-
-
-PostgreSQLInstanceSpec supports all fields of:
-
-* [v1alpha1.ResourceClaimSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimspec)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/crossplane/stacks-crossplane-io-v1alpha1.md b/docs/v0.3/api/crossplaneio/crossplane/stacks-crossplane-io-v1alpha1.md
deleted file mode 100644
index 3359301d..00000000
--- a/docs/v0.3/api/crossplaneio/crossplane/stacks-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,260 +0,0 @@
-# stacks.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains resources relating to Crossplane Stacks.
-
-This API group contains the following Crossplane resources:
-
-* [ClusterStackInstall](#ClusterStackInstall)
-* [Stack](#Stack)
-* [StackInstall](#StackInstall)
-
-## ClusterStackInstall
-
-ClusterStackInstall is the CRD type for a request to add a stack to Crossplane.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `stacks.crossplane.io/v1alpha1`
-`kind` | string | `ClusterStackInstall`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [StackInstallSpec](#StackInstallSpec) | StackInstallSpec specifies details about a request to install a stack to Crossplane.
-`status` | [StackInstallStatus](#StackInstallStatus) | StackInstallStatus represents the observed state of a StackInstall.
-
-
-
-## Stack
-
-A Stack that has been added to Crossplane.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `stacks.crossplane.io/v1alpha1`
-`kind` | string | `Stack`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [StackSpec](#StackSpec) | StackSpec specifies the desired state of a Stack.
-`status` | [StackStatus](#StackStatus) | StackStatus represents the observed state of a Stack.
-
-
-
-## StackInstall
-
-A StackInstall requests a stack be installed to Crossplane.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `stacks.crossplane.io/v1alpha1`
-`kind` | string | `StackInstall`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [StackInstallSpec](#StackInstallSpec) | StackInstallSpec specifies details about a request to install a stack to Crossplane.
-`status` | [StackInstallStatus](#StackInstallStatus) | StackInstallStatus represents the observed state of a StackInstall.
-
-
-
-## AppMetadataSpec
-
-AppMetadataSpec defines metadata about the stack application
-
-Appears in:
-
-* [StackSpec](#StackSpec)
-
-
-Name | Type | Description
------|------|------------
-`title` | string |
-`overviewShort` | string |
-`overview` | string |
-`readme` | string |
-`version` | string |
-`icons` | [[]IconSpec](#IconSpec) |
-`maintainers` | [[]ContributorSpec](#ContributorSpec) |
-`owners` | [[]ContributorSpec](#ContributorSpec) |
-`company` | string |
-`category` | string |
-`keywords` | []string |
-`website` | string |
-`source` | string |
-`license` | string |
-`dependsOn` | [[]StackInstallSpec](#StackInstallSpec) | DependsOn is the list of CRDs that this stack depends on. This data drives the dependency resolution process.
-`permissionScope` | string |
-
-
-
-## ContributorSpec
-
-ContributorSpec defines a contributor for a stack (e.g., maintainer, owner, etc.)
-
-Appears in:
-
-* [AppMetadataSpec](#AppMetadataSpec)
-
-
-Name | Type | Description
------|------|------------
-`name` | string |
-`email` | string |
-
-
-
-## ControllerDeployment
-
-ControllerDeployment defines a controller for a stack that is managed by a Deployment.
-
-Appears in:
-
-* [ControllerSpec](#ControllerSpec)
-
-
-Name | Type | Description
------|------|------------
-`name` | string |
-`spec` | [apps/v1.DeploymentSpec](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#deploymentspec-v1-apps) |
-
-
-
-## ControllerJob
-
-ControllerJob defines a controller for a stack that is installed by a Job.
-
-Appears in:
-
-* [ControllerSpec](#ControllerSpec)
-
-
-Name | Type | Description
------|------|------------
-`name` | string |
-`spec` | [batch/v1.JobSpec](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#jobspec-v1-batch) |
-
-
-
-## ControllerSpec
-
-ControllerSpec defines the controller that implements the logic for a stack, which can come in different flavors. A golang code (controller-runtime) controller with a managing Deployment is all that is supported currently, but more types will come in the future (e.g., templates, functions/hooks, templates, a new DSL, etc.
-
-Appears in:
-
-* [StackSpec](#StackSpec)
-
-
-Name | Type | Description
------|------|------------
-`deployment` | [ControllerDeployment](#ControllerDeployment) |
-`job` | [ControllerJob](#ControllerJob) |
-
-
-
-## IconSpec
-
-IconSpec defines the icon for a stack
-
-Appears in:
-
-* [AppMetadataSpec](#AppMetadataSpec)
-
-
-Name | Type | Description
------|------|------------
-`base64Data` | string |
-`mediatype` | string |
-
-
-
-## PermissionsSpec
-
-PermissionsSpec defines the permissions that a stack will require to operate.
-
-Appears in:
-
-* [StackSpec](#StackSpec)
-
-
-Name | Type | Description
------|------|------------
-`rules` | [[]rbac/v1.PolicyRule](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#policyrule-v1-rbac) |
-
-
-
-## StackInstallSpec
-
-StackInstallSpec specifies details about a request to install a stack to Crossplane.
-
-Appears in:
-
-* [ClusterStackInstall](#ClusterStackInstall)
-* [StackInstall](#StackInstall)
-* [AppMetadataSpec](#AppMetadataSpec)
-
-
-Name | Type | Description
------|------|------------
-`source` | string | Source is the domain name for the stack registry hosting the stack being requested, e.g., registry.crossplane.io
-`package` | string | Package is the name of the stack package that is being requested, e.g., myapp. Either Package or CustomResourceDefinition can be specified.
-`crd` | string | CustomResourceDefinition is the full name of a CRD that is owned by the stack being requested. This can be a convenient way of installing a stack when the desired CRD is known, but the package name that contains it is not known. Either Package or CustomResourceDefinition can be specified.
-
-
-
-## StackInstallStatus
-
-StackInstallStatus represents the observed state of a StackInstall.
-
-Appears in:
-
-* [ClusterStackInstall](#ClusterStackInstall)
-* [StackInstall](#StackInstall)
-
-
-Name | Type | Description
------|------|------------
-`conditionedStatus` | [v1alpha1.ConditionedStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#conditionedstatus) |
-`installJob` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) |
-`stackRecord` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) |
-
-
-
-## StackInstaller
-
-StackInstaller provides a common interface for StackInstall and ClusterStackInstall to share controller and reconciler logic
-
-
-## StackSpec
-
-StackSpec specifies the desired state of a Stack.
-
-Appears in:
-
-* [Stack](#Stack)
-
-
-Name | Type | Description
------|------|------------
-`customresourcedefinitions` | [CRDList](#CRDList) | CRDList is the full list of CRDs that this stack owns and depends on
-`controller` | [ControllerSpec](#ControllerSpec) | ControllerSpec defines the controller that implements the logic for a stack, which can come in different flavors. A golang code (controller-runtime) controller with a managing Deployment is all that is supported currently, but more types will come in the future (e.g., templates, functions/hooks, templates, a new DSL, etc.
-`permissions` | [PermissionsSpec](#PermissionsSpec) | PermissionsSpec defines the permissions that a stack will require to operate.
-
-
-StackSpec supports all fields of:
-
-* [AppMetadataSpec](#AppMetadataSpec)
-
-
-## StackStatus
-
-StackStatus represents the observed state of a Stack.
-
-Appears in:
-
-* [Stack](#Stack)
-
-
-Name | Type | Description
------|------|------------
-`conditionedStatus` | [v1alpha1.ConditionedStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#conditionedstatus) |
-`controllerRef` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) |
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/crossplane/storage-crossplane-io-v1alpha1.md b/docs/v0.3/api/crossplaneio/crossplane/storage-crossplane-io-v1alpha1.md
deleted file mode 100644
index dcb081cf..00000000
--- a/docs/v0.3/api/crossplaneio/crossplane/storage-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,81 +0,0 @@
-# storage.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains portable resource claims for storage services such as buckets.
-
-This API group contains the following Crossplane resources:
-
-* [Bucket](#Bucket)
-* [BucketClass](#BucketClass)
-
-## Bucket
-
-A Bucket is a portable resource claim that may be satisfied by binding to a storage bucket PostgreSQL managed resource such as an AWS S3 bucket or Azure storage container.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.crossplane.io/v1alpha1`
-`kind` | string | `Bucket`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [BucketSpec](#BucketSpec) | BucketSpec specifies the desired state of a Bucket.
-`status` | [v1alpha1.ResourceClaimStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimstatus) |
-
-
-
-## BucketClass
-
-BucketClass contains a namespace-scoped portable class for Bucket
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.crossplane.io/v1alpha1`
-`kind` | string | `BucketClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-
-
-BucketClass supports all fields of:
-
-* [v1alpha1.PortableClass](../crossplane-runtime/core-crossplane-io-v1alpha1.md#portableclass)
-
-
-## BucketSpec
-
-BucketSpec specifies the desired state of a Bucket.
-
-Appears in:
-
-* [Bucket](#Bucket)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name specifies the desired name of the bucket.
-`predefinedACL` | [PredefinedACL](#PredefinedACL) | PredefinedACL specifies a predefined ACL (e.g. Private, ReadWrite, etc) to be applied to the bucket.
-`localPermission` | [LocalPermissionType](#LocalPermissionType) | LocalPermission specifies permissions granted to a provider specific service account for this bucket, e.g. Read, ReadWrite, or Write.
-
-
-BucketSpec supports all fields of:
-
-* [v1alpha1.ResourceClaimSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimspec)
-
-
-## LocalPermissionType
-
-A LocalPermissionType is a type of permission that may be granted to a Bucket. Alias of string.
-
-Appears in:
-
-* [BucketSpec](#BucketSpec)
-
-
-## PredefinedACL
-
-A PredefinedACL is a predefined ACL that may be applied to a Bucket. Alias of string.
-
-Appears in:
-
-* [BucketSpec](#BucketSpec)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/crossplane/workload-crossplane-io-v1alpha1.md b/docs/v0.3/api/crossplaneio/crossplane/workload-crossplane-io-v1alpha1.md
deleted file mode 100644
index a9ee2a4c..00000000
--- a/docs/v0.3/api/crossplaneio/crossplane/workload-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,160 +0,0 @@
-# workload.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains resources relating to Crossplane Workloads.
-
-This API group contains the following Crossplane resources:
-
-* [KubernetesApplication](#KubernetesApplication)
-* [KubernetesApplicationResource](#KubernetesApplicationResource)
-
-## KubernetesApplication
-
-A KubernetesApplication defines an application deployed by Crossplane to a Kubernetes cluster, i.e. a portable KubernetesCluster resource claim.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `workload.crossplane.io/v1alpha1`
-`kind` | string | `KubernetesApplication`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [KubernetesApplicationSpec](#KubernetesApplicationSpec) | A KubernetesApplicationSpec specifies the resources of a Kubernetes application.
-`status` | [KubernetesApplicationStatus](#KubernetesApplicationStatus) | KubernetesApplicationStatus represents the observed state of a KubernetesApplication.
-
-
-
-## KubernetesApplicationResource
-
-A KubernetesApplicationResource is a resource of a Kubernetes application. Each resource templates a single Kubernetes resource to be deployed to its scheduled KubernetesCluster.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `workload.crossplane.io/v1alpha1`
-`kind` | string | `KubernetesApplicationResource`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [KubernetesApplicationResourceSpec](#KubernetesApplicationResourceSpec) | KubernetesApplicationResourceSpec specifies the desired state of a KubernetesApplicationResource.
-`status` | [KubernetesApplicationResourceStatus](#KubernetesApplicationResourceStatus) | KubernetesApplicationResourceStatus represents the observed state of a KubernetesApplicationResource.
-
-
-
-## KubernetesApplicationResourceSpec
-
-KubernetesApplicationResourceSpec specifies the desired state of a KubernetesApplicationResource.
-
-Appears in:
-
-* [KubernetesApplicationResource](#KubernetesApplicationResource)
-* [KubernetesApplicationResourceTemplate](#KubernetesApplicationResourceTemplate)
-
-
-Name | Type | Description
------|------|------------
-`template` | [meta/v1/unstructured.Unstructured](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#unstructured-unstructured-v1) | A Template for a Kubernetes resource to be submitted to the KubernetesCluster to which this application resource is scheduled. The resource must be understood by the KubernetesCluster. Crossplane requires only that the resource contains standard Kubernetes type and object metadata.
-`secrets` | [[]core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core) | Secrets upon which this application resource depends. These secrets will be propagated to the Kubernetes cluster to which this application is scheduled.
-
-
-
-## KubernetesApplicationResourceState
-
-KubernetesApplicationResourceState represents the state of a KubernetesApplicationResource. Alias of string.
-
-Appears in:
-
-* [KubernetesApplicationResourceStatus](#KubernetesApplicationResourceStatus)
-
-
-## KubernetesApplicationResourceStatus
-
-KubernetesApplicationResourceStatus represents the observed state of a KubernetesApplicationResource.
-
-Appears in:
-
-* [KubernetesApplicationResource](#KubernetesApplicationResource)
-
-
-Name | Type | Description
------|------|------------
-`conditionedStatus` | [v1alpha1.ConditionedStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#conditionedstatus) |
-`state` | [KubernetesApplicationResourceState](#KubernetesApplicationResourceState) | State of the application.
-`clusterRef` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | Cluster to which this application has been scheduled.
-`remote` | [RemoteStatus](#RemoteStatus) | Remote status of the resource templated by this application resource.
-
-
-
-## KubernetesApplicationResourceTemplate
-
-A KubernetesApplicationResourceTemplate is used to instantiate new KubernetesApplicationResources.
-
-Appears in:
-
-* [KubernetesApplicationSpec](#KubernetesApplicationSpec)
-
-
-Name | Type | Description
------|------|------------
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [KubernetesApplicationResourceSpec](#KubernetesApplicationResourceSpec) | KubernetesApplicationResourceSpec specifies the desired state of a KubernetesApplicationResource.
-
-
-
-## KubernetesApplicationSpec
-
-A KubernetesApplicationSpec specifies the resources of a Kubernetes application.
-
-Appears in:
-
-* [KubernetesApplication](#KubernetesApplication)
-
-
-Name | Type | Description
------|------|------------
-`resourceSelector` | [meta/v1.LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#labelselector-v1-meta) | ResourceSelector selects the KubernetesApplicationResources that are managed by this KubernetesApplication. Note that a KubernetesApplication will never adopt orphaned KubernetesApplicationResources, and thus this selector serves only to help match a KubernetesApplication to its KubernetesApplicationResources.
-`clusterSelector` | [meta/v1.LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#labelselector-v1-meta) | ClusterSelector selects the clusters to which this application may be scheduled. Leave both match labels and expressions empty to match any cluster.
-`resourceTemplates` | [[]KubernetesApplicationResourceTemplate](#KubernetesApplicationResourceTemplate) | ResourceTemplates specifies a set of Kubernetes application resources managed by this application.
-
-
-
-## KubernetesApplicationState
-
-KubernetesApplicationState represents the state of a Kubernetes application. Alias of string.
-
-Appears in:
-
-* [KubernetesApplicationStatus](#KubernetesApplicationStatus)
-
-
-## KubernetesApplicationStatus
-
-KubernetesApplicationStatus represents the observed state of a KubernetesApplication.
-
-Appears in:
-
-* [KubernetesApplication](#KubernetesApplication)
-
-
-Name | Type | Description
------|------|------------
-`conditionedStatus` | [v1alpha1.ConditionedStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#conditionedstatus) |
-`state` | [KubernetesApplicationState](#KubernetesApplicationState) | State of the application.
-`clusterRef` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | Cluster to which this application has been scheduled.
-`desiredResources` | int | Desired resources of this application, i.e. the number of resources that match this application's resource selector.
-`submittedResources` | int | Submitted resources of this workload, i.e. the subset of desired resources that have been successfully submitted to their scheduled Kubernetes cluster.
-
-
-
-## RemoteStatus
-
-RemoteStatus represents the observed state of a remote cluster.
-
-Appears in:
-
-* [KubernetesApplicationResourceStatus](#KubernetesApplicationResourceStatus)
-
-
-Name | Type | Description
------|------|------------
-`raw` | [encoding/json.RawMessage](https://golang.org/pkg/encoding/json#RawMessage) | Raw JSON representation of the remote status as a byte array.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-aws/aws-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-aws/aws-crossplane-io-v1alpha2.md
deleted file mode 100644
index 078901dc..00000000
--- a/docs/v0.3/api/crossplaneio/stack-aws/aws-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# aws.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains core AWS resources.
-
-This API group contains the following Crossplane resources:
-
-* [Provider](#Provider)
-
-## Provider
-
-A Provider configures an AWS 'provider', i.e. a connection to a particular AWS account using a particular AWS IAM role.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `aws.crossplane.io/v1alpha2`
-`kind` | string | `Provider`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ProviderSpec](#ProviderSpec) | A ProviderSpec defines the desired state of a Provider.
-
-
-
-## ProviderSpec
-
-A ProviderSpec defines the desired state of a Provider.
-
-Appears in:
-
-* [Provider](#Provider)
-
-
-Name | Type | Description
------|------|------------
-`region` | string | Region for managed resources created using this AWS provider.
-`credentialsSecretRef` | [core/v1.SecretKeySelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#secretkeyselector-v1-core) | A Secret containing INI encoded credentials for an AWS IAM role that will be used to authenticate to this AWS account.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-aws/cache-aws-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-aws/cache-aws-crossplane-io-v1alpha2.md
deleted file mode 100644
index 2eb757a4..00000000
--- a/docs/v0.3/api/crossplaneio/stack-aws/cache-aws-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,163 +0,0 @@
-# cache.aws.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for AWS caching services such as ElastiCache.
-
-This API group contains the following Crossplane resources:
-
-* [ReplicationGroup](#ReplicationGroup)
-* [ReplicationGroupClass](#ReplicationGroupClass)
-
-## ReplicationGroup
-
-A ReplicationGroup is a managed resource that represents an AWS ElastiCache Replication Group.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.aws.crossplane.io/v1alpha2`
-`kind` | string | `ReplicationGroup`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ReplicationGroupSpec](#ReplicationGroupSpec) | A ReplicationGroupSpec defines the desired state of a ReplicationGroup.
-`status` | [ReplicationGroupStatus](#ReplicationGroupStatus) | A ReplicationGroupStatus defines the observed state of a ReplicationGroup.
-
-
-
-## ReplicationGroupClass
-
-A ReplicationGroupClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.aws.crossplane.io/v1alpha2`
-`kind` | string | `ReplicationGroupClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [ReplicationGroupClassSpecTemplate](#ReplicationGroupClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned ReplicationGroup.
-
-
-
-## MinorVersion
-
-MinorVersion represents a supported minor version of Redis. Alias of string.
-
-
-## NodeGroupConfigurationSpec
-
-A NodeGroupConfigurationSpec specifies the desired state of a node group.
-
-Appears in:
-
-* [ReplicationGroupParameters](#ReplicationGroupParameters)
-
-
-Name | Type | Description
------|------|------------
-`primaryAvailabilityZone` | Optional string | PrimaryAvailabilityZone specifies the Availability Zone where the primary node of this node group (shard) is launched.
-`replicaAvailabilityZones` | Optional []string | ReplicaAvailabilityZones specifies a list of Availability Zones to be used for the read replicas. The number of Availability Zones in this list must match the value of ReplicaCount or ReplicasPerNodeGroup if not specified.
-`replicaCount` | Optional int | ReplicaCount specifies the number of read replica nodes in this node group (shard).
-`slots` | Optional string | Slots specifies the keyspace for a particular node group. Keyspaces range from 0 to 16,383. The string is in the format startkey-endkey. Example: "0-3999"
-
-
-
-## PatchVersion
-
-PatchVersion represents a supported patch version of Redis. Alias of string.
-
-
-## ReplicationGroupClassSpecTemplate
-
-A ReplicationGroupClassSpecTemplate is a template for the spec of a dynamically provisioned ReplicationGroup.
-
-Appears in:
-
-* [ReplicationGroupClass](#ReplicationGroupClass)
-
-
-
-
-ReplicationGroupClassSpecTemplate supports all fields of:
-
-* [v1alpha1.NonPortableClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#nonportableclassspectemplate)
-* [ReplicationGroupParameters](#ReplicationGroupParameters)
-
-
-## ReplicationGroupParameters
-
-ReplicationGroupParameters define the desired state of an AWS ElastiCache Replication Group. Most fields map directly to an AWS ReplicationGroup: https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html#API_CreateReplicationGroup_RequestParameters
-
-Appears in:
-
-* [ReplicationGroupClassSpecTemplate](#ReplicationGroupClassSpecTemplate)
-* [ReplicationGroupSpec](#ReplicationGroupSpec)
-
-
-Name | Type | Description
------|------|------------
-`atRestEncryptionEnabled` | Optional bool | AtRestEncryptionEnabled enables encryption at rest when set to true. You cannot modify the value of AtRestEncryptionEnabled after the replication group is created. To enable encryption at rest on a replication group you must set AtRestEncryptionEnabled to true when you create the replication group.
-`authEnabled` | Optional bool | AuthEnabled enables mandatory authentication when connecting to the managed replication group. AuthEnabled requires TransitEncryptionEnabled to be true. While ReplicationGroupSpec mirrors the fields of the upstream replication group object as closely as possible, we expose a boolean here rather than requiring the operator pass in a string authentication token. Crossplane will generate a token automatically and expose it via a Secret.
-`automaticFailoverEnabled` | Optional bool | AutomaticFailoverEnabled specifies whether a read-only replica is automatically promoted to read/write primary if the existing primary fails. If true, Multi-AZ is enabled for this replication group. If false, Multi-AZ is disabled for this replication group. AutomaticFailoverEnabled must be enabled for Redis (cluster mode enabled) replication groups.
-`cacheNodeType` | string | CacheNodeType specifies the compute and memory capacity of the nodes in the node group (shard).
-`cacheParameterGroupName` | Optional string | CacheParameterGroupName specifies the name of the parameter group to associate with this replication group. If this argument is omitted, the default cache parameter group for the specified engine is used.
-`cacheSecurityGroupNames` | Optional []string | CacheSecurityGroupNames specifies a list of cache security group names to associate with this replication group.
-`cacheSubnetGroupName` | Optional string | CacheSubnetGroupName specifies the name of the cache subnet group to be used for the replication group. If you're going to launch your cluster in an Amazon VPC, you need to create a subnet group before you start creating a cluster.
-`engineVersion` | Optional string | EngineVersion specifies the version number of the cache engine to be used for the clusters in this replication group. To view the supported cache engine versions, use the DescribeCacheEngineVersions operation.
-`nodeGroupConfiguration` | Optional [[]NodeGroupConfigurationSpec](#NodeGroupConfigurationSpec) | NodeGroupConfiguration specifies a list of node group (shard) configuration options.
-`notificationTopicArn` | Optional string | NotificationTopicARN specifies the Amazon Resource Name (ARN) of the Amazon Simple Notification Service (SNS) topic to which notifications are sent. The Amazon SNS topic owner must be the same as the cluster owner.
-`numCacheClusters` | Optional int | NumCacheClusters specifies the number of clusters this replication group initially has. This parameter is not used if there is more than one node group (shard). You should use ReplicasPerNodeGroup instead. If AutomaticFailoverEnabled is true, the value of this parameter must be at least 2. If AutomaticFailoverEnabled is false you can omit this parameter (it will default to 1), or you can explicitly set it to a value between 2 and 6.
-`numNodeGroups` | Optional int | NumNodeGroups specifies the number of node groups (shards) for this Redis (cluster mode enabled) replication group. For Redis (cluster mode disabled) either omit this parameter or set it to 1.
-`port` | Optional int | Port number on which each member of the replication group accepts connections.
-`preferredCacheClusterAzs` | Optional []string | PreferredCacheClusterAZs specifies a list of EC2 Availability Zones in which the replication group's clusters are created. The order of the Availability Zones in the list is the order in which clusters are allocated. The primary cluster is created in the first AZ in the list. This parameter is not used if there is more than one node group (shard). You should use NodeGroupConfiguration instead. The number of Availability Zones listed must equal the value of NumCacheClusters.
-`preferredMaintenanceWindow` | Optional string | PreferredMaintenanceWindow specifies the weekly time range during which maintenance on the cluster is performed. It is specified as a range in the format ddd:hh24:mi-ddd:hh24:mi (24H Clock UTC). The minimum maintenance window is a 60 minute period. Example: sun:23:00-mon:01:30
-`replicasPerNodeGroup` | Optional int | ReplicasPerNodeGroup specifies the number of replica nodes in each node group (shard). Valid values are 0 to 5.
-`securityGroupIds` | Optional []string | SecurityGroupIDs specifies one or more Amazon VPC security groups associated with this replication group. Use this parameter only when you are creating a replication group in an Amazon VPC.
-`snapshotArns` | Optional []string | SnapshotARNs specifies a list of Amazon Resource Names (ARN) that uniquely identify the Redis RDB snapshot files stored in Amazon S3. The snapshot files are used to populate the new replication group. The Amazon S3 object name in the ARN cannot contain any commas. The new replication group will have the number of node groups (console: shards) specified by the parameter NumNodeGroups or the number of node groups configured by NodeGroupConfiguration regardless of the number of ARNs specified here.
-`snapshotName` | Optional string | SnapshotName specifies the name of a snapshot from which to restore data into the new replication group. The snapshot status changes to restoring while the new replication group is being created.
-`snapshotRetentionLimit` | Optional int | SnapshotRetentionLimit specifies the number of days for which ElastiCache retains automatic snapshots before deleting them. For example, if you set SnapshotRetentionLimit to 5, a snapshot that was taken today is retained for 5 days before being deleted.
-`snapshotWindow` | Optional string | SnapshotWindow specifies the daily time range (in UTC) during which ElastiCache begins taking a daily snapshot of your node group (shard). Example: 05:00-09:00 If you do not specify this parameter, ElastiCache automatically chooses an appropriate time range.
-`transitEncryptionEnabled` | Optional bool | TransitEncryptionEnabled enables in-transit encryption when set to true. You cannot modify the value of TransitEncryptionEnabled after the cluster is created. To enable in-transit encryption on a cluster you must TransitEncryptionEnabled to true when you create a cluster.
-
-
-
-## ReplicationGroupSpec
-
-A ReplicationGroupSpec defines the desired state of a ReplicationGroup.
-
-Appears in:
-
-* [ReplicationGroup](#ReplicationGroup)
-
-
-
-
-ReplicationGroupSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [ReplicationGroupParameters](#ReplicationGroupParameters)
-
-
-## ReplicationGroupStatus
-
-A ReplicationGroupStatus defines the observed state of a ReplicationGroup.
-
-Appears in:
-
-* [ReplicationGroup](#ReplicationGroup)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State of the Replication Group.
-`providerID` | string | ProviderID is the external ID to identify this resource in the cloud provider
-`endpoint` | string | Endpoint of the Replication Group used in connection strings.
-`port` | int | Port at which the Replication Group endpoint is listening.
-`clusterEnabled` | bool | ClusterEnabled indicates whether cluster mode is enabled, i.e. whether this replication group's data can be partitioned across multiple shards.
-`memberClusters` | []string | MemberClusters that are part of this replication group.
-`groupName` | string | Groupname of the Replication Group.
-
-
-ReplicationGroupStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-aws/compute-aws-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-aws/compute-aws-crossplane-io-v1alpha2.md
deleted file mode 100644
index c5827b7b..00000000
--- a/docs/v0.3/api/crossplaneio/stack-aws/compute-aws-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,186 +0,0 @@
-# compute.aws.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for AWS compute services such as EKS.
-
-This API group contains the following Crossplane resources:
-
-* [EKSCluster](#EKSCluster)
-* [EKSClusterClass](#EKSClusterClass)
-
-## EKSCluster
-
-An EKSCluster is a managed resource that represents an AWS Elastic Kubernetes Service cluster.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.aws.crossplane.io/v1alpha2`
-`kind` | string | `EKSCluster`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [EKSClusterSpec](#EKSClusterSpec) | An EKSClusterSpec defines the desired state of an EKSCluster.
-`status` | [EKSClusterStatus](#EKSClusterStatus) | An EKSClusterStatus represents the observed state of an EKSCluster.
-
-
-
-## EKSClusterClass
-
-An EKSClusterClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.aws.crossplane.io/v1alpha2`
-`kind` | string | `EKSClusterClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [EKSClusterClassSpecTemplate](#EKSClusterClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned EKSCluster.
-
-
-
-## EKSClusterClassSpecTemplate
-
-An EKSClusterClassSpecTemplate is a template for the spec of a dynamically provisioned EKSCluster.
-
-Appears in:
-
-* [EKSClusterClass](#EKSClusterClass)
-
-
-
-
-EKSClusterClassSpecTemplate supports all fields of:
-
-* [v1alpha1.NonPortableClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#nonportableclassspectemplate)
-* [EKSClusterParameters](#EKSClusterParameters)
-
-
-## EKSClusterParameters
-
-EKSClusterParameters define the desired state of an AWS Elastic Kubernetes Service cluster.
-
-Appears in:
-
-* [EKSClusterClassSpecTemplate](#EKSClusterClassSpecTemplate)
-* [EKSClusterSpec](#EKSClusterSpec)
-
-
-Name | Type | Description
------|------|------------
-`region` | [EKSRegion](#EKSRegion) | Region for this EKS Cluster.
-`roleARN` | string | RoleARN: The Amazon Resource Name (ARN) of the IAM role that provides permis sions for Amazon EKS to make calls to other AWS API operations on your behalf. For more information, see 'Amazon EKS Service IAM Role' in the Amazon EKS User Guide.
-`vpcId` | string | VpcID of this EKS cluster.
-`subnetIds` | []string | SubnetIds of this EKS cluster.
-`securityGroupIds` | []string | SecurityGroupIds of this EKS cluster.
-`clusterVersion` | Optional string | ClusterVersion: The desired Kubernetes version of this EKS Cluster. If you do not specify a value here, the latest version available is used.
-`workerNodes` | [WorkerNodesSpec](#WorkerNodesSpec) | WorkerNodes configuration for cloudformation
-`mapRoles` | Optional [[]MapRole](#MapRole) | MapRoles map AWS roles to one or more Kubernetes groups. A Default role that allows nodes access to communicate with master is autogenerated when a node pool comes online.
-`mapUsers` | Optional [[]MapUser](#MapUser) | MapUsers map AWS users to one or more Kubernetes groups.
-
-
-
-## EKSClusterSpec
-
-An EKSClusterSpec defines the desired state of an EKSCluster.
-
-Appears in:
-
-* [EKSCluster](#EKSCluster)
-
-
-
-
-EKSClusterSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [EKSClusterParameters](#EKSClusterParameters)
-
-
-## EKSClusterStatus
-
-An EKSClusterStatus represents the observed state of an EKSCluster.
-
-Appears in:
-
-* [EKSCluster](#EKSCluster)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State of the cluster.
-`resourceName` | string | ClusterName of the cluster.
-`resourceVersion` | string | ClusterVersion of the cluster.
-`endpoint` | string | Endpoint for connecting to the cluster.
-`cloudformationStackId` | string | CloudFormationStackID of the Stack used to create node groups.
-
-
-EKSClusterStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## EKSRegion
-
-EKSRegion represents an EKS enabled AWS region. Alias of string.
-
-Appears in:
-
-* [EKSClusterParameters](#EKSClusterParameters)
-
-
-## MapRole
-
-MapRole maps an AWS IAM role to one or more Kubernetes groups. See https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html and https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/README.md
-
-Appears in:
-
-* [EKSClusterParameters](#EKSClusterParameters)
-
-
-Name | Type | Description
------|------|------------
-`rolearn` | string | RoleARN to match, e.g. 'arn:aws:iam::000000000000:role/KubernetesNode'.
-`username` | string | Username (in Kubernetes) the RoleARN should map to.
-`groups` | []string | Groups (in Kubernetes) the RoleARN should map to.
-
-
-
-## MapUser
-
-MapUser maps an AWS IAM user to one or more Kubernetes groups. See https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html and https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/README.md
-
-Appears in:
-
-* [EKSClusterParameters](#EKSClusterParameters)
-
-
-Name | Type | Description
------|------|------------
-`userarn` | string | UserARN to match, e.g. 'arn:aws:iam::000000000000:user/Alice'
-`username` | string | Username (in Kubernetes) the UserARN should map to.
-`groups` | []string | Groups (in Kubernetes) the UserARN should map to.
-
-
-
-## WorkerNodesSpec
-
-WorkerNodesSpec - Worker node spec used to define cloudformation template that provisions workers for cluster
-
-Appears in:
-
-* [EKSClusterParameters](#EKSClusterParameters)
-
-
-Name | Type | Description
------|------|------------
-`keyName` | Optional string | KeyName of the EC2 Key Pair to allow SSH access to the EC2 instances.
-`nodeImageId` | Optional string | NodeImageId that the EC2 instances should run. Defaults to the region's standard AMI.
-`nodeInstanceType` | string | NodeInstanceType of the EC2 instances.
-`nodeAutoScalingGroupMinSize` | Optional int | NodeAutoScalingGroupMinSize configures the minimum size of this node group's Autoscaling Group. Defaults to 1.
-`nodeAutoScalingGroupMaxSize` | Optional int | NodeAutoScalingGroupMaxSize configures the maximum size of this node group's Autoscaling Group. Defaults to 3.
-`nodeVolumeSize` | Optional int | NodeVolumeSize configures the volume size in GB. Defaults to 20.
-`bootstrapArguments` | Optional string | BootstrapArguments to pass to the bootstrap script. See files/bootstrap.sh in https://github.com/awslabs/amazon-eks-ami
-`nodeGroupName` | Optional string | NodeGroupName is a unique identifier for the Node Group.
-`clusterControlPlaneSecurityGroup` | Optional string | ClusterControlPlaneSecurityGroup configures the security group of the cluster control plane in order to allow communication to this node group.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-aws/database-aws-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-aws/database-aws-crossplane-io-v1alpha2.md
deleted file mode 100644
index 6168c699..00000000
--- a/docs/v0.3/api/crossplaneio/stack-aws/database-aws-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,122 +0,0 @@
-# database.aws.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for AWS database services such as RDS.
-
-This API group contains the following Crossplane resources:
-
-* [RDSInstance](#RDSInstance)
-* [RDSInstanceClass](#RDSInstanceClass)
-
-## RDSInstance
-
-An RDSInstance is a managed resource that represents an AWS Relational Database Service instance.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.aws.crossplane.io/v1alpha2`
-`kind` | string | `RDSInstance`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [RDSInstanceSpec](#RDSInstanceSpec) | An RDSInstanceSpec defines the desired state of an RDSInstance.
-`status` | [RDSInstanceStatus](#RDSInstanceStatus) | An RDSInstanceStatus represents the observed state of an RDSInstance.
-
-
-
-## RDSInstanceClass
-
-An RDSInstanceClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.aws.crossplane.io/v1alpha2`
-`kind` | string | `RDSInstanceClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [RDSInstanceClassSpecTemplate](#RDSInstanceClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned RDSInstance.
-
-
-
-## RDSInstanceClassSpecTemplate
-
-An RDSInstanceClassSpecTemplate is a template for the spec of a dynamically provisioned RDSInstance.
-
-Appears in:
-
-* [RDSInstanceClass](#RDSInstanceClass)
-
-
-
-
-RDSInstanceClassSpecTemplate supports all fields of:
-
-* [v1alpha1.NonPortableClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#nonportableclassspectemplate)
-* [RDSInstanceParameters](#RDSInstanceParameters)
-
-
-## RDSInstanceParameters
-
-RDSInstanceParameters define the desired state of an AWS Relational Database Service instance.
-
-Appears in:
-
-* [RDSInstanceClassSpecTemplate](#RDSInstanceClassSpecTemplate)
-* [RDSInstanceSpec](#RDSInstanceSpec)
-
-
-Name | Type | Description
------|------|------------
-`masterUsername` | string | MasterUsername for this RDSInstance.
-`engine` | string | Engine for this RDSInstance - either mysql or postgres.
-`engineVersion` | Optional string | EngineVersion for this RDS instance, for example "5.6".
-`class` | string | Class of this RDS instance, for example "db.t2.micro".
-`size` | int64 | Size in GB of this RDS instance.
-`subnetGroupName` | Optional string | SubnetGroupName specifies a database subnet group for the RDS instance. The new instance is created in the VPC associated with the DB subnet group. If no DB subnet group is specified, then the instance is not created in a VPC.
-`securityGroups` | Optional []string | SecurityGroups that will allow the RDS instance to be accessed over the network.
-
-
-
-## RDSInstanceSpec
-
-An RDSInstanceSpec defines the desired state of an RDSInstance.
-
-Appears in:
-
-* [RDSInstance](#RDSInstance)
-
-
-
-
-RDSInstanceSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [RDSInstanceParameters](#RDSInstanceParameters)
-
-
-## RDSInstanceState
-
-RDSInstanceState represents the state of an RDS instance. Alias of string.
-
-
-## RDSInstanceStatus
-
-An RDSInstanceStatus represents the observed state of an RDSInstance.
-
-Appears in:
-
-* [RDSInstance](#RDSInstance)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State of this RDS instance.
-`providerID` | string | ProviderID is the AWS identifier for this RDS instance.
-`instanceName` | string | InstanceName of this RDS instance.
-`endpoint` | string | Endpoint of this RDS instance.
-
-
-RDSInstanceStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-aws/identity-aws-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-aws/identity-aws-crossplane-io-v1alpha2.md
deleted file mode 100644
index 795668a7..00000000
--- a/docs/v0.3/api/crossplaneio/stack-aws/identity-aws-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,172 +0,0 @@
-# identity.aws.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for AWS identity services such as IAM.
-
-This API group contains the following Crossplane resources:
-
-* [IAMRole](#IAMRole)
-* [IAMRolePolicyAttachment](#IAMRolePolicyAttachment)
-
-## IAMRole
-
-An IAMRole is a managed resource that represents an AWS IAM Role.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `identity.aws.crossplane.io/v1alpha2`
-`kind` | string | `IAMRole`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [IAMRoleSpec](#IAMRoleSpec) | An IAMRoleSpec defines the desired state of an IAMRole.
-`status` | [IAMRoleStatus](#IAMRoleStatus) | An IAMRoleStatus represents the observed state of an IAMRole.
-
-
-
-## IAMRolePolicyAttachment
-
-An IAMRolePolicyAttachment is a managed resource that represents an AWS IAM Role policy attachment.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `identity.aws.crossplane.io/v1alpha2`
-`kind` | string | `IAMRolePolicyAttachment`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [IAMRolePolicyAttachmentSpec](#IAMRolePolicyAttachmentSpec) | An IAMRolePolicyAttachmentSpec defines the desired state of an IAMRolePolicyAttachment.
-`status` | [IAMRolePolicyAttachmentStatus](#IAMRolePolicyAttachmentStatus) | An IAMRolePolicyAttachmentStatus represents the observed state of an IAMRolePolicyAttachment.
-
-
-
-## IAMRoleExternalStatus
-
-IAMRoleExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [IAMRoleStatus](#IAMRoleStatus)
-
-
-Name | Type | Description
------|------|------------
-`arn` | string | ARN is the Amazon Resource Name (ARN) specifying the role. For more information about ARNs and how to use them in policies, see IAM Identifiers (http://docs.aws.amazon.com/IAM/latest/UserGuide/Using_Identifiers.html) in the IAM User Guide guide.
-`roleID` | string | RoleID is the stable and unique string identifying the role. For more information about IDs, see IAM Identifiers (http://docs.aws.amazon.com/IAM/latest/UserGuide/Using_Identifiers.html) in the Using IAM guide.
-
-
-
-## IAMRoleParameters
-
-IAMRoleParameters define the desired state of an AWS IAM Role.
-
-Appears in:
-
-* [IAMRoleSpec](#IAMRoleSpec)
-
-
-Name | Type | Description
------|------|------------
-`assumeRolePolicyDocument` | string | AssumeRolePolicyDocument is the the trust relationship policy document that grants an entity permission to assume the role.
-`description` | Optional string | Description is a description of the role.
-`roleName` | string | RoleName presents the name of the IAM role.
-
-
-
-## IAMRolePolicyAttachmentExternalStatus
-
-IAMRolePolicyAttachmentExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [IAMRolePolicyAttachmentStatus](#IAMRolePolicyAttachmentStatus)
-
-
-Name | Type | Description
------|------|------------
-`attachedPolicyArn` | string | AttachedPolicyARN is the arn for the attached policy. If nil, the policy is not yet attached
-
-
-
-## IAMRolePolicyAttachmentParameters
-
-IAMRolePolicyAttachmentParameters define the desired state of an AWS IAM Role policy attachment.
-
-Appears in:
-
-* [IAMRolePolicyAttachmentSpec](#IAMRolePolicyAttachmentSpec)
-
-
-Name | Type | Description
------|------|------------
-`policyArn` | string | PolicyARN is the Amazon Resource Name (ARN) of the IAM policy you want to attach.
-`roleName` | string | RoleName presents the name of the IAM role.
-
-
-
-## IAMRolePolicyAttachmentSpec
-
-An IAMRolePolicyAttachmentSpec defines the desired state of an IAMRolePolicyAttachment.
-
-Appears in:
-
-* [IAMRolePolicyAttachment](#IAMRolePolicyAttachment)
-
-
-
-
-IAMRolePolicyAttachmentSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [IAMRolePolicyAttachmentParameters](#IAMRolePolicyAttachmentParameters)
-
-
-## IAMRolePolicyAttachmentStatus
-
-An IAMRolePolicyAttachmentStatus represents the observed state of an IAMRolePolicyAttachment.
-
-Appears in:
-
-* [IAMRolePolicyAttachment](#IAMRolePolicyAttachment)
-
-
-
-
-IAMRolePolicyAttachmentStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [IAMRolePolicyAttachmentExternalStatus](#IAMRolePolicyAttachmentExternalStatus)
-
-
-## IAMRoleSpec
-
-An IAMRoleSpec defines the desired state of an IAMRole.
-
-Appears in:
-
-* [IAMRole](#IAMRole)
-
-
-
-
-IAMRoleSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [IAMRoleParameters](#IAMRoleParameters)
-
-
-## IAMRoleStatus
-
-An IAMRoleStatus represents the observed state of an IAMRole.
-
-Appears in:
-
-* [IAMRole](#IAMRole)
-
-
-
-
-IAMRoleStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [IAMRoleExternalStatus](#IAMRoleExternalStatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-aws/network-aws-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-aws/network-aws-crossplane-io-v1alpha2.md
deleted file mode 100644
index 12e3e874..00000000
--- a/docs/v0.3/api/crossplaneio/stack-aws/network-aws-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,568 +0,0 @@
-# network.aws.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for AWS network services such as VPC and Subnet.
-
-This API group contains the following Crossplane resources:
-
-* [InternetGateway](#InternetGateway)
-* [RouteTable](#RouteTable)
-* [SecurityGroup](#SecurityGroup)
-* [Subnet](#Subnet)
-* [VPC](#VPC)
-
-## InternetGateway
-
-An InternetGateway is a managed resource that represents an AWS VPC Internet Gateway.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `network.aws.crossplane.io/v1alpha2`
-`kind` | string | `InternetGateway`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [InternetGatewaySpec](#InternetGatewaySpec) | An InternetGatewaySpec defines the desired state of an InternetGateway.
-`status` | [InternetGatewayStatus](#InternetGatewayStatus) | An InternetGatewayStatus represents the observed state of an InternetGateway.
-
-
-
-## RouteTable
-
-A RouteTable is a managed resource that represents an AWS VPC Route Table.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `network.aws.crossplane.io/v1alpha2`
-`kind` | string | `RouteTable`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [RouteTableSpec](#RouteTableSpec) | A RouteTableSpec defines the desired state of a RouteTable.
-`status` | [RouteTableStatus](#RouteTableStatus) | A RouteTableStatus represents the observed state of a RouteTable.
-
-
-
-## SecurityGroup
-
-A SecurityGroup is a managed resource that represents an AWS VPC Security Group.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `network.aws.crossplane.io/v1alpha2`
-`kind` | string | `SecurityGroup`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [SecurityGroupSpec](#SecurityGroupSpec) | A SecurityGroupSpec defines the desired state of a SecurityGroup.
-`status` | [SecurityGroupStatus](#SecurityGroupStatus) | A SecurityGroupStatus represents the observed state of a SecurityGroup.
-
-
-
-## Subnet
-
-A Subnet is a managed resource that represents an AWS VPC Subnet.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `network.aws.crossplane.io/v1alpha2`
-`kind` | string | `Subnet`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [SubnetSpec](#SubnetSpec) | A SubnetSpec defines the desired state of a Subnet.
-`status` | [SubnetStatus](#SubnetStatus) | A SubnetStatus represents the observed state of a Subnet.
-
-
-
-## VPC
-
-A VPC is a managed resource that represents an AWS Virtual Private Cloud.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `network.aws.crossplane.io/v1alpha2`
-`kind` | string | `VPC`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [VPCSpec](#VPCSpec) | A VPCSpec defines the desired state of a VPC.
-`status` | [VPCStatus](#VPCStatus) | A VPCStatus represents the observed state of a VPC.
-
-
-
-## Association
-
-Association describes an association between a route table and a subnet.
-
-Appears in:
-
-* [AssociationState](#AssociationState)
-* [RouteTableParameters](#RouteTableParameters)
-
-
-Name | Type | Description
------|------|------------
-`subnetId` | string | The ID of the subnet. A subnet ID is not returned for an implicit association.
-
-
-
-## AssociationState
-
-AssociationState describes an association state in the route table.
-
-Appears in:
-
-* [RouteTableExternalStatus](#RouteTableExternalStatus)
-
-
-Name | Type | Description
------|------|------------
-`main` | bool | Indicates whether this is the main route table.
-`associationId` | string | The ID of the association between a route table and a subnet.
-
-
-AssociationState supports all fields of:
-
-* [Association](#Association)
-
-
-## IPPermission
-
-IPPermission Describes a set of permissions for a security group rule.
-
-Appears in:
-
-* [SecurityGroupParameters](#SecurityGroupParameters)
-
-
-Name | Type | Description
------|------|------------
-`fromPort` | int64 | The start of port range for the TCP and UDP protocols, or an ICMP/ICMPv6 type number. A value of -1 indicates all ICMP/ICMPv6 types. If you specify all ICMP/ICMPv6 types, you must specify all codes.
-`toPort` | int64 | The end of port range for the TCP and UDP protocols, or an ICMP/ICMPv6 code. A value of -1 indicates all ICMP/ICMPv6 codes for the specified ICMP type. If you specify all ICMP/ICMPv6 types, you must specify all codes.
-`protocol` | string | The IP protocol name (tcp, udp, icmp) or number (see Protocol Numbers (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml)). [EC2-VPC only] Use -1 to specify all protocols. When authorizing security group rules, specifying -1 or a protocol number other than tcp, udp, icmp, or 58 (ICMPv6) allows traffic on all ports, regardless of any port range you specify. For tcp, udp, and icmp, you must specify a port range. For 58 (ICMPv6), you can optionally specify a port range; if you don't, traffic for all types and codes is allowed when authorizing rules.
-`cidrBlocks` | [[]IPRange](#IPRange) | One or more IPv4 ranges.
-
-
-
-## IPRange
-
-IPRange describes an IPv4 range.
-
-Appears in:
-
-* [IPPermission](#IPPermission)
-
-
-Name | Type | Description
------|------|------------
-`cidrIp` | string | The IPv4 CIDR range. You can either specify a CIDR range or a source security group, not both. To specify a single IPv4 address, use the /32 prefix length.
-`description` | string | A description for the ip range
-
-
-
-## InternetGatewayAttachment
-
-InternetGatewayAttachment describes the attachment of a VPC to an internet gateway or an egress-only internet gateway.
-
-Appears in:
-
-* [InternetGatewayExternalStatus](#InternetGatewayExternalStatus)
-
-
-Name | Type | Description
------|------|------------
-`attachmentStatus` | string | The current state of the attachment. For an internet gateway, the state is available when attached to a VPC; otherwise, this value is not returned.
-`vpcId` | string | VPCID is the ID of the attached VPC.
-
-
-
-## InternetGatewayExternalStatus
-
-InternetGatewayExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [InternetGatewayStatus](#InternetGatewayStatus)
-
-
-Name | Type | Description
------|------|------------
-`attachments` | [[]InternetGatewayAttachment](#InternetGatewayAttachment) | Any VPCs attached to the internet gateway.
-`internetGatewayId` | string | The ID of the internet gateway.
-`tags` | [[]Tag](#Tag) | Tags represents to current ec2 tags.
-
-
-
-## InternetGatewayParameters
-
-InternetGatewayParameters define the desired state of an AWS VPC Internet Gateway.
-
-Appears in:
-
-* [InternetGatewaySpec](#InternetGatewaySpec)
-
-
-Name | Type | Description
------|------|------------
-`vpcId` | string | the VPC to attach the gateway to.
-
-
-
-## InternetGatewaySpec
-
-An InternetGatewaySpec defines the desired state of an InternetGateway.
-
-Appears in:
-
-* [InternetGateway](#InternetGateway)
-
-
-
-
-InternetGatewaySpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [InternetGatewayParameters](#InternetGatewayParameters)
-
-
-## InternetGatewayStatus
-
-An InternetGatewayStatus represents the observed state of an InternetGateway.
-
-Appears in:
-
-* [InternetGateway](#InternetGateway)
-
-
-
-
-InternetGatewayStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [InternetGatewayExternalStatus](#InternetGatewayExternalStatus)
-
-
-## Route
-
-Route describes a route in a route table.
-
-Appears in:
-
-* [RouteState](#RouteState)
-* [RouteTableParameters](#RouteTableParameters)
-
-
-Name | Type | Description
------|------|------------
-`destinationCidrBlock` | string | The IPv4 CIDR address block used for the destination match. Routing decisions are based on the most specific match.
-`gatewayId` | string | The ID of an internet gateway or virtual private gateway attached to your VPC.
-
-
-
-## RouteState
-
-RouteState describes a route state in the route table.
-
-Appears in:
-
-* [RouteTableExternalStatus](#RouteTableExternalStatus)
-
-
-Name | Type | Description
------|------|------------
-`routeState` | string | The state of the route. The blackhole state indicates that the route's target isn't available (for example, the specified gateway isn't attached to the VPC, or the specified NAT instance has been terminated).
-
-
-RouteState supports all fields of:
-
-* [Route](#Route)
-
-
-## RouteTableExternalStatus
-
-RouteTableExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [RouteTableStatus](#RouteTableStatus)
-
-
-Name | Type | Description
------|------|------------
-`routeTableId` | string | RouteTableID is the ID of the RouteTable.
-`routes` | [[]RouteState](#RouteState) | The actual routes created for the route table.
-`associations` | [[]AssociationState](#AssociationState) | The actual associations created for the route table.
-
-
-
-## RouteTableParameters
-
-RouteTableParameters define the desired state of an AWS VPC Route Table.
-
-Appears in:
-
-* [RouteTableSpec](#RouteTableSpec)
-
-
-Name | Type | Description
------|------|------------
-`vpcId` | string | VPCID is the ID of the VPC.
-`routes` | [[]Route](#Route) | the routes in the route table
-`associations` | [[]Association](#Association) | The associations between the route table and one or more subnets.
-
-
-
-## RouteTableSpec
-
-A RouteTableSpec defines the desired state of a RouteTable.
-
-Appears in:
-
-* [RouteTable](#RouteTable)
-
-
-
-
-RouteTableSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [RouteTableParameters](#RouteTableParameters)
-
-
-## RouteTableStatus
-
-A RouteTableStatus represents the observed state of a RouteTable.
-
-Appears in:
-
-* [RouteTable](#RouteTable)
-
-
-
-
-RouteTableStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [RouteTableExternalStatus](#RouteTableExternalStatus)
-
-
-## SecurityGroupExternalStatus
-
-SecurityGroupExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [SecurityGroupStatus](#SecurityGroupStatus)
-
-
-Name | Type | Description
------|------|------------
-`securityGroupID` | string | SecurityGroupID is the ID of the SecurityGroup.
-`tags` | [[]Tag](#Tag) | Tags represents to current ec2 tags.
-
-
-
-## SecurityGroupParameters
-
-SecurityGroupParameters define the desired state of an AWS VPC Security Group.
-
-Appears in:
-
-* [SecurityGroupSpec](#SecurityGroupSpec)
-
-
-Name | Type | Description
------|------|------------
-`vpcId` | string | VPCID is the ID of the VPC.
-`description` | string | A description of the security group.
-`groupName` | string | The name of the security group.
-`ingress` | [[]IPPermission](#IPPermission) | One or more inbound rules associated with the security group.
-`egress` | [[]IPPermission](#IPPermission) | [EC2-VPC] One or more outbound rules associated with the security group.
-
-
-
-## SecurityGroupSpec
-
-A SecurityGroupSpec defines the desired state of a SecurityGroup.
-
-Appears in:
-
-* [SecurityGroup](#SecurityGroup)
-
-
-
-
-SecurityGroupSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [SecurityGroupParameters](#SecurityGroupParameters)
-
-
-## SecurityGroupStatus
-
-A SecurityGroupStatus represents the observed state of a SecurityGroup.
-
-Appears in:
-
-* [SecurityGroup](#SecurityGroup)
-
-
-
-
-SecurityGroupStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [SecurityGroupExternalStatus](#SecurityGroupExternalStatus)
-
-
-## SubnetExternalStatus
-
-SubnetExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [SubnetStatus](#SubnetStatus)
-
-
-Name | Type | Description
------|------|------------
-`subnetState` | string | SubnetState is the current state of the Subnet.
-`tags` | [[]Tag](#Tag) | Tags represents to current ec2 tags.
-`subnetId` | string | SubnetID is the ID of the Subnet.
-
-
-
-## SubnetParameters
-
-SubnetParameters define the desired state of an AWS VPC Subnet.
-
-Appears in:
-
-* [SubnetSpec](#SubnetSpec)
-
-
-Name | Type | Description
------|------|------------
-`cidrBlock` | string | CIDRBlock is the IPv4 network range for the Subnet, in CIDR notation. For example, 10.0.0.0/18.
-`availabilityZone` | string | The Availability Zone for the subnet. Default: AWS selects one for you. If you create more than one subnet in your VPC, we may not necessarily select a different zone for each subnet.
-`vpcId` | string | VPCID is the ID of the VPC.
-
-
-
-## SubnetSpec
-
-A SubnetSpec defines the desired state of a Subnet.
-
-Appears in:
-
-* [Subnet](#Subnet)
-
-
-
-
-SubnetSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [SubnetParameters](#SubnetParameters)
-
-
-## SubnetStatus
-
-A SubnetStatus represents the observed state of a Subnet.
-
-Appears in:
-
-* [Subnet](#Subnet)
-
-
-
-
-SubnetStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [SubnetExternalStatus](#SubnetExternalStatus)
-
-
-## Tag
-
-Tag defines a tag
-
-Appears in:
-
-* [InternetGatewayExternalStatus](#InternetGatewayExternalStatus)
-* [SecurityGroupExternalStatus](#SecurityGroupExternalStatus)
-* [SubnetExternalStatus](#SubnetExternalStatus)
-* [VPCExternalStatus](#VPCExternalStatus)
-
-
-Name | Type | Description
------|------|------------
-`key` | string | Key is the name of the tag.
-`value` | string | Value is the value of the tag.
-
-
-
-## VPCExternalStatus
-
-VPCExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [VPCStatus](#VPCStatus)
-
-
-Name | Type | Description
------|------|------------
-`vpcState` | string | VPCState is the current state of the VPC.
-`tags` | [[]Tag](#Tag) | Tags represents to current ec2 tags.
-`vpcId` | string | VPCID is the ID of the VPC.
-
-
-
-## VPCParameters
-
-VPCParameters define the desired state of an AWS Virtual Private Cloud.
-
-Appears in:
-
-* [VPCSpec](#VPCSpec)
-
-
-Name | Type | Description
------|------|------------
-`cidrBlock` | string | CIDRBlock is the IPv4 network range for the VPC, in CIDR notation. For example, 10.0.0.0/16.
-`enableDnsSupport` | bool | A boolean flag to enable/disable DNS support in the VPC
-`enableDnsHostNames` | bool | A boolean flag to enable/disable DNS hostnames in the VPC
-
-
-
-## VPCSpec
-
-A VPCSpec defines the desired state of a VPC.
-
-Appears in:
-
-* [VPC](#VPC)
-
-
-
-
-VPCSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [VPCParameters](#VPCParameters)
-
-
-## VPCStatus
-
-A VPCStatus represents the observed state of a VPC.
-
-Appears in:
-
-* [VPC](#VPC)
-
-
-
-
-VPCStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [VPCExternalStatus](#VPCExternalStatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-aws/storage-aws-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-aws/storage-aws-crossplane-io-v1alpha2.md
deleted file mode 100644
index 185f244c..00000000
--- a/docs/v0.3/api/crossplaneio/stack-aws/storage-aws-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,233 +0,0 @@
-# storage.aws.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for AWS storage services such as S3.
-
-This API group contains the following Crossplane resources:
-
-* [DBSubnetGroup](#DBSubnetGroup)
-* [S3Bucket](#S3Bucket)
-* [S3BucketClass](#S3BucketClass)
-
-## DBSubnetGroup
-
-A DBSubnetGroup is a managed resource that represents an AWS VPC Database Subnet Group.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.aws.crossplane.io/v1alpha2`
-`kind` | string | `DBSubnetGroup`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [DBSubnetGroupSpec](#DBSubnetGroupSpec) | A DBSubnetGroupSpec defines the desired state of a DBSubnetGroup.
-`status` | [DBSubnetGroupStatus](#DBSubnetGroupStatus) | A DBSubnetGroupStatus represents the observed state of a DBSubnetGroup.
-
-
-
-## S3Bucket
-
-An S3Bucket is a managed resource that represents an AWS S3 Bucket.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.aws.crossplane.io/v1alpha2`
-`kind` | string | `S3Bucket`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [S3BucketSpec](#S3BucketSpec) | S3BucketSpec defines the desired state of S3Bucket
-`status` | [S3BucketStatus](#S3BucketStatus) | S3BucketStatus defines the observed state of S3Bucket
-
-
-
-## S3BucketClass
-
-An S3BucketClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.aws.crossplane.io/v1alpha2`
-`kind` | string | `S3BucketClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [S3BucketClassSpecTemplate](#S3BucketClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned S3Bucket.
-
-
-
-## DBSubnetGroupExternalStatus
-
-DBSubnetGroupExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [DBSubnetGroupStatus](#DBSubnetGroupStatus)
-
-
-Name | Type | Description
------|------|------------
-`groupArn` | string | The Amazon Resource Name (ARN) for the DB subnet group.
-`groupStatus` | string | Provides the status of the DB subnet group.
-`subnets` | [[]Subnet](#Subnet) | Contains a list of Subnet elements.
-`vpcId` | string | Provides the VpcId of the DB subnet group.
-
-
-
-## DBSubnetGroupParameters
-
-DBSubnetGroupParameters define the desired state of an AWS VPC Database Subnet Group.
-
-Appears in:
-
-* [DBSubnetGroupSpec](#DBSubnetGroupSpec)
-
-
-Name | Type | Description
------|------|------------
-`description` | string | The description for the DB subnet group.
-`groupName` | string | The name for the DB subnet group. This value is stored as a lowercase string.
-`subnetIds` | []string | The EC2 Subnet IDs for the DB subnet group.
-`tags` | [[]Tag](#Tag) | A list of tags. For more information, see Tagging Amazon RDS Resources (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html) in the Amazon RDS User Guide.
-
-
-
-## DBSubnetGroupSpec
-
-A DBSubnetGroupSpec defines the desired state of a DBSubnetGroup.
-
-Appears in:
-
-* [DBSubnetGroup](#DBSubnetGroup)
-
-
-
-
-DBSubnetGroupSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [DBSubnetGroupParameters](#DBSubnetGroupParameters)
-
-
-## DBSubnetGroupStatus
-
-A DBSubnetGroupStatus represents the observed state of a DBSubnetGroup.
-
-Appears in:
-
-* [DBSubnetGroup](#DBSubnetGroup)
-
-
-
-
-DBSubnetGroupStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [DBSubnetGroupExternalStatus](#DBSubnetGroupExternalStatus)
-
-
-## S3BucketClassSpecTemplate
-
-An S3BucketClassSpecTemplate is a template for the spec of a dynamically provisioned S3Bucket.
-
-Appears in:
-
-* [S3BucketClass](#S3BucketClass)
-
-
-
-
-S3BucketClassSpecTemplate supports all fields of:
-
-* [v1alpha1.NonPortableClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#nonportableclassspectemplate)
-* [S3BucketParameters](#S3BucketParameters)
-
-
-## S3BucketParameters
-
-S3BucketParameters define the desired state of an AWS S3 Bucket.
-
-Appears in:
-
-* [S3BucketClassSpecTemplate](#S3BucketClassSpecTemplate)
-* [S3BucketSpec](#S3BucketSpec)
-
-
-Name | Type | Description
------|------|------------
-`nameFormat` | Optional string | NameFormat specifies the name of the external S3Bucket instance. The first instance of the string '%s' will be replaced with the Kubernetes UID of this S3Bucket. Omit this field to use the UID alone as the name.
-`region` | string | Region of the bucket.
-`cannedACL` | Optional [s3.BucketCannedACL](https://godoc.org/github.com/aws/aws-sdk-go-v2/service/s3#BucketCannedACL) | CannedACL applies a standard AWS built-in ACL for common bucket use cases.
-`versioning` | Optional bool | Versioning enables versioning of objects stored in this bucket.
-`localPermission` | [storage/v1alpha1.LocalPermissionType](../crossplane/storage-crossplane-io-v1alpha1.md#localpermissiontype) | LocalPermission is the permissions granted on the bucket for the provider specific bucket service account that is available in a secret after provisioning.
-
-
-
-## S3BucketSpec
-
-S3BucketSpec defines the desired state of S3Bucket
-
-Appears in:
-
-* [S3Bucket](#S3Bucket)
-
-
-
-
-S3BucketSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [S3BucketParameters](#S3BucketParameters)
-
-
-## S3BucketStatus
-
-S3BucketStatus defines the observed state of S3Bucket
-
-Appears in:
-
-* [S3Bucket](#S3Bucket)
-
-
-Name | Type | Description
------|------|------------
-`providerID` | string | ProviderID is the AWS identifier for this bucket.
-`iamUsername` | string | IAMUsername is the name of an IAM user that is automatically created and granted access to this bucket by Crossplane at bucket creation time.
-`lastUserPolicyVersion` | int | LastUserPolicyVersion is the most recent version of the policy associated with this bucket's IAMUser.
-`lastLocalPermission` | [storage/v1alpha1.LocalPermissionType](../crossplane/storage-crossplane-io-v1alpha1.md#localpermissiontype) | LastLocalPermission is the most recent local permission that was set for this bucket.
-
-
-S3BucketStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## Subnet
-
-Subnet represents a aws subnet
-
-Appears in:
-
-* [DBSubnetGroupExternalStatus](#DBSubnetGroupExternalStatus)
-
-
-Name | Type | Description
------|------|------------
-`subnetID` | string | Specifies the identifier of the subnet.
-`subnetStatus` | string | Specifies the status of the subnet.
-
-
-
-## Tag
-
-Tag defines a tag
-
-Appears in:
-
-* [DBSubnetGroupParameters](#DBSubnetGroupParameters)
-
-
-Name | Type | Description
------|------|------------
-`key` | string | Key is the name of the tag.
-`value` | string | Value is the value of the tag.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-azure/azure-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-azure/azure-crossplane-io-v1alpha2.md
deleted file mode 100644
index 07d270f3..00000000
--- a/docs/v0.3/api/crossplaneio/stack-azure/azure-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,93 +0,0 @@
-# azure.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains core resources for Microsoft Azure.
-
-This API group contains the following Crossplane resources:
-
-* [Provider](#Provider)
-* [ResourceGroup](#ResourceGroup)
-
-## Provider
-
-A Provider configures an Azure 'provider', i.e. a connection to a particular Azure account using a particular Azure Service Principal.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `azure.crossplane.io/v1alpha2`
-`kind` | string | `Provider`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ProviderSpec](#ProviderSpec) | A ProviderSpec defines the desired state of a Provider.
-
-
-
-## ResourceGroup
-
-A ResourceGroup is a managed resource that represents an Azure Resource Group.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `azure.crossplane.io/v1alpha2`
-`kind` | string | `ResourceGroup`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ResourceGroupSpec](#ResourceGroupSpec) | A ResourceGroupSpec defines the desired state of a ResourceGroup.
-`status` | [ResourceGroupStatus](#ResourceGroupStatus) | A ResourceGroupStatus represents the observed status of a ResourceGroup.
-
-
-
-## ProviderSpec
-
-A ProviderSpec defines the desired state of a Provider.
-
-Appears in:
-
-* [Provider](#Provider)
-
-
-Name | Type | Description
------|------|------------
-`credentialsSecretRef` | [core/v1.SecretKeySelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#secretkeyselector-v1-core) | Azure service principal credentials json secret key reference A Secret containing JSON encoded credentials for an Azure Service Principal that will be used to authenticate to this Azure Provider.
-
-
-
-## ResourceGroupSpec
-
-A ResourceGroupSpec defines the desired state of a ResourceGroup.
-
-Appears in:
-
-* [ResourceGroup](#ResourceGroup)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name of the resource group.
-`location` | string | Location of the resource group. See the official list of valid regions - https://azure.microsoft.com/en-us/global-infrastructure/regions/
-
-
-ResourceGroupSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## ResourceGroupStatus
-
-A ResourceGroupStatus represents the observed status of a ResourceGroup.
-
-Appears in:
-
-* [ResourceGroup](#ResourceGroup)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name of the resource group.
-
-
-ResourceGroupStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-azure/cache-azure-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-azure/cache-azure-crossplane-io-v1alpha2.md
deleted file mode 100644
index ce87bc73..00000000
--- a/docs/v0.3/api/crossplaneio/stack-azure/cache-azure-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,138 +0,0 @@
-# cache.azure.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for Azure cache services such as Redis.
-
-This API group contains the following Crossplane resources:
-
-* [Redis](#Redis)
-* [RedisClass](#RedisClass)
-
-## Redis
-
-A Redis is a managed resource that represents an Azure Redis cluster.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.azure.crossplane.io/v1alpha2`
-`kind` | string | `Redis`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [RedisSpec](#RedisSpec) | A RedisSpec defines the desired state of a Redis.
-`status` | [RedisStatus](#RedisStatus) | A RedisStatus represents the observed state of a Redis.
-
-
-
-## RedisClass
-
-A RedisClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.azure.crossplane.io/v1alpha2`
-`kind` | string | `RedisClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [RedisClassSpecTemplate](#RedisClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned Redis.
-
-
-
-## RedisClassSpecTemplate
-
-A RedisClassSpecTemplate is a template for the spec of a dynamically provisioned Redis.
-
-Appears in:
-
-* [RedisClass](#RedisClass)
-
-
-
-
-RedisClassSpecTemplate supports all fields of:
-
-* [v1alpha1.NonPortableClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#nonportableclassspectemplate)
-* [RedisParameters](#RedisParameters)
-
-
-## RedisParameters
-
-RedisParameters define the desired state of an Azure Redis cluster. Most fields map directly to an Azure Redis resource: https://docs.microsoft.com/en-us/rest/api/redis/redis/create#redisresource
-
-Appears in:
-
-* [RedisClassSpecTemplate](#RedisClassSpecTemplate)
-* [RedisSpec](#RedisSpec)
-
-
-Name | Type | Description
------|------|------------
-`resourceGroupName` | string | ResourceGroupName in which to create this resource.
-`location` | string | Location in which to create this resource.
-`sku` | [SKUSpec](#SKUSpec) | SKU of the Redis cache to deploy.
-`enableNonSslPort` | Optional bool | EnableNonSSLPort specifies whether the non-ssl Redis server port (6379) is enabled.
-`shardCount` | Optional int | ShardCount specifies the number of shards to be created on a Premium Cluster Cache.
-`staticIP` | Optional string | StaticIP address. Required when deploying a Redis cache inside an existing Azure Virtual Network.
-`subnetId` | Optional string | SubnetID specifies the full resource ID of a subnet in a virtual network to deploy the Redis cache in. Example format: /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/Microsoft.{Network|ClassicNetwork}/VirtualNetworks/vnet1/subnets/subnet1
-`redisConfiguration` | Optional map[string]string | RedisConfiguration specifies Redis Settings.
-
-
-
-## RedisSpec
-
-A RedisSpec defines the desired state of a Redis.
-
-Appears in:
-
-* [Redis](#Redis)
-
-
-
-
-RedisSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [RedisParameters](#RedisParameters)
-
-
-## RedisStatus
-
-A RedisStatus represents the observed state of a Redis.
-
-Appears in:
-
-* [Redis](#Redis)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State represents the state of an Azure Redis.
-`providerID` | string | ProviderID is the external ID to identify this resource in the cloud provider.
-`endpoint` | string | Endpoint of the Redis resource used in connection strings.
-`port` | int | Port at which the Redis endpoint is listening.
-`sslPort` | int | SSLPort at which the Redis endpoint is listening.
-`redisVersion` | string | RedisVersion the Redis endpoint is running.
-`resourceName` | string | ResourceName of the Redis cache resource.
-
-
-RedisStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## SKUSpec
-
-An SKUSpec represents the performance and cost oriented properties of a Redis.
-
-Appears in:
-
-* [RedisParameters](#RedisParameters)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name specifies what type of Redis cache to deploy. Valid values: (Basic, Standard, Premium). Possible values include: 'Basic', 'Standard', 'Premium'
-`family` | string | Family specifies which family to use. Valid values: (C, P). Possible values include: 'C', 'P'
-`capacity` | int | Capacity specifies the size of Redis cache to deploy. Valid values: for C family (0, 1, 2, 3, 4, 5, 6), for P family (1, 2, 3, 4).
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-azure/compute-azure-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-azure/compute-azure-crossplane-io-v1alpha2.md
deleted file mode 100644
index bfef18a7..00000000
--- a/docs/v0.3/api/crossplaneio/stack-azure/compute-azure-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,122 +0,0 @@
-# compute.azure.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for Azure compute services such as AKS.
-
-This API group contains the following Crossplane resources:
-
-* [AKSCluster](#AKSCluster)
-* [AKSClusterClass](#AKSClusterClass)
-
-## AKSCluster
-
-An AKSCluster is a managed resource that represents an Azure Kubernetes Engine cluster.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.azure.crossplane.io/v1alpha2`
-`kind` | string | `AKSCluster`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [AKSClusterSpec](#AKSClusterSpec) | An AKSClusterSpec defines the desired state of a AKSCluster.
-`status` | [AKSClusterStatus](#AKSClusterStatus) | An AKSClusterStatus represents the observed state of an AKSCluster.
-
-
-
-## AKSClusterClass
-
-An AKSClusterClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.azure.crossplane.io/v1alpha2`
-`kind` | string | `AKSClusterClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [AKSClusterClassSpecTemplate](#AKSClusterClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned AKSCluster.
-
-
-
-## AKSClusterClassSpecTemplate
-
-An AKSClusterClassSpecTemplate is a template for the spec of a dynamically provisioned AKSCluster.
-
-Appears in:
-
-* [AKSClusterClass](#AKSClusterClass)
-
-
-
-
-AKSClusterClassSpecTemplate supports all fields of:
-
-* [v1alpha1.NonPortableClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#nonportableclassspectemplate)
-* [AKSClusterParameters](#AKSClusterParameters)
-
-
-## AKSClusterParameters
-
-AKSClusterParameters define the desired state of an Azure Kubernetes Engine cluster.
-
-Appears in:
-
-* [AKSClusterClassSpecTemplate](#AKSClusterClassSpecTemplate)
-* [AKSClusterSpec](#AKSClusterSpec)
-
-
-Name | Type | Description
------|------|------------
-`resourceGroupName` | string | ResourceGroupName is the name of the resource group that the cluster will be created in
-`location` | string | Location is the Azure location that the cluster will be created in
-`version` | string | Version is the Kubernetes version that will be deployed to the cluster
-`vnetSubnetID` | Optional string | VnetSubnetID is the subnet to which the cluster will be deployed.
-`nodeCount` | Optional int | NodeCount is the number of nodes that the cluster will initially be created with. This can be scaled over time and defaults to 1.
-`nodeVMSize` | Optional string | NodeVMSize is the name of the worker node VM size, e.g., Standard_B2s, Standard_F2s_v2, etc.
-`dnsNamePrefix` | Optional string | DNSNamePrefix is the DNS name prefix to use with the hosted Kubernetes API server FQDN. You will use this to connect to the Kubernetes API when managing containers after creating the cluster.
-`disableRBAC` | Optional bool | DisableRBAC determines whether RBAC will be disabled or enabled in the cluster.
-`writeServicePrincipalTo` | [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core) | WriteServicePrincipalSecretTo the specified Secret. The service principal is automatically generated and used by the AKS cluster to interact with other Azure resources.
-
-
-
-## AKSClusterSpec
-
-An AKSClusterSpec defines the desired state of a AKSCluster.
-
-Appears in:
-
-* [AKSCluster](#AKSCluster)
-
-
-
-
-AKSClusterSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [AKSClusterParameters](#AKSClusterParameters)
-
-
-## AKSClusterStatus
-
-An AKSClusterStatus represents the observed state of an AKSCluster.
-
-Appears in:
-
-* [AKSCluster](#AKSCluster)
-
-
-Name | Type | Description
------|------|------------
-`clusterName` | string | ClusterName is the name of the cluster as registered with the cloud provider.
-`state` | string | State is the current state of the cluster.
-`providerID` | string | ProviderID is the external ID to identify this resource in the cloud provider.
-`endpoint` | string | Endpoint is the endpoint where the cluster can be reached
-`appObjectID` | string | ApplicationObjectID is the object ID of the AD application the cluster uses for Azure APIs.
-`servicePrincipalID` | string | ServicePrincipalID is the ID of the service principal the AD application uses.
-`runningOperation` | string | RunningOperation stores any current long running operation for this instance across reconciliation attempts.
-
-
-AKSClusterStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-azure/database-azure-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-azure/database-azure-crossplane-io-v1alpha2.md
deleted file mode 100644
index 9364a504..00000000
--- a/docs/v0.3/api/crossplaneio/stack-azure/database-azure-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,270 +0,0 @@
-# database.azure.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for Azure database services such as SQL server.
-
-This API group contains the following Crossplane resources:
-
-* [MysqlServer](#MysqlServer)
-* [MysqlServerVirtualNetworkRule](#MysqlServerVirtualNetworkRule)
-* [PostgresqlServer](#PostgresqlServer)
-* [PostgresqlServerVirtualNetworkRule](#PostgresqlServerVirtualNetworkRule)
-* [SQLServerClass](#SQLServerClass)
-
-## MysqlServer
-
-A MysqlServer is a managed resource that represents an Azure MySQL Database Server.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.azure.crossplane.io/v1alpha2`
-`kind` | string | `MysqlServer`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [SQLServerSpec](#SQLServerSpec) | A SQLServerSpec defines the desired state of a SQLServer.
-`status` | [SQLServerStatus](#SQLServerStatus) | A SQLServerStatus represents the observed state of a SQLServer.
-
-
-
-## MysqlServerVirtualNetworkRule
-
-A MysqlServerVirtualNetworkRule is a managed resource that represents an Azure MySQL Database virtual network rule.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.azure.crossplane.io/v1alpha2`
-`kind` | string | `MysqlServerVirtualNetworkRule`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [VirtualNetworkRuleSpec](#VirtualNetworkRuleSpec) | A VirtualNetworkRuleSpec defines the desired state of a VirtualNetworkRule.
-`status` | [VirtualNetworkRuleStatus](#VirtualNetworkRuleStatus) | A VirtualNetworkRuleStatus represents the observed state of a VirtualNetworkRule.
-
-
-
-## PostgresqlServer
-
-A PostgresqlServer is a managed resource that represents an Azure PostgreSQL Database Server.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.azure.crossplane.io/v1alpha2`
-`kind` | string | `PostgresqlServer`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [SQLServerSpec](#SQLServerSpec) | A SQLServerSpec defines the desired state of a SQLServer.
-`status` | [SQLServerStatus](#SQLServerStatus) | A SQLServerStatus represents the observed state of a SQLServer.
-
-
-
-## PostgresqlServerVirtualNetworkRule
-
-A PostgresqlServerVirtualNetworkRule is a managed resource that represents an Azure PostgreSQL Database virtual network rule.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.azure.crossplane.io/v1alpha2`
-`kind` | string | `PostgresqlServerVirtualNetworkRule`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [VirtualNetworkRuleSpec](#VirtualNetworkRuleSpec) | A VirtualNetworkRuleSpec defines the desired state of a VirtualNetworkRule.
-`status` | [VirtualNetworkRuleStatus](#VirtualNetworkRuleStatus) | A VirtualNetworkRuleStatus represents the observed state of a VirtualNetworkRule.
-
-
-
-## SQLServerClass
-
-A SQLServerClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.azure.crossplane.io/v1alpha2`
-`kind` | string | `SQLServerClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [SQLServerClassSpecTemplate](#SQLServerClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned SQLServer.
-
-
-
-## PricingTierSpec
-
-PricingTierSpec represents the performance and cost oriented properties of a SQLServer.
-
-Appears in:
-
-* [SQLServerParameters](#SQLServerParameters)
-
-
-Name | Type | Description
------|------|------------
-`tier` | string | Tier of the particular SKU, e.g. Basic. Possible values include: 'Basic', 'GeneralPurpose', 'MemoryOptimized'
-`vcores` | int | VCores (aka Capacity) specifies how many virtual cores this SQLServer requires.
-`family` | string | Family of hardware.
-
-
-
-## SQLServer
-
-SQLServer represents a generic Azure SQL server.
-
-
-## SQLServerClassSpecTemplate
-
-A SQLServerClassSpecTemplate is a template for the spec of a dynamically provisioned MysqlServer or PostgresqlServer.
-
-Appears in:
-
-* [SQLServerClass](#SQLServerClass)
-
-
-
-
-SQLServerClassSpecTemplate supports all fields of:
-
-* [v1alpha1.NonPortableClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#nonportableclassspectemplate)
-* [SQLServerParameters](#SQLServerParameters)
-
-
-## SQLServerParameters
-
-SQLServerParameters define the desired state of an Azure SQL Database, either PostgreSQL or MySQL.
-
-Appears in:
-
-* [SQLServerClassSpecTemplate](#SQLServerClassSpecTemplate)
-* [SQLServerSpec](#SQLServerSpec)
-
-
-Name | Type | Description
------|------|------------
-`resourceGroupName` | string | ResourceGroupName specifies the name of the resource group that should contain this SQLServer.
-`location` | string | Location specifies the location of this SQLServer.
-`pricingTier` | [PricingTierSpec](#PricingTierSpec) | PricingTier specifies the pricing tier (aka SKU) for this SQLServer.
-`storageProfile` | [StorageProfileSpec](#StorageProfileSpec) | StorageProfile configures the storage profile of this SQLServer.
-`adminLoginName` | string | AdminLoginName specifies the administrator login name for this SQLServer.
-`version` | string | Version specifies the version of this server, for example "5.6", or "9.6".
-`sslEnforced` | Optional bool | SSLEnforced specifies whether SSL is required to connect to this SQLServer.
-
-
-
-## SQLServerSpec
-
-A SQLServerSpec defines the desired state of a SQLServer.
-
-Appears in:
-
-* [MysqlServer](#MysqlServer)
-* [PostgresqlServer](#PostgresqlServer)
-
-
-
-
-SQLServerSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [SQLServerParameters](#SQLServerParameters)
-
-
-## SQLServerStatus
-
-A SQLServerStatus represents the observed state of a SQLServer.
-
-Appears in:
-
-* [MysqlServer](#MysqlServer)
-* [PostgresqlServer](#PostgresqlServer)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State of this SQLServer.
-`message` | string | A Message containing detail on the state of this SQLServer, if any.
-`providerID` | string | ProviderID is the external ID to identify this resource in the cloud provider.
-`endpoint` | string | Endpoint of the MySQL Server instance used in connection strings.
-`runningOperation` | string | RunningOperation stores any current long running operation for this instance across reconciliation attempts.
-`runningOperationType` | string | RunningOperationType is the type of the currently running operation.
-
-
-SQLServerStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## StorageProfileSpec
-
-A StorageProfileSpec represents storage related properties of a SQLServer.
-
-Appears in:
-
-* [SQLServerParameters](#SQLServerParameters)
-
-
-Name | Type | Description
------|------|------------
-`storageGB` | int | StorageGB configures the maximum storage allowed.
-`backupRetentionDays` | int | BackupRetentionDays configures how many days backups will be retained.
-`geoRedundantBackup` | bool | GeoRedundantBackup enables geo-redunndant backups.
-
-
-
-## VirtualNetworkRuleProperties
-
-VirtualNetworkRuleProperties defines the properties of a VirtualNetworkRule.
-
-Appears in:
-
-* [VirtualNetworkRuleSpec](#VirtualNetworkRuleSpec)
-
-
-Name | Type | Description
------|------|------------
-`virtualNetworkSubnetId` | string | VirtualNetworkSubnetID - The ARM resource id of the virtual network subnet.
-`ignoreMissingVnetServiceEndpoint` | bool | IgnoreMissingVnetServiceEndpoint - Create firewall rule before the virtual network has vnet service endpoint enabled.
-
-
-
-## VirtualNetworkRuleSpec
-
-A VirtualNetworkRuleSpec defines the desired state of a VirtualNetworkRule.
-
-Appears in:
-
-* [MysqlServerVirtualNetworkRule](#MysqlServerVirtualNetworkRule)
-* [PostgresqlServerVirtualNetworkRule](#PostgresqlServerVirtualNetworkRule)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name - Name of the Virtual Network Rule.
-`serverName` | string | ServerName - Name of the Virtual Network Rule's server.
-`resourceGroupName` | string | ResourceGroupName - Name of the Virtual Network Rule's resource group.
-`properties` | [VirtualNetworkRuleProperties](#VirtualNetworkRuleProperties) | VirtualNetworkRuleProperties - Resource properties.
-
-
-VirtualNetworkRuleSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## VirtualNetworkRuleStatus
-
-A VirtualNetworkRuleStatus represents the observed state of a VirtualNetworkRule.
-
-Appears in:
-
-* [MysqlServerVirtualNetworkRule](#MysqlServerVirtualNetworkRule)
-* [PostgresqlServerVirtualNetworkRule](#PostgresqlServerVirtualNetworkRule)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State of this virtual network rule.
-`message` | string | A Message containing details about the state of this virtual network rule, if any.
-`id` | string | ID - Resource ID
-`type` | string | Type - Resource type.
-
-
-VirtualNetworkRuleStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-azure/network-azure-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-azure/network-azure-crossplane-io-v1alpha2.md
deleted file mode 100644
index f40830ef..00000000
--- a/docs/v0.3/api/crossplaneio/stack-azure/network-azure-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,197 +0,0 @@
-# network.azure.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for Azure network services such as virtual networks.
-
-This API group contains the following Crossplane resources:
-
-* [Subnet](#Subnet)
-* [VirtualNetwork](#VirtualNetwork)
-
-## Subnet
-
-A Subnet is a managed resource that represents an Azure Subnet.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `network.azure.crossplane.io/v1alpha2`
-`kind` | string | `Subnet`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [SubnetSpec](#SubnetSpec) | A SubnetSpec defines the desired state of a Subnet.
-`status` | [SubnetStatus](#SubnetStatus) | A SubnetStatus represents the observed state of a Subnet.
-
-
-
-## VirtualNetwork
-
-A VirtualNetwork is a managed resource that represents an Azure Virtual Network.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `network.azure.crossplane.io/v1alpha2`
-`kind` | string | `VirtualNetwork`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [VirtualNetworkSpec](#VirtualNetworkSpec) | A VirtualNetworkSpec defines the desired state of a VirtualNetwork.
-`status` | [VirtualNetworkStatus](#VirtualNetworkStatus) | A VirtualNetworkStatus represents the observed state of a VirtualNetwork.
-
-
-
-## AddressSpace
-
-AddressSpace contains an array of IP address ranges that can be used by subnets of the virtual network.
-
-Appears in:
-
-* [VirtualNetworkPropertiesFormat](#VirtualNetworkPropertiesFormat)
-
-
-Name | Type | Description
------|------|------------
-`addressPrefixes` | []string | AddressPrefixes - A list of address blocks reserved for this virtual network in CIDR notation.
-
-
-
-## ServiceEndpointPropertiesFormat
-
-ServiceEndpointPropertiesFormat defines properties of a service endpoint.
-
-Appears in:
-
-* [SubnetPropertiesFormat](#SubnetPropertiesFormat)
-
-
-Name | Type | Description
------|------|------------
-`service` | Optional string | Service - The type of the endpoint service.
-`locations` | Optional []string | Locations - A list of locations.
-`provisioningState` | Optional string | ProvisioningState - The provisioning state of the resource.
-
-
-
-## SubnetPropertiesFormat
-
-SubnetPropertiesFormat defines properties of a Subnet.
-
-Appears in:
-
-* [SubnetSpec](#SubnetSpec)
-
-
-Name | Type | Description
------|------|------------
-`addressPrefix` | string | AddressPrefix - The address prefix for the subnet.
-`serviceEndpoints` | [[]ServiceEndpointPropertiesFormat](#ServiceEndpointPropertiesFormat) | ServiceEndpoints - An array of service endpoints.
-
-
-
-## SubnetSpec
-
-A SubnetSpec defines the desired state of a Subnet.
-
-Appears in:
-
-* [Subnet](#Subnet)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name - The name of the resource that is unique within a resource group. This name can be used to access the resource.
-`virtualNetworkName` | string | VirtualNetworkName - Name of the Subnet's virtual network.
-`resourceGroupName` | string | ResourceGroupName - Name of the Subnet's resource group.
-`properties` | [SubnetPropertiesFormat](#SubnetPropertiesFormat) | SubnetPropertiesFormat - Properties of the subnet.
-
-
-SubnetSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## SubnetStatus
-
-A SubnetStatus represents the observed state of a Subnet.
-
-Appears in:
-
-* [Subnet](#Subnet)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State of this Subnet.
-`message` | string | A Message providing detail about the state of this Subnet, if any.
-`etag` | string | Etag - A unique string that changes whenever the resource is updated.
-`id` | string | ID of this Subnet.
-`purpose` | string | Purpose - A string identifying the intention of use for this subnet based on delegations and other user-defined properties.
-
-
-SubnetStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## VirtualNetworkPropertiesFormat
-
-VirtualNetworkPropertiesFormat defines properties of a VirtualNetwork.
-
-Appears in:
-
-* [VirtualNetworkSpec](#VirtualNetworkSpec)
-
-
-Name | Type | Description
------|------|------------
-`addressSpace` | Optional [AddressSpace](#AddressSpace) | AddressSpace - The AddressSpace that contains an array of IP address ranges that can be used by subnets.
-`enableDdosProtection` | Optional bool | EnableDDOSProtection - Indicates if DDoS protection is enabled for all the protected resources in the virtual network. It requires a DDoS protection plan associated with the resource.
-`enableVmProtection` | Optional bool | EnableVMProtection - Indicates if VM protection is enabled for all the subnets in the virtual network.
-
-
-
-## VirtualNetworkSpec
-
-A VirtualNetworkSpec defines the desired state of a VirtualNetwork.
-
-Appears in:
-
-* [VirtualNetwork](#VirtualNetwork)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name - Name of the Virtual Network.
-`resourceGroupName` | string | ResourceGroupName - Name of the Virtual Network's resource group.
-`properties` | [VirtualNetworkPropertiesFormat](#VirtualNetworkPropertiesFormat) | VirtualNetworkPropertiesFormat - Properties of the virtual network.
-`location` | string | Location - Resource location.
-`tags` | Optional map[string]string | Tags - Resource tags.
-
-
-VirtualNetworkSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## VirtualNetworkStatus
-
-A VirtualNetworkStatus represents the observed state of a VirtualNetwork.
-
-Appears in:
-
-* [VirtualNetwork](#VirtualNetwork)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State of this VirtualNetwork.
-`message` | string | A Message providing detail about the state of this VirtualNetwork, if any.
-`id` | string | ID of this VirtualNetwork.
-`etag` | string | Etag - A unique read-only string that changes whenever the resource is updated.
-`resourceGuid` | string | ResourceGUID - The GUID of this VirtualNetwork.
-`type` | string | Type of this VirtualNetwork.
-
-
-VirtualNetworkStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-azure/storage-azure-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-azure/storage-azure-crossplane-io-v1alpha2.md
deleted file mode 100644
index 8fbbc0de..00000000
--- a/docs/v0.3/api/crossplaneio/stack-azure/storage-azure-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,469 +0,0 @@
-# storage.azure.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for Azure storage services such as containers and accounts.
-
-This API group contains the following Crossplane resources:
-
-* [Account](#Account)
-* [AccountClass](#AccountClass)
-* [Container](#Container)
-* [ContainerClass](#ContainerClass)
-
-## Account
-
-An Account is a managed resource that represents an Azure Blob Service Account.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.azure.crossplane.io/v1alpha2`
-`kind` | string | `Account`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [AccountSpec](#AccountSpec) | An AccountSpec defines the desired state of an Account.
-`status` | [AccountStatus](#AccountStatus) | An AccountStatus represents the observed state of an Account.
-
-
-
-## AccountClass
-
-An AccountClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.azure.crossplane.io/v1alpha2`
-`kind` | string | `AccountClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [AccountClassSpecTemplate](#AccountClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned Account.
-
-
-
-## Container
-
-A Container is a managed resource that represents an Azure Blob Storage Container.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.azure.crossplane.io/v1alpha2`
-`kind` | string | `Container`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ContainerSpec](#ContainerSpec) | A ContainerSpec defines the desired state of a Container.
-`status` | [ContainerStatus](#ContainerStatus) | A ContainerStatus represents the observed status of a Container.
-
-
-
-## ContainerClass
-
-A ContainerClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.azure.crossplane.io/v1alpha2`
-`kind` | string | `ContainerClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [ContainerClassSpecTemplate](#ContainerClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned Container.
-
-
-
-## AccountClassSpecTemplate
-
-An AccountClassSpecTemplate is a template for the spec of a dynamically provisioned Account.
-
-Appears in:
-
-* [AccountClass](#AccountClass)
-
-
-
-
-AccountClassSpecTemplate supports all fields of:
-
-* [v1alpha1.NonPortableClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#nonportableclassspectemplate)
-* [AccountParameters](#AccountParameters)
-
-
-## AccountParameters
-
-AccountParameters define the desired state of an Azure Blob Storage Account.
-
-Appears in:
-
-* [AccountClassSpecTemplate](#AccountClassSpecTemplate)
-* [AccountSpec](#AccountSpec)
-
-
-Name | Type | Description
------|------|------------
-`resourceGroupName` | string | ResourceGroupName specifies the resource group for this Account.
-`storageAccountName` | string | StorageAccountName specifies the name for this Account.
-`storageAccountSpec` | [StorageAccountSpec](#StorageAccountSpec) | StorageAccountSpec specifies the desired state of this Account.
-
-
-
-## AccountSpec
-
-An AccountSpec defines the desired state of an Account.
-
-Appears in:
-
-* [Account](#Account)
-
-
-
-
-AccountSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [AccountParameters](#AccountParameters)
-
-
-## AccountStatus
-
-An AccountStatus represents the observed state of an Account.
-
-Appears in:
-
-* [Account](#Account)
-
-
-
-
-AccountStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [StorageAccountStatus](#StorageAccountStatus)
-
-
-## ContainerClassSpecTemplate
-
-A ContainerClassSpecTemplate is a template for the spec of a dynamically provisioned Container.
-
-Appears in:
-
-* [ContainerClass](#ContainerClass)
-
-
-
-
-ContainerClassSpecTemplate supports all fields of:
-
-* [v1alpha1.NonPortableClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#nonportableclassspectemplate)
-* [ContainerParameters](#ContainerParameters)
-
-
-## ContainerParameters
-
-ContainerParameters define the desired state of an Azure Blob Storage Container.
-
-Appears in:
-
-* [ContainerClassSpecTemplate](#ContainerClassSpecTemplate)
-* [ContainerSpec](#ContainerSpec)
-
-
-Name | Type | Description
------|------|------------
-`nameFormat` | string | NameFormat specifies the name of the external Container. The first instance of the string '%s' will be replaced with the Kubernetes UID of this Container.
-`metadata` | Optional [azblob.Metadata](https://godoc.org/github.com/Azure/azure-storage-blob-go/azblob#Metadata) | Metadata for this Container.
-`publicAccessType` | Optional [azblob.PublicAccessType](https://godoc.org/github.com/Azure/azure-storage-blob-go/azblob#PublicAccessType) | PublicAccessType for this container; either "blob" or "container".
-`accountReference` | [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core) | AccountReference to the Azure Blob Storage Account this Container will reside within.
-
-
-
-## ContainerSpec
-
-A ContainerSpec defines the desired state of a Container.
-
-Appears in:
-
-* [Container](#Container)
-
-
-Name | Type | Description
------|------|------------
-`writeConnectionSecretToRef` | Optional [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core) | WriteConnectionSecretToReference specifies the name of a Secret, in the same namespace as this managed resource, to which any connection details for this managed resource should be written. Connection details frequently include the endpoint, username, and password required to connect to the managed resource.
-`claimRef` | Optional [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | ClaimReference specifies the resource claim to which this managed resource will be bound. ClaimReference is set automatically during dynamic provisioning. Crossplane does not currently support setting this field manually, per https://github.com/crossplaneio/crossplane-runtime/issues/19
-`classRef` | Optional [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | NonPortableClassReference specifies the non-portable resource class that was used to dynamically provision this managed resource, if any. Crossplane does not currently support setting this field manually, per https://github.com/crossplaneio/crossplane-runtime/issues/20
-`reclaimPolicy` | Optional [v1alpha1.ReclaimPolicy](../crossplane-runtime/core-crossplane-io-v1alpha1.md#reclaimpolicy) | ReclaimPolicy specifies what will happen to the external resource this managed resource manages when the managed resource is deleted. "Delete" deletes the external resource, while "Retain" (the default) does not. Note this behaviour is subtly different from other uses of the ReclaimPolicy concept within the Kubernetes ecosystem per https://github.com/crossplaneio/crossplane-runtime/issues/21
-
-
-ContainerSpec supports all fields of:
-
-* [ContainerParameters](#ContainerParameters)
-
-
-## ContainerStatus
-
-A ContainerStatus represents the observed status of a Container.
-
-Appears in:
-
-* [Container](#Container)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name of this Container.
-
-
-ContainerStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## CustomDomain
-
-CustomDomain specifies the custom domain assigned to this storage account.
-
-Appears in:
-
-* [StorageAccountSpecProperties](#StorageAccountSpecProperties)
-
-
-Name | Type | Description
------|------|------------
-`name` | Optional string | Name - custom domain name assigned to the storage account. Name is the CNAME source.
-`useSubDomainName` | Optional bool | UseSubDomainName - Indicates whether indirect CNAME validation is enabled.
-
-
-
-## EnabledEncryptionServices
-
-EnabledEncryptionServices a list of services that support encryption.
-
-Appears in:
-
-* [Encryption](#Encryption)
-
-
-Name | Type | Description
------|------|------------
-`blob` | bool | Blob - The encryption function of the blob storage service.
-`file` | bool | File - The encryption function of the file storage service.
-`table` | bool | Table - The encryption function of the table storage service.
-`queue` | bool | Queue - The encryption function of the queue storage service.
-
-
-
-## Encryption
-
-Encryption the encryption settings on the storage account.
-
-Appears in:
-
-* [StorageAccountSpecProperties](#StorageAccountSpecProperties)
-
-
-Name | Type | Description
------|------|------------
-`services` | [EnabledEncryptionServices](#EnabledEncryptionServices) | Services - List of services which support encryption.
-`keySource` | [storage.KeySource](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#KeySource) | KeySource - The encryption keySource (provider). Possible values (case-insensitive): Microsoft.Storage, Microsoft.Keyvault
-`keyvaultproperties` | [KeyVaultProperties](#KeyVaultProperties) | KeyVaultProperties - Properties provided by key vault.
-
-
-
-## Endpoints
-
-Endpoints the URIs that are used to perform a retrieval of a public blob, queue, or table object.
-
-Appears in:
-
-* [StorageAccountStatusProperties](#StorageAccountStatusProperties)
-
-
-Name | Type | Description
------|------|------------
-`blob` | string | Blob - the blob endpoint.
-`queue` | string | Queue - the queue endpoint.
-`table` | string | Table - the table endpoint.
-`file` | string | File - the file endpoint.
-
-
-
-## IPRule
-
-IPRule IP rule with specific IP or IP range in CIDR format.
-
-Appears in:
-
-* [NetworkRuleSet](#NetworkRuleSet)
-
-
-Name | Type | Description
------|------|------------
-`value` | string | IPAddressOrRange - Specifies the IP or IP range in CIDR format. Only IPV4 address is allowed.
-`action` | [storage.Action](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#Action) | Action - The action of IP ACL rule. Possible values include: 'Allow'
-
-
-
-## Identity
-
-Identity identity for the resource.
-
-Appears in:
-
-* [StorageAccountSpec](#StorageAccountSpec)
-
-
-Name | Type | Description
------|------|------------
-`principalId` | string | PrincipalID - The principal ID of resource identity.
-`tenantId` | string | TenantID - The tenant ID of resource.
-`type` | string | Type - The identity type.
-
-
-
-## KeyVaultProperties
-
-KeyVaultProperties properties of key vault.
-
-Appears in:
-
-* [Encryption](#Encryption)
-
-
-Name | Type | Description
------|------|------------
-`keyname` | string | KeyName - The name of KeyVault key.
-`keyversion` | string | KeyVersion - The version of KeyVault key.
-`keyvaulturi` | string | KeyVaultURI - The Uri of KeyVault.
-
-
-
-## NetworkRuleSet
-
-NetworkRuleSet network rule set
-
-Appears in:
-
-* [StorageAccountSpecProperties](#StorageAccountSpecProperties)
-
-
-Name | Type | Description
------|------|------------
-`bypass` | [storage.Bypass](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#Bypass) | Bypass - Specifies whether traffic is bypassed for Logging/Metrics/AzureServices. Possible values are any combination of Logging|Metrics|AzureServices (For example, "Logging, Metrics"), or None to bypass none of those traffics. Possible values include: 'None', 'Logging', 'Metrics', 'AzureServices'
-`virtualNetworkRules` | [[]VirtualNetworkRule](#VirtualNetworkRule) | VirtualNetworkRules - Sets the virtual network rules
-`ipRules` | [[]IPRule](#IPRule) | IPRules - Sets the IP ACL rules
-`defaultAction` | [storage.DefaultAction](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#DefaultAction) | DefaultAction - Specifies the default action of allow or deny when no other rules match. Possible values include: 'Allow', 'Deny'
-
-
-
-## Sku
-
-Sku of an Azure Blob Storage Account.
-
-Appears in:
-
-* [StorageAccountSpec](#StorageAccountSpec)
-
-
-Name | Type | Description
------|------|------------
-`capabilities` | [[]skuCapability](#skuCapability) | Capabilities - The capability information in the specified sku, including file encryption, network acls, change notification, etc.
-`kind` | [storage.Kind](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#Kind) | Kind - Indicates the type of storage account. Possible values include: 'Storage', 'BlobStorage'
-`locations` | []string | Locations - The set of locations that the Sku is available. This will be supported and registered Azure Geo Regions (e.g. West US, East US, Southeast Asia, etc.).
-`name` | [storage.SkuName](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#SkuName) | Name - Gets or sets the sku name. Required for account creation; optional for update. Note that in older versions, sku name was called accountType. Possible values include: 'Standard_LRS', 'Standard_GRS', 'Standard_RAGRS', 'Standard_ZRS', 'Premium_LRS'
-`resourceType` | string | ResourceType - The type of the resource, usually it is 'storageAccounts'.
-`tier` | [storage.SkuTier](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#SkuTier) | Tier - Gets the sku tier. This is based on the Sku name. Possible values include: 'Standard', 'Premium'
-
-
-
-## StorageAccountSpec
-
-A StorageAccountSpec defines the desired state of an Azure Blob Storage account.
-
-Appears in:
-
-* [AccountParameters](#AccountParameters)
-
-
-Name | Type | Description
------|------|------------
-`identity` | Optional [Identity](#Identity) | Identity - The identity of the resource.
-`kind` | [storage.Kind](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#Kind) | Kind - Indicates the type of storage account. Possible values include: 'Storage', 'BlobStorage'
-`location` | string | Location - The location of the resource. This will be one of the supported and registered Azure Geo Regions (e.g. West US, East US, Southeast Asia, etc.).
-`sku` | [Sku](#Sku) | Sku of the storage account.
-`properties` | Optional [StorageAccountSpecProperties](#StorageAccountSpecProperties) | StorageAccountSpecProperties - The parameters used to create the storage account.
-`tags` | Optional map[string]string | Tags - A list of key value pairs that describe the resource. These tags can be used for viewing and grouping this resource (across resource groups). A maximum of 15 tags can be provided for a resource. Each tag must have a key with a length no greater than 128 characters and a value with a length no greater than 256 characters.
-
-
-
-## StorageAccountSpecProperties
-
-StorageAccountSpecProperties the parameters used to create the storage account.
-
-Appears in:
-
-* [StorageAccountSpec](#StorageAccountSpec)
-
-
-Name | Type | Description
------|------|------------
-`accessTier` | [storage.AccessTier](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#AccessTier) | AccessTier - Required for storage accounts where kind = BlobStorage. The access tier used for billing. Possible values include: 'Hot', 'Cool'
-`customDomain` | [CustomDomain](#CustomDomain) | CustomDomain - User domain assigned to the storage account. Name is the CNAME source. Only one custom domain is supported per storage account at this time. to clear the existing custom domain, use an empty string for the custom domain name property.
-`supportsHttpsTrafficOnly` | bool | EnableHTTPSTrafficOnly - Allows https traffic only to storage service if sets to true.
-`encryption` | [Encryption](#Encryption) | Encryption - Provides the encryption settings on the account. If left unspecified the account encryption settings will remain the same. The default setting is unencrypted.
-`networkAcls` | [NetworkRuleSet](#NetworkRuleSet) | NetworkRuleSet - Network rule set
-
-
-
-## StorageAccountStatus
-
-A StorageAccountStatus represents the observed status of an Account.
-
-Appears in:
-
-* [AccountStatus](#AccountStatus)
-
-
-Name | Type | Description
------|------|------------
-`id` | string | ID of this Account.
-`name` | string | Name of this Account.
-`type` | string | Type of this Account.
-`properties` | [StorageAccountStatusProperties](#StorageAccountStatusProperties) | Properties of this Account.
-
-
-
-## StorageAccountStatusProperties
-
-StorageAccountStatusProperties represent the observed state of an Account.
-
-Appears in:
-
-* [StorageAccountStatus](#StorageAccountStatus)
-
-
-Name | Type | Description
------|------|------------
-`creationTime` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | CreationTime - the creation date and time of the storage account in UTC.
-`lastGeoFailoverTime` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | LastGeoFailoverTime - the timestamp of the most recent instance of a failover to the secondary location. Only the most recent timestamp is retained. This element is not returned if there has never been a failover instance. Only available if the accountType is Standard_GRS or Standard_RAGRS.
-`primaryEndpoints` | [Endpoints](#Endpoints) | PrimaryEndpoints - the URLs that are used to perform a retrieval of a public blob, queue, or table object. Note that Standard_ZRS and Premium_LRS accounts only return the blob endpoint.
-`primaryLocation` | string | PrimaryLocation - the location of the primary data center for the storage account.
-`provisioningState` | [storage.ProvisioningState](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#ProvisioningState) | ProvisioningState - the status of the storage account at the time the operation was called. Possible values include: 'Creating', 'ResolvingDNS', 'Succeeded'
-`secondaryEndpoints` | [Endpoints](#Endpoints) | SecondaryEndpoints - the URLs that are used to perform a retrieval of a public blob, queue, or table object from the secondary location of the storage account. Only available if the Sku name is Standard_RAGRS.
-`secondaryLocation` | string | SecondaryLocation - the location of the geo-replicated secondary for the storage account. Only available if the accountType is Standard_GRS or Standard_RAGRS.
-`statusOfPrimary` | [storage.AccountStatus](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#AccountStatus) | StatusOfPrimary - the status indicating whether the primary location of the storage account is available or unavailable. Possible values include: 'Available', 'Unavailable'
-`statusOfSecondary` | [storage.AccountStatus](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#AccountStatus) | StatusOfSecondary - the status indicating whether the secondary location of the storage account is available or unavailable. Only available if the Sku name is Standard_GRS or Standard_RAGRS. Possible values include: 'Available', 'Unavailable'
-
-
-
-## VirtualNetworkRule
-
-VirtualNetworkRule virtual Network rule.
-
-Appears in:
-
-* [NetworkRuleSet](#NetworkRuleSet)
-
-
-Name | Type | Description
------|------|------------
-`id` | string | VirtualNetworkResourceID - Resource ID of a subnet, for example: /subscriptions/{subscriptionId}/resourceGroups/{groupName}/providers/Microsoft.Network/virtualNetworks/{vnetName}/subnets/{subnetName}.
-`action` | [storage.Action](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#Action) | Action - The action of virtual network rule. Possible values include: 'Allow'
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-gcp/cache-gcp-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-gcp/cache-gcp-crossplane-io-v1alpha2.md
deleted file mode 100644
index 46a30d5a..00000000
--- a/docs/v0.3/api/crossplaneio/stack-gcp/cache-gcp-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,121 +0,0 @@
-# cache.gcp.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for GCP cache services such as CloudMemorystore.
-
-This API group contains the following Crossplane resources:
-
-* [CloudMemorystoreInstance](#CloudMemorystoreInstance)
-* [CloudMemorystoreInstanceClass](#CloudMemorystoreInstanceClass)
-
-## CloudMemorystoreInstance
-
-A CloudMemorystoreInstance is a managed resource that represents a Google Cloud Memorystore instance.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.gcp.crossplane.io/v1alpha2`
-`kind` | string | `CloudMemorystoreInstance`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [CloudMemorystoreInstanceSpec](#CloudMemorystoreInstanceSpec) | A CloudMemorystoreInstanceSpec defines the desired state of a CloudMemorystoreInstance.
-`status` | [CloudMemorystoreInstanceStatus](#CloudMemorystoreInstanceStatus) | A CloudMemorystoreInstanceStatus represents the observed state of a CloudMemorystoreInstance.
-
-
-
-## CloudMemorystoreInstanceClass
-
-A CloudMemorystoreInstanceClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.gcp.crossplane.io/v1alpha2`
-`kind` | string | `CloudMemorystoreInstanceClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [CloudMemorystoreInstanceClassSpecTemplate](#CloudMemorystoreInstanceClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned CloudMemorystoreInstance.
-
-
-
-## CloudMemorystoreInstanceClassSpecTemplate
-
-A CloudMemorystoreInstanceClassSpecTemplate is a template for the spec of a dynamically provisioned CloudMemorystoreInstance.
-
-Appears in:
-
-* [CloudMemorystoreInstanceClass](#CloudMemorystoreInstanceClass)
-
-
-
-
-CloudMemorystoreInstanceClassSpecTemplate supports all fields of:
-
-* [v1alpha1.NonPortableClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#nonportableclassspectemplate)
-* [CloudMemorystoreInstanceParameters](#CloudMemorystoreInstanceParameters)
-
-
-## CloudMemorystoreInstanceParameters
-
-CloudMemorystoreInstanceParameters define the desired state of an Google Cloud Memorystore instance. Most fields map directly to an Instance: https://cloud.google.com/memorystore/docs/redis/reference/rest/v1/projects.locations.instances#Instance
-
-Appears in:
-
-* [CloudMemorystoreInstanceClassSpecTemplate](#CloudMemorystoreInstanceClassSpecTemplate)
-* [CloudMemorystoreInstanceSpec](#CloudMemorystoreInstanceSpec)
-
-
-Name | Type | Description
------|------|------------
-`region` | string | Region in which to create this Cloud Memorystore cluster.
-`tier` | string | Tier specifies the replication level of the Redis cluster. BASIC provides a single Redis instance with no high availability. STANDARD_HA provides a cluster of two Redis instances in distinct availability zones. https://cloud.google.com/memorystore/docs/redis/redis-tiers
-`locationId` | Optional string | LocationID specifies the zone where the instance will be provisioned. If not provided, the service will choose a zone for the instance. For STANDARD_HA tier, instances will be created across two zones for protection against zonal failures.
-`alternativeLocationId` | Optional string | AlternativeLocationID is only applicable to STANDARD_HA tier, which protects the instance against zonal failures by provisioning it across two zones. If provided, it must be a different zone from the one provided in locationId.
-`memorySizeGb` | int | MemorySizeGB specifies the Redis memory size in GiB.
-`reservedIpRange` | Optional string | ReservedIPRange specifies the CIDR range of internal addresses that are reserved for this instance. If not provided, the service will choose an unused /29 block, for example, 10.0.0.0/29 or 192.168.0.0/29. Ranges must be unique and non-overlapping with existing subnets in an authorized network.
-`authorizedNetwork` | Optional string | AuthorizedNetwork specifies the full name of the Google Compute Engine network to which the instance is connected. If left unspecified, the default network will be used.
-`redisVersion` | Optional string | RedisVersion specifies the version of Redis software. If not provided, latest supported version will be used. Updating the version will perform an upgrade/downgrade to the new version. Currently, the supported values are REDIS_3_2 for Redis 3.2, and REDIS_4_0 for Redis 4.0 (the default).
-`redisConfigs` | Optional map[string]string | RedisConfigs specifies Redis configuration parameters, according to http://redis.io/topics/config. Currently, the only supported parameters are: * maxmemory-policy * notify-keyspace-events
-
-
-
-## CloudMemorystoreInstanceSpec
-
-A CloudMemorystoreInstanceSpec defines the desired state of a CloudMemorystoreInstance.
-
-Appears in:
-
-* [CloudMemorystoreInstance](#CloudMemorystoreInstance)
-
-
-
-
-CloudMemorystoreInstanceSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [CloudMemorystoreInstanceParameters](#CloudMemorystoreInstanceParameters)
-
-
-## CloudMemorystoreInstanceStatus
-
-A CloudMemorystoreInstanceStatus represents the observed state of a CloudMemorystoreInstance.
-
-Appears in:
-
-* [CloudMemorystoreInstance](#CloudMemorystoreInstance)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State of this instance.
-`message` | string | Additional information about the current status of this instance, if available.
-`providerID` | string | ProviderID is the external ID to identify this resource in the cloud provider, e.g. 'projects/fooproj/locations/us-foo1/instances/foo'
-`currentLocationId` | string | CurrentLocationID is the current zone where the Redis endpoint is placed. For Basic Tier instances, this will always be the same as the locationId provided by the user at creation time. For Standard Tier instances, this can be either locationId or alternativeLocationId and can change after a failover event.
-`endpoint` | string | Endpoint of the Cloud Memorystore instance used in connection strings.
-`port` | int | Port at which the Cloud Memorystore instance endpoint is listening.
-
-
-CloudMemorystoreInstanceStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-gcp/compute-gcp-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-gcp/compute-gcp-crossplane-io-v1alpha2.md
deleted file mode 100644
index 841d6818..00000000
--- a/docs/v0.3/api/crossplaneio/stack-gcp/compute-gcp-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,440 +0,0 @@
-# compute.gcp.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for GCP compute services such as GKE.
-
-This API group contains the following Crossplane resources:
-
-* [GKECluster](#GKECluster)
-* [GKEClusterClass](#GKEClusterClass)
-* [GlobalAddress](#GlobalAddress)
-* [Network](#Network)
-* [Subnetwork](#Subnetwork)
-
-## GKECluster
-
-A GKECluster is a managed resource that represents a Google Kubernetes Engine cluster.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.gcp.crossplane.io/v1alpha2`
-`kind` | string | `GKECluster`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [GKEClusterSpec](#GKEClusterSpec) | A GKEClusterSpec defines the desired state of a GKECluster.
-`status` | [GKEClusterStatus](#GKEClusterStatus) | A GKEClusterStatus represents the observed state of a GKECluster.
-
-
-
-## GKEClusterClass
-
-A GKEClusterClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.gcp.crossplane.io/v1alpha2`
-`kind` | string | `GKEClusterClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [GKEClusterClassSpecTemplate](#GKEClusterClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned GKECluster.
-
-
-
-## GlobalAddress
-
-A GlobalAddress is a managed resource that represents a Google Compute Engine Global Address.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.gcp.crossplane.io/v1alpha2`
-`kind` | string | `GlobalAddress`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [GlobalAddressSpec](#GlobalAddressSpec) | A GlobalAddressSpec defines the desired state of a GlobalAddress.
-`status` | [GlobalAddressStatus](#GlobalAddressStatus) | A GlobalAddressStatus reflects the observed state of a GlobalAddress.
-
-
-
-## Network
-
-A Network is a managed resource that represents a Google Compute Engine VPC Network.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.gcp.crossplane.io/v1alpha2`
-`kind` | string | `Network`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [NetworkSpec](#NetworkSpec) | A NetworkSpec defines the desired state of a Network.
-`status` | [NetworkStatus](#NetworkStatus) | A NetworkStatus represents the observed state of a Network.
-
-
-
-## Subnetwork
-
-A Subnetwork is a managed resource that represents a Google Compute Engine VPC Subnetwork.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.gcp.crossplane.io/v1alpha2`
-`kind` | string | `Subnetwork`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [SubnetworkSpec](#SubnetworkSpec) | A SubnetworkSpec defines the desired state of a Subnetwork.
-`status` | [SubnetworkStatus](#SubnetworkStatus) | A SubnetworkStatus represents the observed state of a Subnetwork.
-
-
-
-## GCPNetworkPeering
-
-A GCPNetworkPeering represents the observed state of a Google Compute Engine VPC Network Peering.
-
-
-Name | Type | Description
------|------|------------
-`autoCreateRoutes` | bool | AutoCreateRoutes: This field will be deprecated soon. Use the exchange_subnet_routes field instead. Indicates whether full mesh connectivity is created and managed automatically between peered networks. Currently this field should always be true since Google Compute Engine will automatically create and manage subnetwork routes between two networks when peering state is ACTIVE.
-`exchangeSubnetRoutes` | bool | ExchangeSubnetRoutes: Indicates whether full mesh connectivity is created and managed automatically between peered networks. Currently this field should always be true since Google Compute Engine will automatically create and manage subnetwork routes between two networks when peering state is ACTIVE.
-`name` | string | Name: Name of this peering. Provided by the client when the peering is created. The name must comply with RFC1035. Specifically, the name must be 1-63 characters long and match regular expression `[a-z]([-a-z0-9]*[a-z0-9])?`. The first character must be a lowercase letter, and all the following characters must be a dash, lowercase letter, or digit, except the last character, which cannot be a dash.
-`network` | string | Network: The URL of the peer network. It can be either full URL or partial URL. The peer network may belong to a different project. If the partial URL does not contain project, it is assumed that the peer network is in the same project as the current network.
-`state` | string | State: State for the peering, either `ACTIVE` or `INACTIVE`. The peering is `ACTIVE` when there's a matching configuration in the peer network. Possible values: "ACTIVE" "INACTIVE"
-`stateDetails` | string | StateDetails: Details about the current state of the peering.
-
-
-
-## GCPNetworkRoutingConfig
-
-A GCPNetworkRoutingConfig specifies the desired state of a Google Compute Engine VPC Network Routing configuration.
-
-Appears in:
-
-* [GCPNetworkStatus](#GCPNetworkStatus)
-* [NetworkParameters](#NetworkParameters)
-
-
-Name | Type | Description
------|------|------------
-`routingMode` | string | RoutingMode: The network-wide routing mode to use. If set to REGIONAL, this network's Cloud Routers will only advertise routes with subnets of this network in the same region as the router. If set to GLOBAL, this network's Cloud Routers will advertise routes with all subnets of this network, across regions. Possible values: "GLOBAL" "REGIONAL"
-
-
-
-## GCPNetworkStatus
-
-A GCPNetworkStatus represents the observed state of a Google Compute Engine VPC Network.
-
-Appears in:
-
-* [NetworkStatus](#NetworkStatus)
-
-
-Name | Type | Description
------|------|------------
-`IPv4Range` | string | IPv4Range: Deprecated in favor of subnet mode networks. The range of internal addresses that are legal on this network. This range is a CIDR specification, for example: 192.168.0.0/16. Provided by the client when the network is created.
-`autoCreateSubnetworks` | bool | AutoCreateSubnetworks: When set to true, the VPC network is created in "auto" mode. When set to false, the VPC network is created in "custom" mode. An auto mode VPC network starts with one subnet per region. Each subnet has a predetermined range as described in Auto mode VPC network IP ranges.
-`creationTimestamp` | string | CreationTimestamp: Creation timestamp in RFC3339 text format.
-`description` | string | Description: An optional description of this resource. Provide this field when you create the resource.
-`gatewayIPv4` | string | GatewayIPv4: The gateway address for default routing out of the network, selected by GCP.
-`id` | uint64 | Id: The unique identifier for the resource. This identifier is defined by the server.
-`peerings` | [[]*github.com/crossplaneio/stack-gcp/gcp/apis/compute/v1alpha2.GCPNetworkPeering](#*github.com/crossplaneio/stack-gcp/gcp/apis/compute/v1alpha2.GCPNetworkPeering) | Peerings: A list of network peerings for the resource.
-`routingConfig` | [GCPNetworkRoutingConfig](#GCPNetworkRoutingConfig) | RoutingConfig: The network-level routing configuration for this network. Used by Cloud Router to determine what type of network-wide routing behavior to enforce.
-`selfLink` | string | SelfLink: Server-defined URL for the resource.
-`subnetworks` | []string | Subnetworks: Server-defined fully-qualified URLs for all subnetworks in this VPC network.
-
-
-
-## GCPSubnetworkSecondaryRange
-
-A GCPSubnetworkSecondaryRange defines the state of a Google Compute Engine VPC Subnetwork secondary range.
-
-
-Name | Type | Description
------|------|------------
-`ipCidrRange` | string | IPCIDRRange: The range of IP addresses belonging to this subnetwork secondary range. Provide this property when you create the subnetwork. Ranges must be unique and non-overlapping with all primary and secondary IP ranges within a network. Only IPv4 is supported.
-`rangeName` | string | RangeName: The name associated with this subnetwork secondary range, used when adding an alias IP range to a VM instance. The name must be 1-63 characters long, and comply with RFC1035. The name must be unique within the subnetwork.
-
-
-
-## GCPSubnetworkStatus
-
-A GCPSubnetworkStatus represents the observed state of a Google Compute Engine VPC Subnetwork.
-
-Appears in:
-
-* [SubnetworkStatus](#SubnetworkStatus)
-
-
-Name | Type | Description
------|------|------------
-`creationTimestamp` | string | CreationTimestamp: Creation timestamp in RFC3339 text format.
-`description` | string | Description: An optional description of this resource. Provide this property when you create the resource. This field can be set only at resource creation time.
-`enableFlowLogs` | bool | EnableFlowLogs: Whether to enable flow logging for this subnetwork. If this field is not explicitly set, it will not appear in get listings. If not set the default behavior is to disable flow logging.
-`fingerprint` | string | Fingerprint: Fingerprint of this resource. A hash of the contents stored in this object. This field is used in optimistic locking. This field will be ignored when inserting a Subnetwork. An up-to-date fingerprint must be provided in order to update the Subnetwork, otherwise the request will fail with error 412 conditionNotMet. To see the latest fingerprint, make a get() request to retrieve a Subnetwork.
-`gatewayAddress` | string | GatewayAddress: The gateway address for default routes to reach destination addresses outside this subnetwork.
-`id` | uint64 | Id: The unique identifier for the resource. This identifier is defined by the server.
-`ipCidrRange` | string | IPCIDRRange: The range of internal addresses that are owned by this subnetwork. Provide this property when you create the subnetwork. For example, 10.0.0.0/8 or 192.168.0.0/16. Ranges must be unique and non-overlapping within a network. Only IPv4 is supported. This field can be set only at resource creation time.
-`kind` | string | Kind: Type of the resource. Always compute#subnetwork for Subnetwork resources.
-`name` | string | Name: The name of the resource, provided by the client when initially creating the resource. The name must be 1-63 characters long, and comply with RFC1035. Specifically, the name must be 1-63 characters long and match the regular expression `[a-z]([-a-z0-9]*[a-z0-9])?` which means the first character must be a lowercase letter, and all following characters must be a dash, lowercase letter, or digit, except the last character, which cannot be a dash.
-`network` | string | Network: The URL of the network to which this subnetwork belongs, provided by the client when initially creating the subnetwork. Only networks that are in the distributed mode can have subnetworks. This field can be set only at resource creation time.
-`privateIpGoogleAccess` | bool | PrivateIPGoogleAccess: Whether the VMs in this subnet can access Google services without assigned external IP addresses. This field can be both set at resource creation time and updated using setPrivateIPGoogleAccess.
-`region` | string | Region: URL of the region where the Subnetwork resides. This field can be set only at resource creation time.
-`secondaryIpRanges` | [[]*github.com/crossplaneio/stack-gcp/gcp/apis/compute/v1alpha2.GCPSubnetworkSecondaryRange](#*github.com/crossplaneio/stack-gcp/gcp/apis/compute/v1alpha2.GCPSubnetworkSecondaryRange) | SecondaryIPRanges: An array of configurations for secondary IP ranges for VM instances contained in this subnetwork. The primary IP of such VM must belong to the primary ipCidrRange of the subnetwork. The alias IPs may belong to either primary or secondary ranges. This field can be updated with a patch request.
-`selfLink` | string | SelfLink: Server-defined URL for the resource.
-
-
-
-## GKEClusterClassSpecTemplate
-
-A GKEClusterClassSpecTemplate is a template for the spec of a dynamically provisioned GKECluster.
-
-Appears in:
-
-* [GKEClusterClass](#GKEClusterClass)
-
-
-
-
-GKEClusterClassSpecTemplate supports all fields of:
-
-* [v1alpha1.NonPortableClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#nonportableclassspectemplate)
-* [GKEClusterParameters](#GKEClusterParameters)
-
-
-## GKEClusterParameters
-
-GKEClusterParameters define the desired state of a Google Kubernetes Engine cluster.
-
-Appears in:
-
-* [GKEClusterClassSpecTemplate](#GKEClusterClassSpecTemplate)
-* [GKEClusterSpec](#GKEClusterSpec)
-
-
-Name | Type | Description
------|------|------------
-`clusterVersion` | Optional string | ClusterVersion is the initial Kubernetes version for this cluster. Users may specify either explicit versions offered by Kubernetes Engine or version aliases, for example "latest", "1.X", or "1.X.Y". Leave unset to use the default version.
-`labels` | Optional map[string]string | Labels for the cluster to use to annotate any related Google Compute Engine resources.
-`machineType` | Optional string | MachineType is the name of a Google Compute Engine machine type (e.g. n1-standard-1). If unspecified the default machine type is n1-standard-1.
-`numNodes` | int64 | NumNodes is the number of nodes to create in this cluster. You must ensure that your Compute Engine resource quota is sufficient for this number of instances. You must also have available firewall and routes quota.
-`zone` | Optional string | Zone specifies the name of the Google Compute Engine zone in which this cluster resides.
-`scopes` | Optional []string | Scopes are the set of Google API scopes to be made available on all of the node VMs under the "default" service account.
-`network` | Optional string | Network is the name of the Google Compute Engine network to which the cluster is connected. If left unspecified, the default network will be used.
-`subnetwork` | Optional string | Subnetwork is the name of the Google Compute Engine subnetwork to which the cluster is connected.
-`enableIPAlias` | Optional bool | EnableIPAlias determines whether Alias IPs will be used for pod IPs in the cluster.
-`createSubnetwork` | Optional bool | CreateSubnetwork determines whether a new subnetwork will be created automatically for the cluster. Only applicable when EnableIPAlias is true.
-`nodeIPV4CIDR` | Optional string | NodeIPV4CIDR specifies the IP address range of the instance IPs in this cluster. This is applicable only if CreateSubnetwork is true. Omit this field to have a range chosen with the default size. Set it to a netmask (e.g. /24) to have a range chosen with a specific netmask.
-`clusterIPV4CIDR` | Optional string | ClusterIPV4CIDR specifies the IP address range of the pod IPs in this cluster. This is applicable only if EnableIPAlias is true. Omit this field to have a range chosen with the default size. Set it to a netmask (e.g. /24) to have a range chosen with a specific netmask.
-`clusterSecondaryRangeName` | Optional string | ClusterSecondaryRangeName specifies the name of the secondary range to be used for the cluster CIDR block. The secondary range will be used for pod IP addresses. This must be an existing secondary range associated with the cluster subnetwork.
-`serviceIPV4CIDR` | Optional string | ServiceIPV4CIDR specifies the IP address range of service IPs in this cluster. This is applicable only if EnableIPAlias is true. Omit this field to have a range chosen with the default size. Set it to a netmask (e.g. /24) to have a range chosen with a specific netmask.
-`servicesSecondaryRangeName` | string | ServicesSecondaryRangeName specifies the name of the secondary range to be used as for the services CIDR block. The secondary range will be used for service ClusterIPs. This must be an existing secondary range associated with the cluster subnetwork.
-
-
-
-## GKEClusterSpec
-
-A GKEClusterSpec defines the desired state of a GKECluster.
-
-Appears in:
-
-* [GKECluster](#GKECluster)
-
-
-
-
-GKEClusterSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [GKEClusterParameters](#GKEClusterParameters)
-
-
-## GKEClusterStatus
-
-A GKEClusterStatus represents the observed state of a GKECluster.
-
-Appears in:
-
-* [GKECluster](#GKECluster)
-
-
-Name | Type | Description
------|------|------------
-`clusterName` | string | ClusterName is the name of this GKE cluster. The name is automatically generated by Crossplane.
-`endpoint` | string | Endpoint of the GKE cluster used in connection strings.
-`state` | string | State of this GKE cluster.
-
-
-GKEClusterStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## GlobalAddressParameters
-
-GlobalAddressParameters define the desired state of a Google Compute Engine Global Address. Most fields map directly to an Address: https://cloud.google.com/compute/docs/reference/rest/v1/globalAddresses
-
-Appears in:
-
-* [GlobalAddressSpec](#GlobalAddressSpec)
-
-
-Name | Type | Description
------|------|------------
-`address` | Optional string | Address: The static IP address represented by this resource.
-`addressType` | Optional string | AddressType: The type of address to reserve, either INTERNAL or EXTERNAL. If unspecified, defaults to EXTERNAL. Possible values: "EXTERNAL" "INTERNAL" "UNSPECIFIED_TYPE"
-`description` | Optional string | Description: An optional description of this resource.
-`ipVersion` | Optional string | IPVersion: The IP version that will be used by this address. Valid options are IPV4 or IPV6. Possible values: "IPV4" "IPV6" "UNSPECIFIED_VERSION"
-`name` | string | Name of the resource. The name must be 1-63 characters long, and comply with RFC1035. Specifically, the name must be 1-63 characters long and match the regular expression `[a-z]([-a-z0-9]*[a-z0-9])?`. The first character must be a lowercase letter, and all following characters (except for the last character) must be a dash, lowercase letter, or digit. The last character must be a lowercase letter or digit.
-`network` | Optional string | Network: The URL of the network in which to reserve the address. This field can only be used with INTERNAL type with the VPC_PEERING purpose.
-`prefixLength` | Optional int64 | PrefixLength: The prefix length if the resource represents an IP range.
-`purpose` | Optional string | Purpose: The purpose of this resource, which can be one of the following values: - `GCE_ENDPOINT` for addresses that are used by VM instances, alias IP ranges, internal load balancers, and similar resources. - `DNS_RESOLVER` for a DNS resolver address in a subnetwork - `VPC_PEERING` for addresses that are reserved for VPC peer networks. - `NAT_AUTO` for addresses that are external IP addresses automatically reserved for Cloud NAT. Possible values: "DNS_RESOLVER" "GCE_ENDPOINT" "NAT_AUTO" "VPC_PEERING"
-`subnetwork` | Optional string | Subnetwork: The URL of the subnetwork in which to reserve the address. If an IP address is specified, it must be within the subnetwork's IP range. This field can only be used with INTERNAL type with a GCE_ENDPOINT or DNS_RESOLVER purpose.
-
-
-
-## GlobalAddressSpec
-
-A GlobalAddressSpec defines the desired state of a GlobalAddress.
-
-Appears in:
-
-* [GlobalAddress](#GlobalAddress)
-
-
-
-
-GlobalAddressSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [GlobalAddressParameters](#GlobalAddressParameters)
-
-
-## GlobalAddressStatus
-
-A GlobalAddressStatus reflects the observed state of a GlobalAddress.
-
-Appears in:
-
-* [GlobalAddress](#GlobalAddress)
-
-
-Name | Type | Description
------|------|------------
-`creationTimestamp` | string | CreationTimestamp in RFC3339 text format.
-`id` | uint64 | ID for the resource. This identifier is defined by the server.
-`selfLink` | string | SelfLink: Server-defined URL for the resource.
-`status` | string | Status of the address, which can be one of RESERVING, RESERVED, or IN_USE. An address that is RESERVING is currently in the process of being reserved. A RESERVED address is currently reserved and available to use. An IN_USE address is currently being used by another resource and is not available. Possible values: "IN_USE" "RESERVED" "RESERVING"
-`users` | []string | Users that are using this address.
-
-
-GlobalAddressStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## NetworkParameters
-
-NetworkParameters define the desired state of a Google Compute Engine VPC Network. Most fields map directly to a Network: https://cloud.google.com/compute/docs/reference/rest/v1/networks
-
-Appears in:
-
-* [NetworkSpec](#NetworkSpec)
-
-
-Name | Type | Description
------|------|------------
-`IPv4Range` | string | IPv4Range: Deprecated in favor of subnet mode networks. The range of internal addresses that are legal on this network. This range is a CIDR specification, for example: 192.168.0.0/16. Provided by the client when the network is created.
-`autoCreateSubnetworks` | bool | AutoCreateSubnetworks: When set to true, the VPC network is created in "auto" mode. When set to false, the VPC network is created in "custom" mode. When set to nil, the VPC network is created in "legacy" mode which will be deprecated by GCP soon. An auto mode VPC network starts with one subnet per region. Each subnet has a predetermined range as described in Auto mode VPC network IP ranges.
-`description` | string | Description: An optional description of this resource. Provide this field when you create the resource.
-`name` | string | Name: Name of the resource. Provided by the client when the resource is created. The name must be 1-63 characters long, and comply with RFC1035. Specifically, the name must be 1-63 characters long and match the regular expression `[a-z]([-a-z0-9]*[a-z0-9])?. The first character must be a lowercase letter, and all following characters (except for the last character) must be a dash, lowercase letter, or digit. The last character must be a lowercase letter or digit.
-`routingConfig` | [GCPNetworkRoutingConfig](#GCPNetworkRoutingConfig) | RoutingConfig: The network-level routing configuration for this network. Used by Cloud Router to determine what type of network-wide routing behavior to enforce.
-
-
-
-## NetworkSpec
-
-A NetworkSpec defines the desired state of a Network.
-
-Appears in:
-
-* [Network](#Network)
-
-
-
-
-NetworkSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [NetworkParameters](#NetworkParameters)
-
-
-## NetworkStatus
-
-A NetworkStatus represents the observed state of a Network.
-
-Appears in:
-
-* [Network](#Network)
-
-
-
-
-NetworkStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [GCPNetworkStatus](#GCPNetworkStatus)
-
-
-## SubnetworkParameters
-
-SubnetworkParameters define the desired state of a Google Compute Engine VPC Subnetwork. Most fields map directly to a Subnetwork: https://cloud.google.com/compute/docs/reference/rest/v1/subnetworks
-
-Appears in:
-
-* [SubnetworkSpec](#SubnetworkSpec)
-
-
-Name | Type | Description
------|------|------------
-`description` | Optional string | Description: An optional description of this resource. Provide this property when you create the resource. This field can be set only at resource creation time.
-`enableFlowLogs` | Optional bool | EnableFlowLogs: Whether to enable flow logging for this subnetwork. If this field is not explicitly set, it will not appear in get listings. If not set the default behavior is to disable flow logging.
-`ipCidrRange` | string | IPCIDRRange: The range of internal addresses that are owned by this subnetwork. Provide this property when you create the subnetwork. For example, 10.0.0.0/8 or 192.168.0.0/16. Ranges must be unique and non-overlapping within a network. Only IPv4 is supported. This field can be set only at resource creation time.
-`name` | string | Name: The name of the resource, provided by the client when initially creating the resource. The name must be 1-63 characters long, and comply with RFC1035. Specifically, the name must be 1-63 characters long and match the regular expression `[a-z]([-a-z0-9]*[a-z0-9])?` which means the first character must be a lowercase letter, and all following characters must be a dash, lowercase letter, or digit, except the last character, which cannot be a dash.
-`network` | string | Network: The URL of the network to which this subnetwork belongs, provided by the client when initially creating the subnetwork. Only networks that are in the distributed mode can have subnetworks. This field can be set only at resource creation time.
-`privateIpGoogleAccess` | Optional bool | PrivateIPGoogleAccess: Whether the VMs in this subnet can access Google services without assigned external IP addresses. This field can be both set at resource creation time and updated using setPrivateIPGoogleAccess.
-`region` | Optional string | Region: URL of the region where the Subnetwork resides. This field can be set only at resource creation time.
-`secondaryIpRanges` | Optional [[]*github.com/crossplaneio/stack-gcp/gcp/apis/compute/v1alpha2.GCPSubnetworkSecondaryRange](#*github.com/crossplaneio/stack-gcp/gcp/apis/compute/v1alpha2.GCPSubnetworkSecondaryRange) | SecondaryIPRanges: An array of configurations for secondary IP ranges for VM instances contained in this subnetwork. The primary IP of such VM must belong to the primary ipCidrRange of the subnetwork. The alias IPs may belong to either primary or secondary ranges. This field can be updated with a patch request.
-
-
-
-## SubnetworkSpec
-
-A SubnetworkSpec defines the desired state of a Subnetwork.
-
-Appears in:
-
-* [Subnetwork](#Subnetwork)
-
-
-
-
-SubnetworkSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [SubnetworkParameters](#SubnetworkParameters)
-
-
-## SubnetworkStatus
-
-A SubnetworkStatus represents the observed state of a Subnetwork.
-
-Appears in:
-
-* [Subnetwork](#Subnetwork)
-
-
-
-
-SubnetworkStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [GCPSubnetworkStatus](#GCPSubnetworkStatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-gcp/database-gcp-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-gcp/database-gcp-crossplane-io-v1alpha2.md
deleted file mode 100644
index dc5149be..00000000
--- a/docs/v0.3/api/crossplaneio/stack-gcp/database-gcp-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,119 +0,0 @@
-# database.gcp.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for GCP database services such as CloudSQL.
-
-This API group contains the following Crossplane resources:
-
-* [CloudsqlInstance](#CloudsqlInstance)
-* [CloudsqlInstanceClass](#CloudsqlInstanceClass)
-
-## CloudsqlInstance
-
-A CloudsqlInstance is a managed resource that represents a Google CloudSQL instance.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.gcp.crossplane.io/v1alpha2`
-`kind` | string | `CloudsqlInstance`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [CloudsqlInstanceSpec](#CloudsqlInstanceSpec) | A CloudsqlInstanceSpec defines the desired state of a CloudsqlInstance.
-`status` | [CloudsqlInstanceStatus](#CloudsqlInstanceStatus) | A CloudsqlInstanceStatus represents the observed state of a CloudsqlInstance.
-
-
-
-## CloudsqlInstanceClass
-
-A CloudsqlInstanceClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.gcp.crossplane.io/v1alpha2`
-`kind` | string | `CloudsqlInstanceClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [CloudsqlInstanceClassSpecTemplate](#CloudsqlInstanceClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned CloudsqlInstance.
-
-
-
-## CloudsqlInstanceClassSpecTemplate
-
-A CloudsqlInstanceClassSpecTemplate is a template for the spec of a dynamically provisioned CloudsqlInstance.
-
-Appears in:
-
-* [CloudsqlInstanceClass](#CloudsqlInstanceClass)
-
-
-
-
-CloudsqlInstanceClassSpecTemplate supports all fields of:
-
-* [v1alpha1.NonPortableClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#nonportableclassspectemplate)
-* [CloudsqlInstanceParameters](#CloudsqlInstanceParameters)
-
-
-## CloudsqlInstanceParameters
-
-CloudsqlInstanceParameters define the desired state of a Google CloudSQL instance.
-
-Appears in:
-
-* [CloudsqlInstanceClassSpecTemplate](#CloudsqlInstanceClassSpecTemplate)
-* [CloudsqlInstanceSpec](#CloudsqlInstanceSpec)
-
-
-Name | Type | Description
------|------|------------
-`authorizedNetworks` | Optional []string | AuthorizedNetworks is the list of external networks that are allowed to connect to the instance using the IP. In CIDR notation, also known as 'slash' notation (e.g. 192.168.100.0/24).
-`privateNetwork` | Optional string | PrivateNetwork is the resource link for the VPC network from which the Cloud SQL instance is accessible for private IP. For example, /projects/myProject/global/networks/default. This setting can be updated, but it cannot be removed after it is set.
-`ipv4Enabled` | Optional bool | Ipv4Enabled specifies whether the instance should be assigned an IP address or not.
-`databaseVersion` | string | DatabaseVersion specifies he database engine type and version. MySQL Second Generation instances use MYSQL_5_7 (default) or MYSQL_5_6. MySQL First Generation instances use MYSQL_5_6 (default) or MYSQL_5_5 PostgreSQL instances uses POSTGRES_9_6 (default) or POSTGRES_11.
-`labels` | Optional map[string]string | Labels to apply to this CloudSQL instance.
-`region` | string | Region specifies the geographical region of this CloudSQL instance.
-`storageType` | string | StorageType specifies the type of the data disk, either PD_SSD or PD_HDD.
-`storageGB` | int64 | StorageGB specifies the size of the data disk. The minimum is 10GB.
-`tier` | string | Tier (or machine type) for this instance, for example db-n1-standard-1 (MySQL instances) or db-custom-1-3840 (PostgreSQL instances). For MySQL instances, this property determines whether the instance is First or Second Generation. For more information, see https://cloud.google.com/sql/docs/mysql/instance-settings
-`nameFormat` | string | NameFormat specifies the name of the extenral CloudSQL instance. The first instance of the string '%s' will be replaced with the Kubernetes UID of this CloudsqlInstance.
-
-
-
-## CloudsqlInstanceSpec
-
-A CloudsqlInstanceSpec defines the desired state of a CloudsqlInstance.
-
-Appears in:
-
-* [CloudsqlInstance](#CloudsqlInstance)
-
-
-
-
-CloudsqlInstanceSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [CloudsqlInstanceParameters](#CloudsqlInstanceParameters)
-
-
-## CloudsqlInstanceStatus
-
-A CloudsqlInstanceStatus represents the observed state of a CloudsqlInstance.
-
-Appears in:
-
-* [CloudsqlInstance](#CloudsqlInstance)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State of this CloudsqlInstance.
-`publicIp` | string | PublicIP is used to connect to this resource from other authorized networks.
-`privateIp` | string | PrivateIP is used to connect to this instance from the same Network.
-
-
-CloudsqlInstanceStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-gcp/gcp-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-gcp/gcp-crossplane-io-v1alpha2.md
deleted file mode 100644
index 35506ab7..00000000
--- a/docs/v0.3/api/crossplaneio/stack-gcp/gcp-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# gcp.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains the core resources of the Google Cloud Platform.
-
-This API group contains the following Crossplane resources:
-
-* [Provider](#Provider)
-
-## Provider
-
-A Provider configures a GCP 'provider', i.e. a connection to a particular GCP project using a particular GCP service account
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `gcp.crossplane.io/v1alpha2`
-`kind` | string | `Provider`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ProviderSpec](#ProviderSpec) | A ProviderSpec defines the desired state of a Provider.
-
-
-
-## ProviderSpec
-
-A ProviderSpec defines the desired state of a Provider.
-
-Appears in:
-
-* [Provider](#Provider)
-
-
-Name | Type | Description
------|------|------------
-`credentialsSecretRef` | [core/v1.SecretKeySelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#secretkeyselector-v1-core) | A Secret containing JSON encoded credentials for a Google Service Account that will be used to authenticate to this GCP Provider.
-`projectID` | string | ProjectID is the project name (not numerical ID) of this GCP Provider.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-gcp/servicenetworking-gcp-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-gcp/servicenetworking-gcp-crossplane-io-v1alpha2.md
deleted file mode 100644
index b9292a84..00000000
--- a/docs/v0.3/api/crossplaneio/stack-gcp/servicenetworking-gcp-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,78 +0,0 @@
-# servicenetworking.gcp.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for GCP service networking services such as connections.
-
-This API group contains the following Crossplane resources:
-
-* [Connection](#Connection)
-
-## Connection
-
-A Connection is a managed resource that represents a Google Cloud Service Networking Connection.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `servicenetworking.gcp.crossplane.io/v1alpha2`
-`kind` | string | `Connection`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ConnectionSpec](#ConnectionSpec) | A ConnectionSpec defines the desired state of a Connection.
-`status` | [ConnectionStatus](#ConnectionStatus) | A ConnectionStatus represents the observed state of a Connection.
-
-
-
-## ConnectionParameters
-
-ConnectionParameters define the desired state of a Google Cloud Service Networking Connection. Most fields map direct to a Connection: https://cloud.google.com/service-infrastructure/docs/service-networking/reference/rest/v1/services.connections#Connection
-
-Appears in:
-
-* [ConnectionSpec](#ConnectionSpec)
-
-
-Name | Type | Description
------|------|------------
-`parent` | string | Parent: The service that is managing peering connectivity for a service producer's organization. For Google services that support this functionality, this value is services/servicenetworking.googleapis.com.
-`network` | string | Network: The name of service consumer's VPC network that's connected with service producer network, in the following format: `projects/{project}/global/networks/{network}`. `{project}` is a project number, such as in `12345` that includes the VPC service consumer's VPC network. `{network}` is the name of the service consumer's VPC network.
-`reservedPeeringRanges` | Optional []string | ReservedPeeringRanges: The name of one or more allocated IP address ranges for this service producer of type `PEERING`.
-
-
-
-## ConnectionSpec
-
-A ConnectionSpec defines the desired state of a Connection.
-
-Appears in:
-
-* [Connection](#Connection)
-
-
-
-
-ConnectionSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [ConnectionParameters](#ConnectionParameters)
-
-
-## ConnectionStatus
-
-A ConnectionStatus represents the observed state of a Connection.
-
-Appears in:
-
-* [Connection](#Connection)
-
-
-Name | Type | Description
------|------|------------
-`peering` | string | Peering: The name of the VPC Network Peering connection that was created by the service producer.
-`service` | string | Service: The name of the peering service that's associated with this connection, in the following format: `services/{service name}`.
-
-
-ConnectionStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/api/crossplaneio/stack-gcp/storage-gcp-crossplane-io-v1alpha2.md b/docs/v0.3/api/crossplaneio/stack-gcp/storage-gcp-crossplane-io-v1alpha2.md
deleted file mode 100644
index 8f70b39b..00000000
--- a/docs/v0.3/api/crossplaneio/stack-gcp/storage-gcp-crossplane-io-v1alpha2.md
+++ /dev/null
@@ -1,395 +0,0 @@
-# storage.gcp.crossplane.io/v1alpha2 API Reference
-
-Package v1alpha2 contains managed resources for GCP storage services such as GCS buckets.
-
-This API group contains the following Crossplane resources:
-
-* [Bucket](#Bucket)
-* [BucketClass](#BucketClass)
-
-## Bucket
-
-A Bucket is a managed resource that represents a Google Cloud Storage bucket.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.gcp.crossplane.io/v1alpha2`
-`kind` | string | `Bucket`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [BucketSpec](#BucketSpec) | A BucketSpec defines the desired state of a Bucket.
-`status` | [BucketStatus](#BucketStatus) | A BucketStatus represents the observed state of a Bucket.
-
-
-
-## BucketClass
-
-A BucketClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.gcp.crossplane.io/v1alpha2`
-`kind` | string | `BucketClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [BucketClassSpecTemplate](#BucketClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned Bucket.
-
-
-
-## ACLRule
-
-ACLRule represents a grant for a role to an entity (user, group or team) for a Google Cloud Storage object or bucket.
-
-Appears in:
-
-* [BucketSpecAttrs](#BucketSpecAttrs)
-
-
-Name | Type | Description
------|------|------------
-`entity` | string |
-`entityId` | string |
-`role` | string |
-`domain` | string |
-`email` | string |
-`projectTeam` | [ProjectTeam](#ProjectTeam) |
-
-
-
-## BucketClassSpecTemplate
-
-A BucketClassSpecTemplate is a template for the spec of a dynamically provisioned Bucket.
-
-Appears in:
-
-* [BucketClass](#BucketClass)
-
-
-
-
-BucketClassSpecTemplate supports all fields of:
-
-* [v1alpha1.NonPortableClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#nonportableclassspectemplate)
-* [BucketParameters](#BucketParameters)
-
-
-## BucketEncryption
-
-BucketEncryption is a bucket's encryption configuration.
-
-Appears in:
-
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-Name | Type | Description
------|------|------------
-`defaultKmsKeyName` | string | A Cloud KMS key name, in the form projects/P/locations/L/keyRings/R/cryptoKeys/K, that will be used to encrypt objects inserted into this bucket, if no encryption method is specified. The key's location must be the same as the bucket's.
-
-
-
-## BucketLogging
-
-BucketLogging holds the bucket's logging configuration, which defines the destination bucket and optional name prefix for the current bucket's logs.
-
-Appears in:
-
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-Name | Type | Description
------|------|------------
-`logBucket` | string | The destination bucket where the current bucket's logs should be placed.
-`logObjectPrefix` | string | A prefix for log object names.
-
-
-
-## BucketOutputAttrs
-
-BucketOutputAttrs represent the subset of metadata for a Google Cloud Storage bucket limited to output (read-only) fields.
-
-Appears in:
-
-* [BucketStatus](#BucketStatus)
-
-
-Name | Type | Description
------|------|------------
-`bucketPolicyOnly` | [BucketPolicyOnly](#BucketPolicyOnly) | BucketPolicyOnly configures access checks to use only bucket-level IAM policies.
-`created` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | Created is the creation time of the bucket.
-`name` | string | Name is the name of the bucket.
-`retentionPolicy` | [RetentionPolicyStatus](#RetentionPolicyStatus) | Retention policy enforces a minimum retention time for all objects contained in the bucket. A RetentionPolicy of nil implies the bucket has no minimum data retention. This feature is in private alpha release. It is not currently available to most customers. It might be changed in backwards-incompatible ways and is not subject to any SLA or deprecation policy.
-
-
-
-## BucketParameters
-
-BucketParameters define the desired state of a Google Cloud Storage Bucket. Most fields map directly to a bucket resource: https://cloud.google.com/storage/docs/json_api/v1/buckets#resource
-
-Appears in:
-
-* [BucketClassSpecTemplate](#BucketClassSpecTemplate)
-* [BucketSpec](#BucketSpec)
-
-
-Name | Type | Description
------|------|------------
-`nameFormat` | string | NameFormat specifies the name of the external Bucket. The first instance of the string '%s' will be replaced with the Kubernetes UID of this Bucket.
-`serviceAccountSecretRef` | [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core) | ServiceAccountSecretRef contains GCP ServiceAccount secret that will be used for bucket connection secret credentials
-
-
-BucketParameters supports all fields of:
-
-* [BucketSpecAttrs](#BucketSpecAttrs)
-
-
-## BucketPolicyOnly
-
-BucketPolicyOnly configures access checks to use only bucket-level IAM policies.
-
-Appears in:
-
-* [BucketOutputAttrs](#BucketOutputAttrs)
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-Name | Type | Description
------|------|------------
-`enabled` | bool | Enabled specifies whether access checks use only bucket-level IAM policies. Enabled may be disabled until the locked time.
-`lockedTime` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | LockedTime specifies the deadline for changing Enabled from true to false.
-
-
-
-## BucketSpec
-
-A BucketSpec defines the desired state of a Bucket.
-
-Appears in:
-
-* [Bucket](#Bucket)
-
-
-
-
-BucketSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [BucketParameters](#BucketParameters)
-
-
-## BucketSpecAttrs
-
-BucketSpecAttrs represents the full set of metadata for a Google Cloud Storage bucket limited to all input attributes
-
-Appears in:
-
-* [BucketParameters](#BucketParameters)
-
-
-Name | Type | Description
------|------|------------
-`acl` | [[]ACLRule](#ACLRule) | ACL is the list of access control rules on the bucket.
-`defaultObjectAcl` | [[]ACLRule](#ACLRule) | DefaultObjectACL is the list of access controls to apply to new objects when no object ACL is provided.
-`location` | string | Location is the location of the bucket. It defaults to "US".
-`storageClass` | string | StorageClass is the default storage class of the bucket. This defines how objects in the bucket are stored and determines the SLA and the cost of storage. Typical values are "MULTI_REGIONAL", "REGIONAL", "NEARLINE", "COLDLINE", "STANDARD" and "DURABLE_REDUCED_AVAILABILITY". Defaults to "STANDARD", which is equivalent to "MULTI_REGIONAL" or "REGIONAL" depending on the bucket's location settings.
-
-
-BucketSpecAttrs supports all fields of:
-
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-## BucketStatus
-
-A BucketStatus represents the observed state of a Bucket.
-
-Appears in:
-
-* [Bucket](#Bucket)
-
-
-Name | Type | Description
------|------|------------
-`attributes` | [BucketOutputAttrs](#BucketOutputAttrs) | BucketOutputAttrs represent the subset of metadata for a Google Cloud Storage bucket limited to output (read-only) fields.
-
-
-BucketStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## BucketUpdatableAttrs
-
-BucketUpdatableAttrs represents the subset of parameters of a Google Cloud Storage bucket that may be updated.
-
-Appears in:
-
-* [BucketSpecAttrs](#BucketSpecAttrs)
-
-
-Name | Type | Description
------|------|------------
-`bucketPolicyOnly` | [BucketPolicyOnly](#BucketPolicyOnly) | BucketPolicyOnly configures access checks to use only bucket-level IAM policies.
-`cors` | [[]CORS](#CORS) | The bucket's Cross-Origin Resource Sharing (CORS) configuration.
-`defaultEventBasedHold` | bool | DefaultEventBasedHold is the default value for event-based hold on newly created objects in this bucket. It defaults to false.
-`encryption` | [BucketEncryption](#BucketEncryption) | The encryption configuration used by default for newly inserted objects.
-`labels` | map[string]string | Labels are the bucket's labels.
-`lifecycle` | [Lifecycle](#Lifecycle) | Lifecycle is the lifecycle configuration for objects in the bucket.
-`logging` | [BucketLogging](#BucketLogging) | The logging configuration.
-`predefinedAcl` | string | If not empty, applies a predefined set of access controls. It should be set only when creating a bucket. It is always empty for BucketAttrs returned from the service. See https://cloud.google.com/storage/docs/json_api/v1/buckets/insert for valid values.
-`predefinedCefaultObjectAcl` | string | If not empty, applies a predefined set of default object access controls. It should be set only when creating a bucket. It is always empty for BucketAttrs returned from the service. See https://cloud.google.com/storage/docs/json_api/v1/buckets/insert for valid values.
-`requesterPays` | bool | RequesterPays reports whether the bucket is a Requester Pays bucket. Clients performing operations on Requester Pays buckets must provide a user project (see BucketHandle.UserProject), which will be billed for the operations.
-`retentionPolicy` | [RetentionPolicy](#RetentionPolicy) | Retention policy enforces a minimum retention time for all objects contained in the bucket. A RetentionPolicy of nil implies the bucket has no minimum data retention. This feature is in private alpha release. It is not currently available to most customers. It might be changed in backwards-incompatible ways and is not subject to any SLA or deprecation policy.
-`versioningEnabled` | bool | VersioningEnabled reports whether this bucket has versioning enabled.
-`website` | [BucketWebsite](#BucketWebsite) | The website configuration.
-
-
-
-## BucketWebsite
-
-BucketWebsite holds the bucket's website configuration, controlling how the service behaves when accessing bucket contents as a web site. See https://cloud.google.com/storage/docs/static-website for more information.
-
-Appears in:
-
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-Name | Type | Description
------|------|------------
-`mainPageSuffix` | string | If the requested object path is missing, the service will ensure the path has a trailing '/', append this suffix, and attempt to retrieve the resulting object. This allows the creation of index.html objects to represent directory pages.
-`notFundPage` | string | If the requested object path is missing, and any mainPageSuffix object is missing, if applicable, the service will return the named object from this bucket as the content for a 404 Not Found result.
-
-
-
-## CORS
-
-CORS is the bucket's Cross-Origin Resource Sharing (CORS) configuration.
-
-Appears in:
-
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-Name | Type | Description
------|------|------------
-`maxAge` | [meta/v1.Duration](https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration) | MaxAge is the value to return in the Access-Control-Max-Age header used in preflight responses.
-`methods` | []string | Methods is the list of HTTP methods on which to include CORS response headers, (GET, OPTIONS, POST, etc) Note: "*" is permitted in the list of methods, and means "any method".
-`origins` | []string | Origins is the list of Origins eligible to receive CORS response headers. Note: "*" is permitted in the list of origins, and means "any Origin".
-`responseHeaders` | []string | ResponseHeaders is the list of HTTP headers other than the simple response headers to give permission for the user-agent to share across domains.
-
-
-
-## Lifecycle
-
-Lifecycle is the lifecycle configuration for objects in the bucket.
-
-Appears in:
-
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-Name | Type | Description
------|------|------------
-`rules` | [[]LifecycleRule](#LifecycleRule) |
-
-
-
-## LifecycleAction
-
-LifecycleAction is a lifecycle configuration action.
-
-Appears in:
-
-* [LifecycleRule](#LifecycleRule)
-
-
-Name | Type | Description
------|------|------------
-`storageClass` | string | StorageClass is the storage class to set on matching objects if the Action is "SetStorageClass".
-`type` | string | Type is the type of action to take on matching objects. Acceptable values are "Delete" to delete matching objects and "SetStorageClass" to set the storage class defined in StorageClass on matching objects.
-
-
-
-## LifecycleCondition
-
-LifecycleCondition is a set of conditions used to match objects and take an action automatically. All configured conditions must be met for the associated action to be taken.
-
-Appears in:
-
-* [LifecycleRule](#LifecycleRule)
-
-
-Name | Type | Description
------|------|------------
-`ageInDays` | int64 | AgeInDays is the age of the object in days.
-`createdBefore` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | CreatedBefore is the time the object was created. This condition is satisfied when an object is created before midnight of the specified date in UTC.
-`liveness` | [storage.Liveness](https://godoc.org/cloud.google.com/go/storage#Liveness) | Liveness specifies the object's liveness. Relevant only for versioned objects
-`matchesStorageClasses` | []string | MatchesStorageClasses is the condition matching the object's storage class. Values include "MULTI_REGIONAL", "REGIONAL", "NEARLINE", "COLDLINE", "STANDARD", and "DURABLE_REDUCED_AVAILABILITY".
-`numNewerVersions` | int64 | NumNewerVersions is the condition matching objects with a number of newer versions. If the value is N, this condition is satisfied when there are at least N versions (including the live version) newer than this version of the object.
-
-
-
-## LifecycleRule
-
-LifecycleRule is a lifecycle configuration rule. When all the configured conditions are met by an object in the bucket, the configured action will automatically be taken on that object.
-
-Appears in:
-
-* [Lifecycle](#Lifecycle)
-
-
-Name | Type | Description
------|------|------------
-`action` | [LifecycleAction](#LifecycleAction) | Action is the action to take when all of the associated conditions are met.
-`condition` | [LifecycleCondition](#LifecycleCondition) | Condition is the set of conditions that must be met for the associated action to be taken.
-
-
-
-## ProjectTeam
-
-ProjectTeam is the project team associated with the entity, if any.
-
-Appears in:
-
-* [ACLRule](#ACLRule)
-
-
-Name | Type | Description
------|------|------------
-`projectNumber` | string |
-`team` | string |
-
-
-
-## RetentionPolicy
-
-RetentionPolicy enforces a minimum retention time for all objects contained in the bucket. Any attempt to overwrite or delete objects younger than the retention period will result in an error. An unlocked retention policy can be modified or removed from the bucket via the Update method. A locked retention policy cannot be removed or shortened in duration for the lifetime of the bucket. This feature is in private alpha release. It is not currently available to most customers. It might be changed in backwards-incompatible ways and is not subject to any SLA or deprecation policy.
-
-Appears in:
-
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-Name | Type | Description
------|------|------------
-`retentionPeriodSeconds` | int | RetentionPeriod specifies the duration value in seconds that objects need to be retained. Retention duration must be greater than zero and less than 100 years. Note that enforcement of retention periods less than a day is not guaranteed. Such periods should only be used for testing purposes.
-
-
-
-## RetentionPolicyStatus
-
-RetentionPolicyStatus output component of storage.RetentionPolicy
-
-Appears in:
-
-* [BucketOutputAttrs](#BucketOutputAttrs)
-
-
-Name | Type | Description
------|------|------------
-`effectiveTime` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | EffectiveTime is the time from which the policy was enforced and effective.
-`isLocked` | bool | IsLocked describes whether the bucket is locked. Once locked, an object retention policy cannot be modified.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.3/cloud-providers.md b/docs/v0.3/cloud-providers.md
deleted file mode 100644
index 56a8f6cb..00000000
--- a/docs/v0.3/cloud-providers.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: Connect Your Cloud Providers
-toc: true
-weight: 230
-indent: true
----
-
-# Connect Your Cloud Provider
-
-In order for Crossplane to be able to manage resources across all your clouds, you will need to add your cloud provider account credentials to Crossplane.
-Use the links below for specific instructions to add each of the following cloud providers:
-
-* [Google Cloud Platform (GCP)](cloud-providers/gcp/gcp-provider.md)
- * Required for Quick Start
-* [Microsoft Azure](cloud-providers/azure/azure-provider.md)
-* [Amazon Web Services (AWS)](cloud-providers/aws/aws-provider.md)
-
-## Examining Cloud Provider Configuration
-
-When Crossplane is installed, you can list all of the available providers.
-
-```console
-$ kubectl api-resources | grep providers.*crossplane | awk '{print $2}'
-aws.crossplane.io
-azure.crossplane.io
-gcp.crossplane.io
-```
-
-After credentials have put in place for some of the Cloud providers, you can list those configurations.
-
-```console
-$ kubectl -n crossplane-system get providers.gcp.crossplane.io
-NAME PROJECT-ID AGE
-gcp-provider crossplane-example-10412 22h
-
-$ kubectl -n crossplane-system get providers.aws.crossplane.io
-NAME REGION AGE
-aws-provider eu-west-1 22h
-
-$ kubectl -n crossplane-system get providers.azure.crossplane.io
-NAME AGE
-azure-provider 22h
-```
diff --git a/docs/v0.3/cloud-providers/aws/aws-provider.md b/docs/v0.3/cloud-providers/aws/aws-provider.md
deleted file mode 100644
index 4f023b50..00000000
--- a/docs/v0.3/cloud-providers/aws/aws-provider.md
+++ /dev/null
@@ -1,45 +0,0 @@
-
-# Adding Amazon Web Services (AWS) to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your AWS account to be ready for integration with Crossplane. This will be done by adding a [`aw provider`] resource type, which enables Crossplane to communicate with an AWS account.
-
-## Requirements
-
-Prior to adding AWS to Crossplane, following steps need to be taken
-
-- Crossplane is installed in a k8s cluster
-- AWS Stack is installed in the same cluster
-- `kubectl` is configured to communicate with the same cluster
-
-## Step 1: Configure `aws` CLI
-
-Crossplane uses [AWS security credentials], and stores them as a [secret] which is managed by an [`aw provider`] instance. In addition, the AWS default region is also used for targeting a specific region.
-Crossplane requires to have [`aws` command line tool] [installed] and [configured]. Once installed, the credentials and configuration will reside in `~/.aws/credentials` and `~/.aws/config` respectively.
-
-## Step 2: Setup `aws` Provider
-
-Run [setup.sh] script to read `aws` credentials and region, and create an [`aw provider`] instance in Crossplane:
-
-```bash
-./cluster/examples/setup-aws-provider/setup.sh [--profile aws_profile]
-```
-
-The `--profile` switch is optional and specifies the [aws named profile] that was set in Step 1. If not provided, the `default` profile will be selected.
-
-Once the script is successfully executed, Crossplane will use the specified aws account and region in the given named profile to create subsequent AWS managed resources.
-
-You can confirm the existense of the [`aw provider`] by running:
-
-```bash
-kubectl -n crossplane-system get provider/aws-provider
-```
-
-[`aw provider`]: https://github.com/crossplaneio/stack-aws/blob/master/aws/apis/v1alpha2/types.go#L43
- [`aws` command line tool]: https://aws.amazon.com/cli/
-[AWS SDK for GO]: https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/setting-up.html
-[installed]: [https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)
-[configured]: [https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)
-[AWS security credentials]: https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html
-[secret]:https://kubernetes.io/docs/concepts/configuration/secret/
-[setup.sh]: github.com/crossplaneio/crossplane/cluster/examples/setup-aws-provider/setup.sh
-[aws named profile]: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html
diff --git a/docs/v0.3/cloud-providers/azure/azure-provider.md b/docs/v0.3/cloud-providers/azure/azure-provider.md
deleted file mode 100644
index 24dc425e..00000000
--- a/docs/v0.3/cloud-providers/azure/azure-provider.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# Adding Microsoft Azure to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your Azure account to be ready for integration with Crossplane.
-The general steps we will take are summarized below:
-
-* Create a new service principal (account) that Crossplane will use to create and manage Azure resources
-* Add the required permissions to the account
-* Consent to the permissions using an administrator account
-
-## Preparing your Microsoft Azure Account
-
-In order to manage resources in Azure, you must provide credentials for a Azure service principal that Crossplane can use to authenticate.
-This assumes that you have already [set up the Azure CLI client](https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli?view=azure-cli-latest) with your credentials.
-
-Create a JSON file that contains all the information needed to connect and authenticate to Azure:
-
-```console
-# create service principal with Owner role
-az ad sp create-for-rbac --sdk-auth --role Owner > crossplane-azure-provider-key.json
-```
-
-Take note of the `clientID` value from the JSON file that we just created, and save it to an environment variable:
-
-```console
-export AZURE_CLIENT_ID=
-```
-
-Now add the required permissions to the service principal that will allow it to manage the necessary resources in Azure:
-
-```console
-# add required Azure Active Directory permissions
-az ad app permission add --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --api-permissions 1cda74f2-2616-4834-b122-5cb1b07f8a59=Role 78c8a3c8-a07e-4b9e-af1b-b5ccab50a175=Role
-
-# grant (activate) the permissions
-az ad app permission grant --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --expires never
-```
-
-You might see an error similar to the following, but that is OK, the permissions should have gone through still:
-
-```console
-Operation failed with status: 'Conflict'. Details: 409 Client Error: Conflict for url: https://graph.windows.net/e7985bc4-a3b3-4f37-b9d2-fa256023b1ae/oauth2PermissionGrants?api-version=1.6
-```
-
-After these steps are completed, you should have the following file on your local filesystem:
-
-* `crossplane-azure-provider-key.json`
-
-## Grant Consent to Application Permissions
-
-One more step is required to fully grant the permissions to the new service principal.
-From the Azure Portal, you need to grant consent for the permissions using an admin account.
-The steps to perform this action are listed below:
-
-1. `echo ${AZURE_CLIENT_ID}` and note this ID value
-1. Navigate to the Azure Portal: https://portal.azure.com
-1. Click `Azure Active Directory`, or find it in the `All services` list
-1. Click `App registrations (Preview)`
-1. Click on the application from the list where the application (client) ID matches the value from step 1
-1. Click `API permissions`
-1. Click `Grant admin consent for Default Directory`
-1. Click `Yes`
diff --git a/docs/v0.3/cloud-providers/gcp/gcp-provider.md b/docs/v0.3/cloud-providers/gcp/gcp-provider.md
deleted file mode 100644
index 67b92560..00000000
--- a/docs/v0.3/cloud-providers/gcp/gcp-provider.md
+++ /dev/null
@@ -1,142 +0,0 @@
-# Adding Google Cloud Platform (GCP) to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your GCP account to be ready for integration with Crossplane.
-The general steps we will take are summarized below:
-
-* Create a new example project that all resources will be deployed to
-* Enable required APIs such as Kubernetes and CloudSQL
-* Create a service account that will be used to perform GCP operations from Crossplane
-* Assign necessary roles to the service account
-* Enable billing
-
-For your convenience, the specific steps to accomplish those tasks are provided for you below using either the `gcloud` command line tool, or the GCP console in a web browser.
-You can choose whichever you are more comfortable with.
-
-## Option 1: gcloud Command Line Tool
-
-If you have the `gcloud` tool installed, you can run the commands below from the crossplane directory.
-
-Instructions for installing `gcloud` can be found in the [Google docs](https://cloud.google.com/sdk/install).
-
-### Using `gcp-credentials.sh`
-
-In the `cluster/examples` directory you will find a helper script, `gcp-credentials.sh`. This script will prompt you for the organization, project, and billing account that will be used by `gcloud` when creating a project, service account, and credentials file (`crossplane-gcp-provider-key.json`). The chosen project and created service account will have access to the services and roles sufficient to run the Crossplane GCP examples.
-
-```console
-$ cluster/examples/gcp-credentials.sh
-... EXAMPLE OUTPUT ONLY
-export ORGANIZATION_ID=987654321
-export PROJECT_ID=crossplane-example-1234
-export EXAMPLE_SA=example-1234@crossplane-example-1234.iam.gserviceaccount.com
-export BASE64ENCODED_GCP_PROVIDER_CREDS=$(base64 crossplane-gcp-provider-key.json | tr -d "\n")
-```
-
-After running `gcp-credentials.sh`, a series of `export` commands will be shown. Copy and paste the `export` commands that are provided. These variable names will be referenced throughout the Crossplane examples, generally with a `sed` command.
-
-You will also find a `crossplane-gcp-provider-key.json` file in the current working directory. Be sure to remove this file when you are done with the example projects.
-
-### Running `gcloud` by hand
-
-```bash
-# list your organizations (if applicable), take note of the specific organization ID you want to use
-# if you have more than one organization (not common)
-gcloud organizations list
-
-# create a new project (project id must be <=30 characters)
-export EXAMPLE_PROJECT_ID=crossplane-example-123
-gcloud projects create $EXAMPLE_PROJECT_ID --enable-cloud-apis # [--organization $ORGANIZATION_ID]
-
-# or, record the PROJECT_ID value of an existing project
-# export EXAMPLE_PROJECT_ID=$(gcloud projects list --filter NAME=$EXAMPLE_PROJECT_NAME --format="value(PROJECT_ID)")
-
-# link billing to the new project
-gcloud beta billing accounts list
-gcloud beta billing projects link $EXAMPLE_PROJECT_ID --billing-account=$ACCOUNT_ID
-
-# enable Kubernetes API
-gcloud --project $EXAMPLE_PROJECT_ID services enable container.googleapis.com
-
-# enable CloudSQL API
-gcloud --project $EXAMPLE_PROJECT_ID services enable sqladmin.googleapis.com
-
-# enable Redis API
-gcloud --project $EXAMPLE_PROJECT_ID services enable redis.googleapis.com
-
-# enable Compute API
-gcloud --project $EXAMPLE_PROJECT_ID services enable compute.googleapis.com
-
-# enable Additional APIs needed for the example or project
-# See `gcloud services list` for a complete list
-
-# create service account
-gcloud --project $EXAMPLE_PROJECT_ID iam service-accounts create example-123 --display-name "Crossplane Example"
-
-# export service account email
-export EXAMPLE_SA="example-123@$EXAMPLE_PROJECT_ID.iam.gserviceaccount.com"
-
-# create service account key (this will create a `crossplane-gcp-provider-key.json` file in your current working directory)
-gcloud --project $EXAMPLE_PROJECT_ID iam service-accounts keys create --iam-account $EXAMPLE_SA crossplane-gcp-provider-key.json
-
-# assign roles
-gcloud projects add-iam-policy-binding $EXAMPLE_PROJECT_ID --member "serviceAccount:$EXAMPLE_SA" --role="roles/iam.serviceAccountUser"
-gcloud projects add-iam-policy-binding $EXAMPLE_PROJECT_ID --member "serviceAccount:$EXAMPLE_SA" --role="roles/cloudsql.admin"
-gcloud projects add-iam-policy-binding $EXAMPLE_PROJECT_ID --member "serviceAccount:$EXAMPLE_SA" --role="roles/container.admin"
-gcloud projects add-iam-policy-binding $EXAMPLE_PROJECT_ID --member "serviceAccount:$EXAMPLE_SA" --role="roles/redis.admin"
-gcloud projects add-iam-policy-binding $EXAMPLE_PROJECT_ID --member "serviceAccount:$EXAMPLE_SA" --role="roles/compute.networkAdmin"
-```
-
-## Option 2: GCP Console in a Web Browser
-
-If you chose to use the `gcloud` tool, you can skip this section entirely.
-
-Create a GCP example project which we will use to host our example GKE cluster, as well as our example CloudSQL instance.
-
-- Login into [GCP Console](https://console.cloud.google.com)
-- Create a [new project](https://console.cloud.google.com/flows/enableapi?apiid=container.googleapis.com,sqladmin.googleapis.com,redis.googleapis.com) (either stand alone or under existing organization)
-- Create Example Service Account
- - Navigate to: [Create Service Account](https://console.cloud.google.com/iam-admin/serviceaccounts)
- - `Service Account Name`: type "example"
- - `Service Account ID`: leave auto assigned
- - `Service Account Description`: type "Crossplane example"
- - Click `Create` button
- - This should advance to the next section `2 Grant this service account to project (optional)`
- - We will assign this account 3 roles:
- - `Service Account User`
- - `Cloud SQL Admin`
- - `Kubernetes Engine Admin`
- - `Compute Network Admin`
- - Click `Create` button
- - This should advance to the next section `3 Grant users access to this service account (optional)`
- - We don't need to assign any user or admin roles to this account for the example purposes, so you can leave following two fields blank:
- - `Service account users role`
- - `Service account admins role`
- - Next, we will create and export service account key
- - Click `+ Create Key` button.
- - This should open a `Create Key` side panel
- - Select `json` for the Key type (should be selected by default)
- - Click `Create`
- - This should show `Private key saved to your computer` confirmation dialog
- - You also should see `crossplane-example-1234-[suffix].json` file in your browser's Download directory
- - Save (copy or move) this file into example (this) directory, with new name `crossplane-gcp-provider-key.json`
-- Enable `Cloud SQL API`
- - Navigate to [Cloud SQL Admin API](https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview)
- - Click `Enable`
-- Enable `Kubernetes Engine API`
- - Navigate to [Kubernetes Engine API](https://console.developers.google.com/apis/api/container.googleapis.com/overview)
- - Click `Enable`
-- Enable `Cloud Memorystore for Redis`
- - Navigate to [Cloud Memorystore for Redis](https://console.developers.google.com/apis/api/redis.googleapis.com/overview)
- - Click `Enable`
-- Enable `Compute Engine API`
- - Navigate to [Compute Engine API](https://console.developers.google.com/apis/api/compute.googleapis.com/overview)
- - Click `Enable`
-
-### Enable Billing
-
-You will need to enable billing for your account in order to create and use Kubernetes clusters with GKE.
-
-- Go to [GCP Console](https://console.cloud.google.com)
- - Select example project
- - Click `Enable Billing`
-- Go to [Kubernetes Clusters](https://console.cloud.google.com/kubernetes/list)
- - Click `Enable Billing`
diff --git a/docs/v0.3/concepts.md b/docs/v0.3/concepts.md
deleted file mode 100644
index 333dc6bf..00000000
--- a/docs/v0.3/concepts.md
+++ /dev/null
@@ -1,374 +0,0 @@
----
-title: Concepts
-toc: true
-weight: 310
----
-# Table of Contents
-1. [Concepts](#concepts)
-2. [Feature Areas](#feature-areas)
-3. [Glossary](#glossary)
-
-# Concepts
-## Control Plane
-Crossplane is an open source multicloud control plane that consists of smart controllers that can work across clouds to enable workload portability, provisioning and full-lifecycle management of infrastructure across a wide range of providers, vendors, regions, and offerings.
-The control plane presents a declarative management style API that covers a wide range of portable abstractions that facilitate these goals across disparate environments, clusters, regions, and clouds.
-Crossplane can be thought of as a higher-order orchestrator across cloud providers.
-For convenience, Crossplane can run directly on-top of an existing Kubernetes cluster without requiring any changes, even though Crossplane does not necessarily schedule or run any containers on the host cluster.
-
-## Resources and Workloads
-In Crossplane, a *resource* represents an external piece of infrastructure ranging from low level services like clusters and servers, to higher level infrastructure like databases, message queues, buckets, and more.
-Resources are represented as persistent object within the crossplane, and they typically manage one or more pieces of external infrastructure within a cloud provider or cloud offering.
-Resources can also represent local or in-cluster services.
-
-We model *workloads* as schedulable units of work that the user intends to run on a cloud provider.
-Crossplane will support multiple types of workloads including container and serverless.
-You can think of workloads as units that run **your** code and applications.
-Every type of workload has a different kind of payload.
-For example, a container workload can include a set of objects that will be deployed on a managed Kubernetes cluster, or a reference to helm chart, etc.
-A serverless workload could include a function that will run on a serverless managed service.
-Workloads can contain requirements for where and how the workload can run, including regions, providers, affinity, cost, and others that the scheduler can use when assigning the workload.
-
-## Resource Claims and Resource Classes
-To support workload portability we expose the concept of a resource claim and a resource class.
-A resource claim is a persistent object that captures the desired configuration of a resource from the perspective of a workload or application.
-Its configuration is cloud-provider and cloud-offering independent and it’s free of implementation and/or environmental details.
-A resource claim can be thought of as a request for an actual resource and is typically created by a developer or application owner.
-
-A resource class is configuration that contains implementation details specific to a certain environment or deployment, and policies related to a kind of resource.
-A ResourceClass acts as a template with implementation details and policy for resources that will be dynamically provisioned by the workload at deployment time.
-A resource class is typically created by an admin or infrastructure owner.
-
-## Dynamic and Static Provisioning
-
-A resource can be statically or dynamically provisioned.
-Static provisioning is when an administrator creates the resource manually.
-They set the configuration required to provision and manage the corresponding external resource within a cloud provider or cloud offering.
-Once provisioned, resources are available to be bound to resource claims.
-
-Dynamic provisioning is when an resource claim does not find a matching resource and provisions a new one instead.
-The newly provisioned resource is automatically bound to the resource claim.
-To enable dynamic provisioning the administrator needs to create one or more resource class objects.
-
-## Connection Secrets
-Workloads reference all the resources they consume in their `resources` section.
-This helps Crossplane setup connectivity between the workload and resource, and create objects that hold connection information.
-For example, for a database provisioned and managed by Crossplane, a secret will be created that contains a connection string, user and password.
-This secret will be propagated to the target cluster so that it can be used by the workload.
-
-## Secure Connectivity
-To provide secure network connectivity between application deployments in a target cluster
-and the managed services they are using, Crossplane supports
-provisioning and life-cycle management of networks, subnets, peering, and firewall rules to
-provide secure connectivity.
-
-## Stacks
-Stacks extend Crossplane with new functionality. Crossplane provides Stacks for GCP, AWS,
-and Azure that are installed with a Stack Manager that can download packages,
-resolve dependencies, and execute controllers.
-Stacks are designed for simplified RBAC configuration and namespace
-isolation for improved security in multi-team environments. Stacks are published to a registry
-where they can be downloaded, explored, and organized.
-
-Stacks enable the community to add support for more clouds providers and and managed services. Stacks support
-out-of-tree extensibility so they can be released on their own schedule. A CLI can init,
-build, publish, install, and uninstall Stacks from developer laptops or
-in continuous delivery pipelines.
-
-Stacks for GCP, AWS, and Azure support provisioning managed services (database, cache, buckets),
-managed clusters (GKE, EKS, AKS), and secure connectivity (networks, subnets, firewall rules).
-Stacks for independent cloud offerings can be installed alongside the Stacks for GCP, AWS, and Azure
-to customize Crossplane with the right mix of managed services for your organization.
-
-# Feature Areas
-Crossplane has four main feature areas: Services, Stacks, Clusters and Workloads.
-
-## Crossplane Services
-Crossplane supports provisioning managed services using `kubectl`. It applies
-the Kubernetes pattern for Persistent Volume (PV)
-claims and classes to managed service provisioning with support for a strong
-separation of concern between app teams and cluster administrators.
-
-App teams can choose between cloud-specific and portable services including
-managed databases, message queues, buckets, data pipelines, and more to define
-complete applications, build once, and deploy into multiple clouds using
-continuous delivery pipelines or GitOps flows.
-
-Cluster administrators can define self-service policies and best-practice
-configurations to accelerate app delivery and improve security, so app teams can
-focus on delivering their app instead of cloud-specific infrastructure details.
-
-Secure connectivity between managed services and managed Kubernetes clusters is also supported
-in Crossplane such that private networking can be established declaratively using
-`kubectl`.
-
-Crossplane is designed to support the following types of managed services.
-
-### Managed Kubernetes Services
-Managed Kubernetes currently supported for GKE, EKS, AKS.
-
-Kubernetes clusters are another type of resource that can be dynamically provisioned using a
-generic resource claim by the application developer and an environment specific resource
-class by the cluster administrator.
-
-Future support for additional managed services.
-
-### Database Services
-Support for PostgreSQL, MySQL, and Redis.
-
-Database managed services can be statically or dynamically provisioned by Crossplane in AWS, GCP, and Azure.
-An application developer simply has to specify their general need for a database such as MySQL,
-without any specific knowledge of what environment that database will run in or even what
-specific type of database it will be at runtime.
-
-The cluster administrator specifies a resource class that acts as a template with the
-implementation details and policy specific to the environment that the generic MySQL resource is being deployed to.
-This enables the database to be dynamically provisioned at deployment time without the
-application developer needing to know any of the details, which promotes portability and reusability.
-
-Future support for additional managed services.
-
-### Storage Services
-Support for S3, Buckets, and Azure Blob storage.
-
-Future support for additional managed services.
-
-### Networking Services
-Support for networks, subnets, and firewall rules.
-
-Future support for additional managed services.
-
-### Load Balancing Services
-Future support.
-
-### Cloud DNS Services
-Future support.
-
-### Advanced Networking Connectivity Services
-Future support.
-
-### Big Data Services
-Future support.
-
-### Machine Learning Services
-Future support.
-
-## Crossplane Stacks
-Stacks extend Crossplane with new functionality.
-
-See [Stacks](#stacks).
-
-## Crossplane Workloads
-Crossplane includes an extensible workload scheduler that observes application
-policies to select a suitable target cluster from a pool of available clusters.
-The workload scheduler can be customized to consider a number of criteria including
-capabilities, availability, reliability, cost, regions, and performance while
-deploying workloads and their resources. Complex workloads can be modeled as a `KubernetesApplication`.
-
-## Crossplane Clusters
-Crossplane supports dynamic provisioning of managed
-Kubernetes clusters from a single control plane with consistent multi-cluster
-best-practice configuration and secure connectivity between target Kubernetes
-clusters and the managed services provisioned for applications. Managed
-Kubernetes clusters can be dynamically provisioned with a `KubernetesCluster`.
-
-# Glossary
-
-## Kubernetes
-Crossplane is built on the Kubernetes API machinery as a platform for declarative management.
-We rely on common terminology from the [Kubernetes Glossary][kubernetes-glossary] where possible,
-and we don't seek to reproduce that glossary here.
-
-[kubernetes-glossary]: https://kubernetes.io/docs/reference/glossary/?all=true
-However we'll summarize some commonly used concepts for convenience.
-
-### CRD
-A standard Kubernetes Custom Resource Definition (CRD), which defines a new type of resource that can be managed declaratively.
-This serves as the unit of management in Crossplane.
-The CRD is composed of spec and status sections and supports API level versioning (e.g., v1alpha1)
-
-### Controller
-A standard Kubernetes Custom Controller, providing active control loops that own one or more CRDs.
-Can be implemented in different ways, such as
-golang code (controller-runtime), templates, functions/hooks, templates, a new DSL, etc.
-The implementation itself is versioned using semantic versioning (e.g., v1.0.4)
-
-### Namespace
-Allows logical grouping of resources in Kubernetes that can be secured with RBAC rules.
-
-## Crossplane
-
-### Stack
-The unit of extending Crossplane with new functionality. A stack is a Controller that
-owns one or more CRDs and depends on zero or more CRDs.
-
-See [Stacks](#stacks).
-
-### Stack Registry
-A registry where Stacks can be published, downloaded, explored, and categorized.
-The registry understands a Stack’s custom controller and its CRDs and indexes by both -- you could lookup a custom controller by the CRD name and vice versa.
-
-### Stack Package Format
-The package format for Stacks that contains the Stack definition, metadata, icons, CRDs, and other Stack specific files.
-
-### Stack Manager
-The component that is responsible for installing a Stack’s custom controllers and resources in Crossplane.
-It can download packages, resolve dependencies, install resources and execute controllers.
-This component is also responsible for managing the complete life-cycle of Stacks, including upgrading them as new versions become available.
-
-### Application Stack
-App Stacks simplify operations for an app by moving app lifecycle management into a Kubernetes controller
-that owns an app CRD with a handful of settings required to deploy a new app instance,
-complete with the managed services it depends on.
-
-Application Stacks depend on Infrastructure Stacks like stack-gcp, stack-aws,
-and stack-azure to provide managed services via the Kubernetes API.
-
-### Infrastructure Stack
-Infrastructure Stacks like stack-gcp, stack-aws, and stack-azure extend Crossplane
-to support managed service provisioning (DBaaS, cache, buckets), secure connectivity
-(VPCs, subnets, peering, ACLs, secrets), and provisioning managed Kubernetes clusters
-on demand to further isolate the blast radius of applications.
-
-### Cloud Provider Stack
-See [infrastructure-stack](#infrastructure-stack).
-
-### Crossplane Instance
-Crossplane is a multicloud control plane, that happens to use the Kubernetes API machinery
-as a platform for declarative management. A Crossplane Instance is an instance of a
-Kuberentes API server with the Crossplane Stacks Manager installed into it, capable of
-installing cloud provider or application Stacks to build a custom control plane for one
-or more environments.
-
-### Dedicated Crossplane Instance
-Crossplane instance running on a dedicated k8s API server with no Kubernetes worker nodes.
-The Dedicated Crossplane Instance is separate from the target Kubernetes cluster(s) where
-application deployments and pods are scheduled to run.
-
-### Embedded Crossplane Instance
-Crossplane instance running on the same Kubernetes API server as the Kubernetes target cluster
-where app deployments and pods will run.
-
-### Cloud Provider
-Cloud provider such as GCP, AWS, Azure offering IaaS, cloud networking, and managed services.
-
-### Managed Service Provider
-Managed service provider such as Elastic Cloud, MLab, PKS that run on cloud provider IaaS.
-
-### Provider
-A Crossplane kind that connects Crossplane to a cloud provider or managed service provider.
-
-### Infrastructure
-Infrastructure ranging from low level services like clusters and servers,
-to higher level infrastructure like databases, message queues, buckets,
-secure connectivity, managed Kubernetes, and more
-
-### Infrastructure Namespace
-Crossplane supports connecting multiple cloud provider accounts from
-a single control plane, so different environments (dev, staging, prod) can
-use separate accounts, projects, and/or credentials.
-
-The provider and resource classes for these environments can be kept separate
-using an infrastructure namespace (gcp-infra-dev, aws-infra-dev, or azure-infra-dev)
-for each environment. You can create as many as you like using whatever naming works best for your organization.
-
-### Project Namespace
-When running a shared control plane or cluster it's a common practice to
-create separate project namespaces (app-project1-dev) for each app project or team so their resource
-are kept separate and secure. Crossplane supports this model.
-
-### App Project Namespace
-See [project-namespace](#project-namespace)
-
-### Dynamic Provisioning
-Dynamic provisioning is when an resource claim does not find a matching resource and provisions
-a new one instead. The newly provisioned resource is automatically bound to the resource claim.
-To enable dynamic provisioning the administrator needs to create one or more resource class objects.
-
-### Static Provisioning
-Static provisioning is when an administrator creates the resource manually. They set the configuration required to
-provision and manage the corresponding external resource within a cloud provider or cloud offering.
-Once provisioned, resources are available to be bound to resource claims.
-
-### Resource
-A resource represents an external piece of infrastructure ranging from low level services like clusters and
-servers, to higher level infrastructure like databases, message queues, buckets, and more
-
-### External Resource
-An actual resource that exists outside Kubernetes, typically in the cloud.
-AWS RDS and GCP Cloud Memorystore instances are external resources.
-
-### Managed Resource
-The Crossplane representation of an external resource.
-The `RDSInstance` and `CloudMemorystoreInstance` Kubernetes kinds are managed
-resources. A managed resource models the satisfaction of a need; i.e. the need
-for a Redis Cluster is satisfied by the allocation (aka binding) of a
-`CloudMemoryStoreInstance`.
-
-### Resource Claim
-The Crossplane representation of a request for the
-allocation of a managed resource. Resource claims typically represent the need
-for a managed resource that implements a particular protocol. `MySQLInstance`
-and `RedisCluster` are examples of resource claims.
-
-### Resource Class
-The Crossplane representation of the desired configuration
-of a managed resource. Resource claims reference a resource class in order to
-specify how they should be satisfied by a managed resource.
-
-### Cloud-Specific Resource Class
-Cloud-specific Resource Classes capture reusable, best-practice configurations for a specific managed service.
-
-For example, Wordpress requires a MySQL database which can be satisfied by CloudSQL, RDS, or Azure DB, so
-cloud-specific resource classes would be created for CloudSQL, RDS, and Azure DB.
-
-### Non-Portable Resource Class
-Another term for [cloud-specific resource class](#cloud-specific-resource-class).
-
-### Portable Resource Class
-Portable Resource Classes define a named class of service that can be used by portable `Resource Claims`
-in the same namespace. When used in a project namespace, this enables the
-project to provision portable managed services using `kubectl`.
-
-### Connection Secret
-A Kubernetes `Secret` encoding all data required to
-connect to (or consume) an external resource.
-
-### Claimant
-The Kubernetes representation of a process wishing
-to connect to a managed resource, typically a `Pod` or some abstraction
-thereupon such as a `Deployment` or `KubernetesApplication`.
-
-### Consumer
-See [claimant](#claimant).
-
-### Workload
-We model workloads as schedulable units of work that the user intends to run on a cloud provider.
-Crossplane will support multiple types of workloads including container and serverless.
-You can think of workloads as units that run your code and applications.
-Every type of workload has a different kind of payload.
-
-### Kubernetes Application
-A `KubernetesApplication` is a type of workload, with a `KubernetesCluster` label selector
-used for scheduling, and a series of resource templates representing resources
-to be deployed to the scheduled cluster, and managed resources are provisioned
-and securely connected to the application.
-
-### Cluster
-A Kubernetes cluster.
-
-### Target Cluster
-A Kubernetes cluster where application deployments and pods are scheduled to run.
-
-### Managed Cluster
-A Managed Kubernetes cluster from a service provider such as GKE, EKS, or AKS.
-
-### In-Tree
-In-tree means its source code lives in a core Crossplane git repository.
-
-### Out-of-Tree
-Out-of-tree means its source code lives outside of a core Crossplane git repository.
-
-Often used to refer to Crossplane extensions, controllers or Stacks.
-
-Out-of-tree extensibility enables to the community to build, release, publish,
-and install Crossplane extensions separately from the core Crossplane repos.
diff --git a/docs/v0.3/developer-guide.md b/docs/v0.3/developer-guide.md
deleted file mode 100644
index ed6246df..00000000
--- a/docs/v0.3/developer-guide.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: Developer Guide
-toc: true
-weight: 710
----
-# Developer Guide
-
-Welcome to the Crossplane Developer Guide!
-
-## Overview
-
-Infra Stacks like [stack-gcp][stack-gcp], [stack-aws][stack-aws], and
-[stack-azure][stack-azure] extend Crossplane to support managed service
-provisioning (databases, caches, buckets), secure connectivity (VPCs, subnets,
-peering, ACLs, secrets), and provisioning managed Kubernetes clusters on demand
-to further isolate the blast radius of applications.
-
-Infra Stacks are typically pre-built and published to the [Stacks
-registry][stack-registry], where they can be installed by a cluster
-administrator using a [`ClusterStackInstall`][stack-install-docs] kind via the
-Kubernetes API or with the [`stack install`][crossplane-cli-usage] command.
-
-App Stacks depend on Infra Stacks like [stack-gcp][stack-gcp],
-[stack-aws][stack-aws], or [stack-azure][stack-azure] to provide the managed
-services they depend on via the Kubernetes API.
-
-App Stacks may also be pre-built and published to the [Stacks
-registry][stack-registry] where they can be deployed by application teams using
-a [`StackInstall`][crossplane-cli-usage] kind via the Kubernetes API or with
-the [`stack install`][crossplane-cli-usage] command.
-
-## Infra Stacks
-
-### Using Infra Stacks
-
-The [Crossplane Services Guide][services-user-guide] shows how to use existing
- Infra Stacks to deploy a Wordpress `Deployment` that securely consumes a MySQL
- instance from GCP, AWS, or Azure all from `kubectl`.
-
-### Building Infra Stacks
-
-Infra Stacks are out-of-tree Crossplane extensions that can be built and
-published on their own schedule separate from the core Crossplane repos.
-
-Crossplane enables the community to build a modular, open cloud control plane
-where any cloud service or capability can be added using the [Stack
-Manager][stack-manager], an extension manager for the Kubernetes API. Crossplane
-Stacks simplify the work required to build, publish, install and manage control
-plane extensions with a powerful RBAC permission model, integrated dependency
-management, and more.
-
-The [Services Developer Guide][services-developer-guide] shows how to:
-
-* Extend existing Infra Stacks ([stack-gcp][stack-gcp], [stack-aws][stack-aws],
- [stack-azure][stack-azure]) to add more cloud services.
-* Build a new Infra Stack to add more cloud providers.
-* Make independent cloud offerings available via the Kubernetes API, so
- application teams can use them just like standard Kubernetes resources.
-
-## App Stacks
-
-### Using App Stacks
-
-The [Crossplane Stacks Guide][stack-user-guide] guide shows how to use a
-[portable App Stack][stack-wordpress-registry] that can deploy with any Infra
-Stack including: [stack-gcp][stack-gcp], [stack-aws][stack-aws], or
-[stack-azure][stack-azure].
-
-### Building App Stacks
-
-To learn how to build a "Hello World" Stack see the [Stacks Quick Start][stack-quick-start].
-
-For a complete App Stack, see the [portable Wordpress App
-Stack][stack-wordpress] with a kubebuilder-based app
-[`Controller`][kubernetes-controller] that owns a `WordressInstance` CRD, builds
-a complete `KubernetesApplication`, and automates much of what's covered in the
-[Crossplane Services Guide][services-user-guide] plus dynamic cluster
-provisioning, so you can provision a complete Wordpress app instance from
-`kubectl` using a single Kubernetes object.
-
-## Learn More
-
-If you have any questions, please drop us a note on [Crossplane
-Slack][join-crossplane-slack] or [contact us][contact-us]!
-
-To [learn more][learn-more] checkout these [useful links][learn-more].
-
-
-[services-user-guide]: services-guide.md
-[stack-user-guide]: stacks-guide.md
-[stack-registry]: https://hub.docker.com/search?q=crossplane&type=image
-[crossplane-cli-usage]: https://github.com/crossplaneio/crossplane-cli#usage
-[stack-install-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#installation-flow
-[stack-gcp]: https://github.com/crossplaneio/stack-gcp
-[stack-aws]: https://github.com/crossplaneio/stack-aws
-[stack-azure]: https://github.com/crossplaneio/stack-azure
-[stack-wordpress]: https://github.com/crossplaneio/sample-stack-wordpress
-[stack-wordpress-registry]: https://hub.docker.com/r/crossplane/sample-stack-wordpress
-[stack-manager]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#terminology
-[services-developer-guide]: services-developer-guide.md
-[stack-quick-start]: https://github.com/crossplaneio/crossplane-cli#quick-start-stacks
-[kubernetes-controller]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-controllers
-[join-crossplane-slack]: https://slack.crossplane.io
-[contact-us]: https://github.com/crossplaneio/crossplane#contact
-[learn-more]: learn-more.md
diff --git a/docs/v0.3/faqs.md b/docs/v0.3/faqs.md
deleted file mode 100644
index f4538258..00000000
--- a/docs/v0.3/faqs.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-title: FAQs
-toc: true
-weight: 840
-indent: true
----
-# Frequently Asked Questions (FAQs)
-
-### Where did the name Crossplane come from?
-
-Crossplane is the fusing of cross-cloud control plane. We wanted to use a noun that refers to the entity responsible for connecting different cloud providers and acts as control plane across them. Cross implies “cross-cloud” and “plane” brings in “control plane”.
-
-### What's up with popsicle?
-
-We believe in a multi-flavor cloud.
-
-### Why is Upbound open sourcing this project? What are Upbound’s monetization plans?
-
-Upbound’s mission is to create a more open cloud-computing platform, with more choice and less lock-in. We believe the Crossplane as an important step towards this vision and that it’s going to take a village to solve this problem. We believe that multicloud control plane is a new category of open source software, and it will ultimately disrupt closed source and proprietary models. Upbound aspires to be a commercial provider of a more open cloud-computing platform.
-
-### What kind of governance model will be used for Crossplane?
-
-Crossplane will be an independent project and we plan on making a community driven project and not a vendor driven project. It will have an independent brand, github organization, and an open governance model. It will not be tied to single organization or individual.
-
-### Will Crossplane be donated to an open source foundation?
-
-We don’t know yet. We are open to doing so but we’d like to revisit this after the project has gotten some end-user community traction.
-
-### Does using multicloud mean you will use the lowest common denominator across clouds?
-
-Not necessarily. There are numerous best of breed cloud offerings that run on multiple clouds. For example, CockroachDB and ElasticSearch are world class implementations of platform software and run well on cloud providers. They compete with managed services offered by a cloud provider. We believe that by having an open control plane for them to integrate with, and providing a common API, CLI and UI for all of these services, that more of these offerings will exist and get first-class experience in the cloud.
-
-### How are resources and claims related to PersistentVolumes in Kubernetes?
-
-We modeled resource claims and classes after PersistentVolumes and PersistentVolumeClaims in Kubernetes. We believe many of the lessons learned from managing volumes in Kubernetes apply to managing resources within cloud providers. One notable exception is that we avoided creating a plugin model within Crossplane.
-
-### How is workload scheduling related to pod scheduling in Kubernetes?
-
-We modeled workload scheduling after the Pod scheduler in Kubernetes. We believe many of the lessons learned from Pod scheduling apply to scheduling workloads across cloud providers.
-
-### Can I use Crossplane to consistently provision and manage multiple Kubernetes clusters?
-
-Crossplane includes a portable API for Kubernetes clusters that will include common configuration including node pools, auto-scalers, taints, admission controllers, etc. These will be applied to the specific implementations within the cloud providers like EKS, GKE and AKS. We see the Kubernetes Cluster API to be something that will be used by administrators and not developers.
-
-### Other attempts at building a higher level API on-top of a multitude of inconsistent lower level APIs have not been successful, will Crossplane not have the same issues?
-
-We agree that building a consistent higher level API on top of multitudes of inconsistent lower level API's is well known to be fraught with peril (e.g. dumbing down to lowest common denominator, or resulting in so loosely defined an API as to be impossible to practically develop real portable applications on top of it).
-
-Crossplane follows a different approach here. The portable API extracts the pieces that are common across all implementations, and from the perspective of the workload. The rest of the implementation details are captured in full fidelity by the admin in resource classes. The combination of the two is what results in full configuration that can be deployed. We believe this to be a reasonable tradeoff that avoids the dumbing down to lowest common denominator problem, while still enabling portability.
diff --git a/docs/v0.3/gitlab/gitlab-aws.md b/docs/v0.3/gitlab/gitlab-aws.md
deleted file mode 100644
index 6364f965..00000000
--- a/docs/v0.3/gitlab/gitlab-aws.md
+++ /dev/null
@@ -1,427 +0,0 @@
-# Deploying GitLab in AWS
-
-This user guide will walk you through GitLab application deployment using Crossplane managed resources and
-the official GitLab Helm chart.
-
-The following components are dynamically provisioned and configured during this guide:
-
-* An RDS Postgres database
-* A Redis cluster
-* A sample Gitlab application
-
-
-
-
-## Pre-requisites
-
-* Before starting this guide, you should have already [configured your AWS account](../../cloud-providers/aws/aws-provider.md) for use with Crossplane.
-* You should also have an AWS credentials file at `~/.aws/credentials` already on your local filesystem.
-* [Helm](https://docs.helm.sh/using_helm/), minimum version `v2.10.0+`.
-* [jq](https://stedolan.github.io/jq/) - commandline JSON processor `v1.5+`
-* [AWS cli](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)
-
-## Preparation
-
-### EKS Cluster
-Follow [GitLab instruction](https://docs.gitlab.com/charts/installation/cloud/eks.html#scripted-cluster-creation) to create and bootstrap EKS Kubernetes cluster
-
-### Crossplane
-
-Using the newly provisioned cluster:
-
-- Install Crossplane from master channel using the [Crossplane Installation Guide](../install-crossplane.md#master)
-- Install the AWS stack into Crossplane using the [AWS stack section](../install-crossplane.md#aws-stack) of the install guide.
-- Obtain [Cloud Provider Credentials](../cloud-providers.md)
-
-#### Region
-- Export the region of the EKS cluster you're provisioned for this demo
-```
-export REGION=region-of-eks-west-1
-```
-
-#### EKS kubeconfig
-- Obtain EKS Cluster credentials and set as your current context
-```bash
-aws eks --region $REGION update-kubeconfig --name [your-CLUSTER_NAME]
-```
-
-#### AWS provider
-
-Create provider:
-```console
-sed -e "s|REGION|$REGION|g;s|BASE64ENCODED_AWS_PROVIDER_CREDS|`base64 ~/.aws/credentials | tr -d '\n'`|g;" cluster/examples/gitlab/aws/provider.yaml | kubectl create -f -
-```
-
-- Verify AWS provider was successfully registered by the crossplane
- ```bash
- kubectl get providers.aws.crossplane.io -n crossplane-system
- kubectl get secrets -n crossplane-system
- ```
-
- - You should see output similar to:
-
- ```bash
- NAME PROJECT-ID AGE
- demo-aws your-project-123456 11m
- NAME TYPE DATA AGE
- default-token-974db kubernetes.io/service-account-token 3 2d16h
- demo-aws-creds Opaque 1 103s
- ```
-
-#### Create an RDS subnet group
-1. Navigate to the aws console in same region as the EKS cluster
-1. Navigate to `RDS` service
-1. Navigate to `Subnet groups` in left hand pane
-1. Click `Create DB Subnet Group`
-1. Name your subnet i.e. `eks-db-subnets`
-1. Select the VPC created in the EKS VPC step
-1. Click `Add all subnets related to this VPC`
-1. Click Create
-1. Export the db subnet group name
- ```console
- export RDS_SUBNET_GROUP_NAME=replace-with-DBSubnetgroup-name
- ```
-#### Create an RDS/Redis Security Group (example only)
-
-> Note: This will make your RDS and Redis instance visible from anywhere on the internet.
-This is for **EXAMPLE PURPOSES ONLY** and is **NOT RECOMMENDED** for production system.
-
-1. Navigate to ec2 in the same region as the EKS cluster
-1. Click: security groups
-1. Click `Create Security Group`
-1. Name it, ex. `bad-idea-public-visibility`
-1. Give it a description
-1. Select the same VPC as the EKS cluster.
-1. On the Inbound Rules tab, choose `Add Rule`.
- - For Type, choose `Custom TCP Rule`
- - For Port Range, type `6379`
- - For Source, choose `Anywhere` from drop down or type: `0.0.0.0/0`
- - Click `Add Rule` again
- - For Type, choose `PostgreSQL`
- - For Source, choose `Anywhere` from drop down or type: `0.0.0.0/0`
-1. Choose Add another rule if you need to add more IP addresses or different port ranges.
-1. Click: Create
-1. Export the security group id
- ```console
- export REDIS_SECURITY_GROUP=replace-with-security-group-id
- export RDS_SECURITY_GROUP=replace-with-security-group-id
- ```
-
-#### Create an Elasticache Subnet Group
-1. Navigate to the aws console in same region as the EKS cluster
-1. Navigate to `Elasticache` service
-1. Navigate to `Subnet groups` in left hand pane
-1. Click `Create Subnet Group`
-1. Name your subnet i.e. `redis-subnets`
-1. Select the VPC created in the EKS VPC step
-1. Click `Add all subnets related to this VPC`
-1. Click Create
-1. Export the db subnet group name
-
-```console
-export REDIS_SUBNET_GROUP=replace-me-with-redis-subnet-group
-```
-
-
-#### Resource Classes
-Create Crossplane Resource Class needed to provision managed resources for GitLab applications
-
-```bash
-sed -e "s|REDIS_SECURITY_GROUP|$REDIS_SECURITY_GROUP|g;s|REDIS_SUBNET_GROUP|$REDIS_SUBNET_GROUP|g;s|REGION|$REGION|g;s|RDS_SUBNET_GROUP_NAME|$RDS_SUBNET_GROUP_NAME|g;s|RDS_SECURITY_GROUP|$RDS_SECURITY_GROUP|g" cluster/examples/gitlab/aws/resource-classes/* | kubectl create -f -
-```
-
-```
-resourceclass.core.crossplane.io/standard-aws-bucket created
-resourceclass.core.crossplane.io/standard-aws-postgres created
-resourceclass.core.crossplane.io/standard-aws-redis created
-```
-
-Verify
-
-```bash
-kubectl get resourceclasses -n crossplane-system
-```
-
-```
-NAME PROVISIONER PROVIDER-REF RECLAIM-POLICY AGE
-standard-aws-bucket s3buckets.storage.aws.crossplane.io/v1alpha1 demo-aws Delete 17s
-standard-aws-postgres rdsinstance.database.aws.crossplane.io/v1alpha1 demo-aws Delete 17s
-standard-aws-redis replicationgroup.cache.aws.crossplane.io/v1alpha1 demo-aws Delete 17s
-```
-
-#### Resource Claims
-Provision Managed Resources required by GitLab application using Crossplane Resource Claims.
-
-Note: you can use a separate command for each claim file, or create all claims in one command, like so:
-
-```bash
-kubectl create -Rf cluster/examples/gitlab/aws/resource-claims/
-```
-```
-postgresqlinstance.database.crossplane.io/gitlab-postgresql created
-rediscluster.cache.crossplane.io/gitlab-redis created
-bucket.storage.crossplane.io/gitlab-artifacts created
-bucket.storage.crossplane.io/gitlab-backups-tmp created
-bucket.storage.crossplane.io/gitlab-backups created
-bucket.storage.crossplane.io/gitlab-externaldiffs created
-bucket.storage.crossplane.io/gitlab-lfs created
-bucket.storage.crossplane.io/gitlab-packages created
-bucket.storage.crossplane.io/gitlab-pseudonymizer created
-bucket.storage.crossplane.io/gitlab-registry created
-bucket.storage.crossplane.io/gitlab-uploads created
-```
-
-Verify that the resource claims were successfully provisioned.
-```bash
-kubectl get -f cluster/examples/gitlab/aws/resource-claims/postgres.yaml
-kubectl get -f cluster/examples/gitlab/aws/resource-claims/redis.yaml
-```
-
-```
-NAME STATUS CLASS VERSION AGE
-gitlab-postgresql Bound standard-aws-postgres 9.6 5m27s
----
-NAME STATUS CLASS VERSION AGE
-gitlab-redis Bound standard-aws-redis 3.2 7m10s
-```
-
-```bash
-# check all bucket claims
-kubectl get -f cluster/examples/gitlab/aws/resource-claims/buckets/
-```
-```text
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-artifacts Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-backups-tmp Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-backups Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-externaldiffs Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-lfs Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-packages Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-pseudonymizer Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-registry Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-uploads Bound standard-aws-bucket 4m49s
-```
-
-What we are looking for is for `STATUS` value to become `Bound` which indicates the managed resource was successfully provisioned and is ready for consumption
-
-##### Resource Claims Connection Secrets
-Verify that every resource has created a connection secret
-```bash
-kubectl get secrets -n default
-```
-```
-NAME TYPE DATA AGE
-default-token-mzsgg kubernetes.io/service-account-token 3 5h42m
-gitlab-artifacts Opaque 4 6m41s
-gitlab-backups Opaque 4 7m6s
-gitlab-backups-tmp Opaque 4 7m7s
-gitlab-externaldiffs Opaque 4 7m5s
-gitlab-lfs Opaque 4 7m4s
-gitlab-packages Opaque 4 2m28s
-gitlab-postgresql Opaque 3 30m
-gitlab-pseudonymizer Opaque 4 7m2s
-gitlab-redis Opaque 1 28m
-gitlab-registry Opaque 4 7m1s
-gitlab-uploads Opaque 4 7m1s
-```
-
-Note: Kubernetes cluster claim is created in "privileged" mode; thus the kubernetes cluster resource secret is located in `crossplane-system` namespace, however, you will not need to use this secret for our GitLab demo deployment.
-
-At this point, all GitLab managed resources should be ready to consume and this completes the Crossplane resource provisioning phase.
-
-#### Managed Resource Secrets
-
-##### Convert Secrets and Export Valuess
-GitLab requires to provide connection information in the specific format per cloud provider.
-In addition, we need to extract endpoints and additional managed resource properties and add them to helm values.
-
-There is an [ongoing effort](https://github.com/crossplaneio/crossplane/issues/489) to improve secret consumption from GitLab such that secrets produced by Crossplane controllers are directly consumed without transformation.
-
-We will use a convenience script for this purpose.
-Note: your output may be different
-```bash
-./cluster/examples/gitlab/aws/secrets.sh
-```
-```
-Current cluster kubectl context: eks_you-project-123456_us-central1-a_eks-a2345dfb1-asdf-11e9-ac37-9cb6d08bde99
----
-Source cluster secrets:
-NAME TYPE DATA AGE
-default-token-mzsgg kubernetes.io/service-account-token 3 2d7h
-gitlab-artifacts Opaque 4 34h
-gitlab-backups Opaque 4 34h
-gitlab-backups-tmp Opaque 4 34h
-gitlab-externaldiffs Opaque 4 34h
-gitlab-lfs Opaque 4 34h
-gitlab-packages Opaque 4 34h
-gitlab-postgresql Opaque 3 2d2h
-gitlab-pseudonymizer Opaque 4 34h
-gitlab-redis Opaque 1 2d2h
-gitlab-registry Opaque 4 34h
-gitlab-uploads Opaque 4 34h
----
-Generate PostgreSQL secret and values file
-secret/gitlab-postgresql created
----
-Generate Redis values file
----
-Generate Buckets secrets
-secret/bucket-artifacts created
-secret/bucket-backups-tmp created
-secret/bucket-backups created
-secret/bucket-externaldiffs created
-secret/bucket-lfs created
-secret/bucket-packages created
-secret/bucket-pseudonymizer created
-secret/bucket-registry created
-secret/bucket-uploads created
-
-```
-
-## Install
-Render the official GitLab Helm chart with the generated values files, and your settings into a `gitlab-aws.yaml` file.
-See [GitLab Helm Documentation](https://docs.gitlab.com/charts/installation/deployment.html) for the additional details
-
-```bash
-helm repo add gitlab https://charts.gitlab.io/
-helm repo update
-helm fetch gitlab/gitlab --version v1.7.1
-helm template gitlab-1.7.1.tgz --name gitlab-demo --namespace default \
- -f cluster/examples/gitlab/aws/values-buckets.yaml \
- -f cluster/examples/gitlab/aws/values-redis.yaml \
- -f cluster/examples/gitlab/aws/values-psql.yaml \
- --set global.hosts.domain=[your.domain] \
- --set global.hosts.hostSuffix=demo \
- --set certmanager-issuer.email=email@account.io > gitlab-aws.yaml
-```
-
-Examine `gitlab-aws.yaml` to familiarize yourself with all GitLab components.
-
-Install GitLab
-Note: your output may look different:
-```bash
-kubectl create -f gitlab-aws.yaml
-```
-
-Validate GitLab components:
-
-```bash
-kubectl get jobs,deployments,statefulsets
-```
-
-It usually takes few minutes for all GitLab components to get initialized and be ready.
-
-Note: During the initialization "wait", some pods could automatically restart, but this should stabilize once all the
-dependent components become available.
-
-Note: There also could be intermittent `ImagePullBackOff`, but those, similar to above should clear up by themselves.
-
-Note: It appears the `gitlab-demo-unicorn-test-runner-*` (job/pod) will Error and will not re-run, unless the pod is resubmitted.
-
-After few minutes your output for:
-```bash
-kubectl get pod
-```
-Should look similar to:
-```bash
-NAME READY STATUS RESTARTS AGE
-gitlab-demo-certmanager-59f887dc9-jppl7 1/1 Running 0 9m
-gitlab-demo-gitaly-0 1/1 Running 0 9m
-gitlab-demo-gitlab-runner-fcc9cc7cf-c7pzz 0/1 Init:0/1 0 9m
-gitlab-demo-gitlab-shell-57b887755c-kqm89 1/1 Running 0 8m
-gitlab-demo-gitlab-shell-57b887755c-vzqkf 1/1 Running 0 9m
-gitlab-demo-issuer.0-ddzwp 0/1 Completed 0 9m
-gitlab-demo-migrations.0-2h5px 1/1 Running 2 9m
-gitlab-demo-nginx-ingress-controller-7bf4f7574d-cznfl 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-controller-7bf4f7574d-f5wjz 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-controller-7bf4f7574d-mxqpz 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-default-backend-5886cb59c7-bjnrt 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-default-backend-5886cb59c7-gchhp 1/1 Running 0 9m
-gitlab-demo-prometheus-server-64897864cf-p4sd7 2/2 Running 0 9m
-gitlab-demo-registry-746bbb488f-xjlhp 1/1 Running 0 8m
-gitlab-demo-registry-746bbb488f-xxpcr 1/1 Running 0 9m
-gitlab-demo-shared-secrets.0-mr7-2v5cf 0/1 Completed 0 9m
-gitlab-demo-sidekiq-all-in-1-5dd8b5b9d-58p72 1/1 Running 0 9m
-gitlab-demo-task-runner-7c477b48dc-d5nf6 1/1 Running 0 9m
-gitlab-demo-unicorn-6dd757db97-4vqgc 1/2 ImagePullBackOff 0 9m
-gitlab-demo-unicorn-6dd757db97-nmglt 2/2 Running 0 8m
-gitlab-demo-unicorn-test-runner-f2ttk 0/1 Error 0 9m
-```
-
-Note: if `ImagePullBackOff` error Pod does not get auto-cleared, consider deleting the pod.
-A new pod should come up with "Running" STATUS.
-
-## Use
-Retrieve the DNS name using GitLab ingress componenet:
-```bash
-kubectl get ingress
-```
-You should see following ingress configurations:
-```
-NAME HOSTS ADDRESS PORTS AGE
-gitlab-demo-registry registry-demo.upbound.app 35.222.163.203 80, 443 14m
-gitlab-demo-unicorn gitlab-demo.upbound.app 35.222.163.203 80, 443 14m
-```
-
-Navigate your browser to https://gitlab-demo.[your-domain], and if everything ran successfully, you should see:
-
-
-
-## Uninstall
-
-### GitLab
-To remove the GitLab application: run:
-```bash
-kubectl delete -f gitlab-aws.yaml
-```
-
-### Crossplane
-
-Delete all managed resources by running:
-```bash
-kubectl delete -Rf cluster/examples/gitlab/aws/resource-claims
-```
-```
-bucket.storage.crossplane.io "gitlab-artifacts" deleted
-bucket.storage.crossplane.io "gitlab-backups-tmp" deleted
-bucket.storage.crossplane.io "gitlab-backups" deleted
-bucket.storage.crossplane.io "gitlab-externaldiffs" deleted
-bucket.storage.crossplane.io "gitlab-lfs" deleted
-bucket.storage.crossplane.io "gitlab-packages" deleted
-bucket.storage.crossplane.io "gitlab-pseudonymizer" deleted
-bucket.storage.crossplane.io "gitlab-registry" deleted
-bucket.storage.crossplane.io "gitlab-uploads" deleted
-postgresqlinstance.database.crossplane.io "gitlab-postgresql" deleted
-rediscluster.cache.crossplane.io "gitlab-redis" deleted
-```
-
-Verify that all resource claims have been removed:
-```bash
-kubectl get -Rf cluster/examples/gitlab/aws/resource-claims
-```
-Note: typically it may take few seconds for Crossplane to process the request.
-By running resource and provider removal in the same command or back-to-back, we are running the risk of having orphaned resource.
-I.E., a resource that could not be cleaned up because the provider is no longer available.
-
-Delete all resource classes:
-```bash
-kubectl delete -Rf cluster/examples/gitlab/aws/resource-classes/
-```
-```
-resourceclass.core.crossplane.io "standard-aws-bucket" deleted
-resourceclass.core.crossplane.io "standard-aws-postgres" deleted
-resourceclass.core.crossplane.io "standard-aws-redis" deleted
-```
-
-Delete aws-provider and secrets
-```bash
-kubectl delete -f cluster/examples/gitlab/aws/provider.yaml
-```
diff --git a/docs/v0.3/gitlab/gitlab-gcp.md b/docs/v0.3/gitlab/gitlab-gcp.md
deleted file mode 100644
index 0f3ba3c8..00000000
--- a/docs/v0.3/gitlab/gitlab-gcp.md
+++ /dev/null
@@ -1,402 +0,0 @@
-# Deploying GitLab in GCP
-
-This user guide will walk you through GitLab application deployment using Crossplane managed resources and
-the official GitLab Helm chart.
-
-## Pre-requisites
-
-* [Helm](https://docs.helm.sh/using_helm/), minimum version `v2.10.0+`.
-* [jq](https://stedolan.github.io/jq/) - commandline JSON processor `v1.5+`
-
-
-## Preparation
-
-### GKE Cluster
-Follow [GitLab instruction](https://docs.gitlab.com/charts/installation/cloud/gke.html#scripted-cluster-creation) to create and bootstrap GKE Kubernetes cluster
-
-- Obtain GKE cluster credentials
-```bash
-gcloud container clusters get-credentials [your-gke-cluster] --zone [your-cluster-zone] --project [your-gcp-project]
-```
-
-- Configure `kubectl` current context to point to your GKE cluster where you want to deploy GitLab application.
-
-Note: this step is optional since: `gcloud container clusters get-credentials` will automatically set the current context to newly connected cluster
-```bash
-kubectl config get-contexts
-kubectl config set-context [your-cluster-context]
-```
-
-### Crossplane
-
-Using the newly provisioned cluster:
-
-- Install Crossplane from master channel using the [Crossplane Installation Guide](../install-crossplane.md#master)
-- Install the GCP stack into Crossplane using the [GCP stack section](../install-crossplane.md#gcp-stack) of the install guide.
-- Obtain [Cloud Provider Credentials](../cloud-providers.md)
-
-#### GCP Provider
-It is essential to make sure that the GCP Service Account used by the Crossplane GCP Provider has the following Roles:
-
- Cloud SQL Admin
- Kubernetes Engine Admin
- Service Account User
- Cloud Memorystore Redis Admin
- Storage Admin
-
-Using GCP Service Account `gcp-credentials.json`:
-- Generate BASE64ENCODED_GCP_PROVIDER_CREDS encoded value:
-```bash
-base64 gcp-credentials.json | tr -d "\n"
-```
-
-- Update [provider.yaml](../../cluster/examples/gitlab/gcp/provider.yaml) replacing `BASE64ENCODED_GCP_PROVIDER_CREDS`
-- Update [provider.yaml](../../cluster/examples/gitlab/gcp/provider.yaml) replacing `PROJECT_ID` with `project_id` from the credentials.json
-
-#### GCS
-It is recommended to create a separate GCP Service Account dedicated to storage operations only, i.e. with a reduced IAM role set, for example: `StorageAdmin` only.
-
-Follow the same step as for GCP credentials to create and obtain `gcs-credentials.json`
-- Generate BASE64ENCODED_GCS_PROVIDER_CREDS encoded value:
-```bash
-base64 gcs-credentials.json | tr -d "\n"
-```
-
-Otherwise, you can use `BASE64ENCODED_GCP_PROVIDER_CREDS` in place of `BASE64ENCODED_GCS_PROVIDER_CREDS`
-
-- Update [provider.yaml](../../cluster/examples/gitlab/gcp/provider.yaml) replacing `BASE64ENCODED_GCS_PROVIDER_CREDS`
-
-##### GCS Interoperability
-- Navigate to: https://console.cloud.google.com/storage/settings in your GCP project
-- Click on `Interoperability` Tab
-- Using `Interoperable storage access keys` generate `BASE64ENCODED` values
- - `BASE64ENCODED_GCS_INTEROP_ACCESS_KEY`
- - `BASE64ENCODED_GCS_INTEROP_SECRET`
-- Update [provider.yaml](../../cluster/examples/gitlab/gcp/provider.yaml) replacing:
- - `BASE64ENCODED_GCS_INTEROP_ACCESS_KEY`
- - `BASE64ENCODED_GCS_INTEROP_SECRET`
-
-#### Create
-- Create GCP provider:
- ```bash
- kubectl create -f cluster/examples/gitlab/gcp/provider.yaml
- ```
-- Verify GCP provider was successfully registered by the crossplane
- ```bash
- kubectl get providers.gcp.crossplane.io -n crossplane-system
- kubectl get secrets -n crossplane-system
- ```
-
- - You should see output similar to:
-
- ```bash
- NAME PROJECT-ID AGE
- demo-gcp your-project-123456 11m
- NAME TYPE DATA AGE
- default-token-974db kubernetes.io/service-account-token 3 2d16h
- demo-gcp-creds Opaque 1 103s
- demo-gcs-creds Opaque 3 2d11h
- ```
-
-#### Resource Classes
-Create Crossplane Resource Class needed to provision managed resources for GitLab applications
-
-```bash
-kubectl create -f cluster/examples/gitlab/gcp/resource-classes/
-```
-```
-resourceclass.core.crossplane.io/standard-gcp-bucket created
-resourceclass.core.crossplane.io/standard-gcp-cluster created
-resourceclass.core.crossplane.io/standard-gcp-postgres created
-resourceclass.core.crossplane.io/standard-gcp-redis created
-```
-
-Verify
-```bash
-kubectl get resourceclasses -n crossplane-system
-```
-```
-NAME PROVISIONER PROVIDER-REF RECLAIM-POLICY AGE
-standard-gcp-bucket bucket.storage.gcp.crossplane.io/v1alpha1 demo-gcp Delete 17s
-standard-gcp-cluster gkecluster.compute.gcp.crossplane.io/v1alpha1 demo-gcp Delete 17s
-standard-gcp-postgres cloudsqlinstance.database.gcp.crossplane.io/v1alpha1 demo-gcp Delete 17s
-standard-gcp-redis cloudmemorystoreinstance.cache.gcp.crossplane.io/v1alpha1 demo-gcp Delete 17s
-```
-
-#### Resource Claims
-Provision Managed Resources required by GitLab application using Crossplane Resource Claims.
-
-Note: you can use a separate command for each claim file, or create all claims in one command, like so:
-
-```bash
-kubectl create -Rf cluster/examples/gitlab/gcp/resource-claims/
-```
-```
-bucket.storage.crossplane.io/gitlab-artifacts created
-bucket.storage.crossplane.io/gitlab-backups-tmp created
-bucket.storage.crossplane.io/gitlab-backups created
-bucket.storage.crossplane.io/gitlab-externaldiffs created
-bucket.storage.crossplane.io/gitlab-lfs created
-bucket.storage.crossplane.io/gitlab-packages created
-bucket.storage.crossplane.io/gitlab-pseudonymizer created
-bucket.storage.crossplane.io/gitlab-registry created
-bucket.storage.crossplane.io/gitlab-uploads created
-postgresqlinstance.database.crossplane.io/gitlab-postgresql created
-rediscluster.cache.crossplane.io/gitlab-redis created
-```
-
-Verify that the resource claims were successfully provisioned.
-```bash
-kubectl get -f cluster/examples/gitlab/gcp/resource-claims/postgres.yaml
-kubectl get -f cluster/examples/gitlab/gcp/resource-claims/redis.yaml
-```
-
-```
-NAME STATUS CLUSTER-CLASS CLUSTER-REF AGE
-gitlab-gke Bound standard-gcp-cluster gke-af012df6-6e2a-11e9-ac37-9cb6d08bde99 4m7s
----
-NAME STATUS CLASS VERSION AGE
-gitlab-postgresql Bound standard-gcp-postgres 9.6 5m27s
----
-NAME STATUS CLASS VERSION AGE
-gitlab-redis Bound standard-gcp-redis 3.2 7m10s
-```
-
-```bash
-# check all bucket claims
-kubectl get -f cluster/examples/gitlab/gcp/resource-claims/buckets/
-```
-```text
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-artifacts Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-backups-tmp Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-backups Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-externaldiffs Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-lfs Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-packages Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-pseudonymizer Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-registry Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-uploads Bound standard-gcp-bucket 4m49s
-```
-
-What we are looking for is for `STATUS` value to become `Bound` which indicates the managed resource was successfully provisioned and is ready for consumption
-
-##### Resource Claims Connection Secrets
-Verify that every resource has created a connection secret
-```bash
-kubectl get secrets -n default
-```
-```
-NAME TYPE DATA AGE
-default-token-mzsgg kubernetes.io/service-account-token 3 5h42m
-gitlab-artifacts Opaque 4 6m41s
-gitlab-backups Opaque 4 7m6s
-gitlab-backups-tmp Opaque 4 7m7s
-gitlab-externaldiffs Opaque 4 7m5s
-gitlab-lfs Opaque 4 7m4s
-gitlab-packages Opaque 4 2m28s
-gitlab-postgresql Opaque 3 30m
-gitlab-pseudonymizer Opaque 4 7m2s
-gitlab-redis Opaque 1 28m
-gitlab-registry Opaque 4 7m1s
-gitlab-uploads Opaque 4 7m1s
-```
-
-At this point, all GitLab managed resources should be ready to consume and this completes the Crossplane resource provisioning phase.
-
-#### Managed Resource Secrets
-
-##### Convert Secrets and Export Values
-GitLab requires to provide connection information in the specific format per cloud provider.
-In addition, we need to extract endpoints and additional managed resource properties and add them to helm values.
-
-There is an [ongoing effort](https://github.com/crossplaneio/crossplane/issues/489) to improve secret consumption from GitLab such that secrets produced by Crossplane controllers are directly consumed without transformation.
-
-We will use a convenience script for this purpose.
-Note: your output may be different
-```bash
-./cluster/examples/gitlab/gcp/secrets.sh
-```
-```
-Current cluster kubectl context: gke_you-project-123456_us-central1-a_gke-a2345dfb1-asdf-11e9-ac37-9cb6d08bde99
----
-Source cluster secrets:
-NAME TYPE DATA AGE
-default-token-mzsgg kubernetes.io/service-account-token 3 2d7h
-gitlab-artifacts Opaque 4 34h
-gitlab-backups Opaque 4 34h
-gitlab-backups-tmp Opaque 4 34h
-gitlab-externaldiffs Opaque 4 34h
-gitlab-lfs Opaque 4 34h
-gitlab-packages Opaque 4 34h
-gitlab-postgresql Opaque 3 2d2h
-gitlab-pseudonymizer Opaque 4 34h
-gitlab-redis Opaque 1 2d2h
-gitlab-registry Opaque 4 34h
-gitlab-uploads Opaque 4 34h
----
-Generate PostgreSQL secret and values file
-secret/gitlab-postgresql created
----
-Generate Redis values file
----
-Generate Buckets secrets
-secret/bucket-artifacts created
-secret/bucket-backups-tmp created
-secret/bucket-backups created
-secret/bucket-externaldiffs created
-secret/bucket-lfs created
-secret/bucket-packages created
-secret/bucket-pseudonymizer created
-secret/bucket-registry created
-secret/bucket-uploads created
-
-```
-
-## Install
-Render the official GitLab Helm chart with the generated values files, and your settings into a `gitlab-gcp.yaml` file.
-See [GitLab Helm Documentation](https://docs.gitlab.com/charts/installation/deployment.html) for the additional details
-
-```bash
-helm repo add gitlab https://charts.gitlab.io/
-helm repo update
-helm fetch gitlab/gitlab --version v1.7.1
-helm template gitlab-1.7.1.tgz --name gitlab-demo --namespace default \
- -f cluster/examples/gitlab/gcp/values-buckets.yaml \
- -f cluster/examples/gitlab/gcp/values-redis.yaml \
- -f cluster/examples/gitlab/gcp/values-psql.yaml \
- --set global.hosts.domain=your.domain \
- --set global.hosts.hostSuffix=demo \
- --set certmanager-issuer.email=email@account.io > gitlab-gcp.yaml
-```
-
-Examine `gitlab-gcp.yaml` to familiarize yourself with all GitLab components.
-
-Install GitLab
-Note: your output may look different:
-```bash
-kubectl create -f gitlab-gcp.yaml
-```
-
-Validate GitLab components:
-
-```bash
-kubectl get jobs,deployments,statefulsets
-```
-
-It usually takes few minutes for all GitLab components to get initialized and be ready.
-
-Note: During the initialization "wait", some pods could automatically restart, but this should stabilize once all the
-dependent components become available.
-
-Note: There also could be intermittent `ImagePullBackOff`, but those, similar to above should clear up by themselves.
-
-Note: It appears the `gitlab-demo-unicorn-test-runner-*` (job/pod) will Error and will not re-run, unless the pod is resubmitted.
-
-After few minutes your output for:
-```bash
-kubectl get pod
-```
-Should look similar to:
-```bash
-NAME READY STATUS RESTARTS AGE
-gitlab-demo-certmanager-59f887dc9-jppl7 1/1 Running 0 9m
-gitlab-demo-gitaly-0 1/1 Running 0 9m
-gitlab-demo-gitlab-runner-fcc9cc7cf-c7pzz 0/1 Init:0/1 0 9m
-gitlab-demo-gitlab-shell-57b887755c-kqm89 1/1 Running 0 8m
-gitlab-demo-gitlab-shell-57b887755c-vzqkf 1/1 Running 0 9m
-gitlab-demo-issuer.0-ddzwp 0/1 Completed 0 9m
-gitlab-demo-migrations.0-2h5px 1/1 Running 2 9m
-gitlab-demo-nginx-ingress-controller-7bf4f7574d-cznfl 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-controller-7bf4f7574d-f5wjz 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-controller-7bf4f7574d-mxqpz 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-default-backend-5886cb59c7-bjnrt 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-default-backend-5886cb59c7-gchhp 1/1 Running 0 9m
-gitlab-demo-prometheus-server-64897864cf-p4sd7 2/2 Running 0 9m
-gitlab-demo-registry-746bbb488f-xjlhp 1/1 Running 0 8m
-gitlab-demo-registry-746bbb488f-xxpcr 1/1 Running 0 9m
-gitlab-demo-shared-secrets.0-mr7-2v5cf 0/1 Completed 0 9m
-gitlab-demo-sidekiq-all-in-1-5dd8b5b9d-58p72 1/1 Running 0 9m
-gitlab-demo-task-runner-7c477b48dc-d5nf6 1/1 Running 0 9m
-gitlab-demo-unicorn-6dd757db97-4vqgc 1/2 ImagePullBackOff 0 9m
-gitlab-demo-unicorn-6dd757db97-nmglt 2/2 Running 0 8m
-gitlab-demo-unicorn-test-runner-f2ttk 0/1 Error 0 9m
-```
-
-Note: if `ImagePullBackOff` error Pod does not get auto-cleared, consider deleting the pod.
-A new pod should come up with "Running" STATUS.
-
-## Use
-Retrieve the DNS name using GitLab ingress componenet:
-```bash
-kubectl get ingress
-```
-You should see following ingress configurations:
-```
-NAME HOSTS ADDRESS PORTS AGE
-gitlab-demo-registry registry-demo.upbound.app 35.222.163.203 80, 443 14m
-gitlab-demo-unicorn gitlab-demo.upbound.app 35.222.163.203 80, 443 14m
-```
-
-Navigate your browser to https://gitlab-demo.upbound.app, and if everything ran successfully, you should see:
-
-
-
-## Uninstall
-
-### GitLab
-To remove the GitLab application run:
-```bash
-kubectl delete -f gitlab-gcp.yaml
-```
-
-### Crossplane
-
-Delete all managed resources by running:
-```bash
-kubectl delete -Rf cluster/examples/gitlab/gcp/resource-claims
-```
-```
-bucket.storage.crossplane.io "gitlab-artifacts" deleted
-bucket.storage.crossplane.io "gitlab-backups-tmp" deleted
-bucket.storage.crossplane.io "gitlab-backups" deleted
-bucket.storage.crossplane.io "gitlab-externaldiffs" deleted
-bucket.storage.crossplane.io "gitlab-lfs" deleted
-bucket.storage.crossplane.io "gitlab-packages" deleted
-bucket.storage.crossplane.io "gitlab-pseudonymizer" deleted
-bucket.storage.crossplane.io "gitlab-registry" deleted
-bucket.storage.crossplane.io "gitlab-uploads" deleted
-postgresqlinstance.database.crossplane.io "gitlab-postgresql" deleted
-rediscluster.cache.crossplane.io "gitlab-redis" deleted
-```
-
-Verify that all resource claims have been removed:
-```bash
-kubectl get -Rf cluster/examples/gitlab/gcp/resource-claims
-```
-Note: typically it may take few seconds for Crossplane to process the request.
-By running resource and provider removal in the same command or back-to-back, we are running the risk of having orphaned resource.
-I.E., a resource that could not be cleaned up because the provider is no longer available.
-
-Delete all resource classes:
-```bash
-kubectl delete -Rf cluster/examples/gitlab/gcp/resource-classes/
-```
-```
-resourceclass.core.crossplane.io "standard-gcp-bucket" deleted
-resourceclass.core.crossplane.io "standard-gcp-postgres" deleted
-resourceclass.core.crossplane.io "standard-gcp-redis" deleted
-```
-
-Delete gcp-provider and secrets
-```bash
-kubectl delete -f cluster/examples/gitlab/gcp/provider.yaml
-```
diff --git a/docs/v0.3/gitlab/gitlab-login.png b/docs/v0.3/gitlab/gitlab-login.png
deleted file mode 100644
index 44c0ad1a..00000000
Binary files a/docs/v0.3/gitlab/gitlab-login.png and /dev/null differ
diff --git a/docs/v0.3/install-crossplane.md b/docs/v0.3/install-crossplane.md
deleted file mode 100644
index 49f2055b..00000000
--- a/docs/v0.3/install-crossplane.md
+++ /dev/null
@@ -1,215 +0,0 @@
----
-title: Install Crossplane
-toc: true
-weight: 220
-indent: true
----
-# Install Crossplane
-
-Crossplane can be easily installed into any existing Kubernetes cluster using the regularly published Helm chart.
-The Helm chart contains all the custom resources and controllers needed to deploy and configure Crossplane.
-
-## Pre-requisites
-
-* [Kubernetes cluster](https://kubernetes.io/docs/setup/)
- * For example [Minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/), minimum version `v0.28+`
-* [Helm](https://docs.helm.sh/using_helm/), minimum version `v2.9.1+`.
- * Make sure Helm is initialized with sufficient permissions to work on `crossplane-system` namespace.
-
-## Installation
-
-Helm charts for Crossplane are currently published to the `alpha` and `master` channels.
-In the future, `beta` and `stable` will also be available.
-
-### Alpha
-
-The alpha channel is the most recent release of Crossplane that is considered ready for testing by the community.
-
-```console
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-### Master
-
-The `master` channel contains the latest commits, with all automated tests passing.
-`master` is subject to instability, incompatibility, and features may be added or removed without much prior notice.
-It is recommended to use one of the more stable channels, but if you want the absolute newest Crossplane installed, then you can use the `master` channel.
-
-To install the Helm chart from master, you will need to pass the specific version returned by the `search` command:
-
-```console
-helm repo add crossplane-master https://charts.crossplane.io/master/
-helm search crossplane
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version
-```
-
-For example:
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version 0.0.0-249.637ccf9
-```
-
-## Installing Cloud Provider Stacks
-
-After Crossplane has been installed, you can add additional functionality to its control plane by installing Crossplane Stacks.
-For example, each supported cloud provider has its own corresponding stack that contains all the functionality for that particular cloud.
-After a cloud provider's stack is installed, you will be able to provision and manage resources within that cloud from Crossplane.
-
-### GCP Stack
-
-To get started with Google Cloud Platform (GCP), create a file named `stack-gcp.yaml` with the following content:
-
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
- name: gcp
----
-apiVersion: stacks.crossplane.io/v1alpha1
-kind: ClusterStackInstall
-metadata:
- name: stack-gcp
- namespace: gcp
-spec:
- package: "crossplane/stack-gcp:v0.1.0"
-```
-
-Then you can install the GCP stack into Crossplane in the `gcp` namespace with the following command:
-
-```console
-kubectl apply -f stack-gcp.yaml
-```
-
-### AWS Stack
-
-To get started with Amazon Web Services (AWS), create a file named `stack-aws.yaml` with the following content:
-
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
- name: aws
----
-apiVersion: stacks.crossplane.io/v1alpha1
-kind: ClusterStackInstall
-metadata:
- name: stack-aws
- namespace: aws
-spec:
- package: "crossplane/stack-aws:v0.1.0"
-```
-
-Then you can install the AWS stack into Crossplane in the `aws` namespace with the following command:
-
-```console
-kubectl apply -f stack-aws.yaml
-```
-
-### Azure Stack
-
-To get started with Microsoft Azure, create a file named `stack-azure.yaml` with the following content:
-
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
- name: azure
----
-apiVersion: stacks.crossplane.io/v1alpha1
-kind: ClusterStackInstall
-metadata:
- name: stack-azure
- namespace: azure
-spec:
- package: "crossplane/stack-azure:v0.1.0"
-```
-
-Then you can install the Azure stack into Crossplane in the `azure` namespace with the following command:
-
-```console
-kubectl apply -f stack-azure.yaml
-```
-
-### Uninstalling Cloud Provider Stacks
-
-The cloud provider stacks can be uninstalled simply by deleting the stack resources from the cluster with a command similar to what's shown below.
-**Note** that this will also **delete** any resources that Crossplane has provisioned in the cloud provider if their `ReclaimPolicy` is set to `Delete`.
-
-After you have ensured that you are completely done with all your cloud provider resources, you can then run one of the commands below,
-depending on which cloud provider you are removing, to remove its stack from Crossplane:
-
-#### Uninstalling GCP
-
-```console
-kubectl delete -f stack-gcp.yaml
-```
-
-#### Uninstalling AWS
-
-```console
-kubectl delete -f stack-aws.yaml
-```
-
-#### Uninstalling Azure
-
-```console
-kubectl delete -f stack-azure.yaml
-```
-
-## Uninstalling the Chart
-
-To uninstall/delete the `crossplane` deployment:
-
-```console
-helm delete --purge crossplane
-```
-
-That command removes all Kubernetes components associated with Crossplane, including all the custom resources and controllers.
-
-## Configuration
-
-The following tables lists the configurable parameters of the Crossplane chart and their default values.
-
-| Parameter | Description | Default |
-| ------------------------- | --------------------------------------------------------------- | ------------------------------------------------------ |
-| `image.repository` | Image | `crossplane/crossplane` |
-| `image.tag` | Image tag | `master` |
-| `image.pullPolicy` | Image pull policy | `Always` |
-| `imagePullSecrets` | Names of image pull secrets to use | `dockerhub` |
-| `replicas` | The number of replicas to run for the Crossplane operator | `1` |
-| `deploymentStrategy` | The deployment strategy for the Crossplane operator | `RollingUpdate` |
-
-### Command Line
-
-You can pass the settings with helm command line parameters.
-Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`.
-For example, the following command will install Crossplane with an image pull policy of `IfNotPresent`.
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane --set image.pullPolicy=IfNotPresent
-```
-
-### Settings File
-
-Alternatively, a yaml file that specifies the values for the above parameters (`values.yaml`) can be provided while installing the chart.
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane -f values.yaml
-```
-
-Here are the sample settings to get you started.
-
-```yaml
-replicas: 1
-
-deploymentStrategy: RollingUpdate
-
-image:
- repository: crossplane/crossplane
- tag: master
- pullPolicy: Always
-
-imagePullSecrets:
-- dockerhub
-```
diff --git a/docs/v0.3/learn-more.md b/docs/v0.3/learn-more.md
deleted file mode 100644
index c4f978b6..00000000
--- a/docs/v0.3/learn-more.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Learn More
-toc: true
-weight: 810
----
-# Learn More
-
-If you have any questions, please drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us]!
-
-***Learn more about using Crossplane***
- - [GitLab deploys into multiple clouds from kubectl using Crossplane](https://about.gitlab.com/2019/05/20/gitlab-first-deployed-kubernetes-api-to-multiple-clouds/)
- - [CNCF Talks & Community Presentations](https://www.youtube.com/playlist?list=PL510POnNVaaZJj9OG6PbgsZvgYbhwJRyE)
- - [Software Engineering Daily - Intro Podcast](https://softwareengineeringdaily.com/2019/01/02/crossplane-multicloud-control-plane-with-bassam-tabbara/)
- - [Crossplane Architecture](https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit?usp=sharing)
- - [Latest Design Docs](https://github.com/crossplaneio/crossplane/tree/master/design)
- - [Roadmap](https://github.com/crossplaneio/crossplane/blob/master/ROADMAP.md)
-
-***Writing Kubernetes controllers to extend Crossplane***
- - [Keep the Space Shuttle Flying: Writing Robust Operators](https://www.youtube.com/watch?v=uf97lOApOv8)
- - [Best practices for building Kubernetes Operators](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)
- - [Programming Kubernetes Book](https://www.oreilly.com/library/view/programming-kubernetes/9781492047094/)
- - [Crossplane Reconciler Patterns](https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-reconciler-patterns.md)
- - [Contributor Guide](https://github.com/crossplaneio/crossplane/blob/master/CONTRIBUTING.md)
-
-***Join the growing Crossplane community and get involved!***
-- Join our [Community Slack](https://slack.crossplane.io/)!
-- Submit an issue on [GitHub](https://github.com/crossplaneio/crossplane)
-- Attend our bi-weekly [Community Meeting](https://github.com/crossplaneio/crossplane#community-meeting)
-- Join our bi-weekly live stream: [The Binding Status](https://github.com/crossplaneio/tbs)
-- Subscribe to our [YouTube Channel](https://www.youtube.com/channel/UC19FgzMBMqBro361HbE46Fw)
-- Drop us a note on Twitter: [@crossplane_io](https://twitter.com/crossplane_io)
-- Email us: [info@crossplane.io](mailto:info@crossplane.io)
-
-
-[join-crossplane-slack]: https://slack.crossplane.io
-[contact-us]: https://github.com/crossplaneio/crossplane#contact
diff --git a/docs/v0.3/media/arch.png b/docs/v0.3/media/arch.png
deleted file mode 100644
index 8205e62e..00000000
Binary files a/docs/v0.3/media/arch.png and /dev/null differ
diff --git a/docs/v0.3/media/banner.png b/docs/v0.3/media/banner.png
deleted file mode 100644
index 0a495e1d..00000000
Binary files a/docs/v0.3/media/banner.png and /dev/null differ
diff --git a/docs/v0.3/media/crossplane-overview.png b/docs/v0.3/media/crossplane-overview.png
deleted file mode 100644
index 87c25a89..00000000
Binary files a/docs/v0.3/media/crossplane-overview.png and /dev/null differ
diff --git a/docs/v0.3/media/logo.svg b/docs/v0.3/media/logo.svg
deleted file mode 100644
index 3af90369..00000000
--- a/docs/v0.3/media/logo.svg
+++ /dev/null
@@ -1,310 +0,0 @@
-
-
-
diff --git a/docs/v0.3/postgresql.md b/docs/v0.3/postgresql.md
deleted file mode 100644
index 3964587d..00000000
--- a/docs/v0.3/postgresql.md
+++ /dev/null
@@ -1,133 +0,0 @@
-# Deploying PostgreSQL Databases
-
-This user guide will walk you through how to deploy a PostgreSQL database across many different environments with a focus on portability and reusability.
-The database will be dynamically provisioned in the cloud provider of your choice at the request of the application developer via a `ResourceClaim` and created with the environment specific information that the administrator providers in a `ResourceClass`.
-The commands in this guide assume you are running from a terminal/shell at the root of the [Crossplane repo](https://github.com/crossplaneio/crossplane/).
-
-## Install Crossplane
-
-The first step will be to install Crossplane and any desired cloud provider stacks by following the steps in the [Crossplane install guide](install-crossplane.md).
-
-## Add Cloud Provider
-
-Next you'll need to add your cloud provider credentials to Crossplane using [these provider specific steps](cloud-providers.md).
-
-After those steps are completed, you should have the cloud provider credentials saved in a file on your local filesystem, for which the path will be stored in the environment variable `PROVIDER_KEY_FILE` in the next section.
-
-## Set Environment Variables
-
-After your cloud provider credentials have been created/added, let's set the following environment variables that have different values for each provider,
-but will allow the rest of the steps to be consistent across all of them.
-You only need to set the variables for your chosen cloud provider, you can ignore the other ones.
-
-### Google Cloud Platform (GCP)
-
-```console
-export PROVIDER=GCP
-export provider=gcp
-export PROVIDER_KEY_FILE=crossplane-${provider}-provider-key.json
-export DATABASE_TYPE=cloudsqlinstances
-export versionfield=databaseVersion
-```
-
-### Microsoft Azure
-
-```console
-export PROVIDER=AZURE
-export provider=azure
-export PROVIDER_KEY_FILE=crossplane-${provider}-provider-key.json
-export DATABASE_TYPE=postgresqlservers
-export versionfield=version
-```
-
-### Amazon Web Services (AWS)
-
-```console
-export PROVIDER=AWS
-export provider=aws
-export PROVIDER_KEY_FILE=~/.aws/credentials
-export DATABASE_TYPE=rdsinstances
-export versionfield=engineVersion
-```
-
-## Create a PostgreSQL Resource Class
-
-Let's create a `ResourceClass` that acts as a "blueprint" that contains the environment specific details of how a general request from the application to create a PostgreSQL database should be fulfilled.
-This is a task that the administrator should complete, since they will have the knowledge and privileges for the specific environment details.
-
-```console
-sed "s/BASE64ENCODED_${PROVIDER}_PROVIDER_CREDS/`base64 ${PROVIDER_KEY_FILE} | tr -d '\n'`/g;" cluster/examples/database/${provider}/postgresql/provider.yaml | kubectl create -f -
-kubectl create -f cluster/examples/database/${provider}/postgresql/resource-class.yaml
-```
-
-## Create a PostgreSQL Resource Claim
-
-After the administrator has created the PostgreSQL `ResourceClass` "blueprint", the application developer is now free to create a PostgreSQL `ResourceClaim`.
-This is a general request for a PostgreSQL database to be used by their application and it requires no environment specific information, allowing our applications to express their need for a database in a very portable way.
-
-```console
-kubectl create namespace demo
-kubectl -n demo create -f cluster/examples/database/${provider}/postgresql/resource-claim.yaml
-```
-
-## Check Status of PostgreSQL Provisioning
-
-We can follow along with the status of the provisioning of the database resource with the below commands.
-Note that the first command gives us the status of the `ResourceClaim` (general request for a database by the application),
-and the second command gives the status of the environment specific database resource that Crossplane is provisioning using the `ResourceClass` "blueprint".
-
-```console
-kubectl -n demo get postgresqlinstance -o custom-columns=NAME:.metadata.name,STATUS:.status.bindingPhase,CLASS:.spec.classRef.name,VERSION:.spec.engineVersion,AGE:.metadata.creationTimestamp
-kubectl -n crossplane-system get ${DATABASE_TYPE} -o custom-columns=NAME:.metadata.name,STATUS:.status.bindingPhase,STATE:.status.state,CLASS:.spec.classRef.name,VERSION:.spec.${versionfield},AGE:.metadata.creationTimestamp
-```
-
-## Access the PostgreSQL Database
-
-Once the dynamic provisioning process has finished creating and preparing the database, the status output will look similar to the following:
-
-```console
-> kubectl -n demo get postgresqlinstance -o custom-columns=NAME:.metadata.name,STATUS:.status.bindingPhase,CLASS:.spec.classRef.name,VERSION:.spec.engineVersion,AGE:.metadata.creationTimestamp
-NAME STATUS CLASS VERSION AGE
-cloud-postgresql-claim Bound cloud-postgresql 9.6 2018-12-23T04:00:11Z
-
-> kubectl -n crossplane-system get ${DATABASE_TYPE} -o custom-columns=NAME:.metadata.name,STATUS:.status.bindingPhase,STATE:.status.state,CLASS:.spec.classRef.name,VERSION:.spec.${versionfield},AGE:.metadata.creationTimestamp
-NAME STATUS STATE CLASS VERSION AGE
-postgresql-3ef70bf9-0667-11e9-99e1-080027cf2340 Bound Ready cloud-postgresql 9.6 2018-12-23T04:00:12Z
-```
-
-Note that both the general `postgresqlinstance` `ResourceClaim` and the cloud provider specific PostgreSQL database have the `Bound` status, meaning the dynamic provisioning is done and the resource is ready for consumption.
-
-The connection information will be stored in a secret specified via the `writeConnectionSecretTo` field.
-Since the secret is base64 encoded, we'll need to decode its fields to view them in plain-text.
-To view all the connection information in plain-text, run the following command:
-
-```console
-for r in endpoint username password; do echo -n "${r}: "; kubectl -n demo get secret cloud-postgresql-claim -o jsonpath='{.data.'"${r}"'}' | base64 -D; echo; done
-```
-
-A workload or pod manifest will usually reference this connection information through injecting the secret contents into environment variables in the manifest.
-You can see this in action as an example in the [Azure Workload example](https://github.com/crossplaneio/crossplane/blob/release-0.1/cluster/examples/workloads/wordpress-azure/workload.yaml#L47-L62).
-
-More information about consuming secrets from manifests can be found in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/secret/#use-cases).
-
-## Clean-up
-
-When you are finished with the PostgreSQL instance from this guide, you can clean up all the resources by running the below commands.
-
-First, delete the resource claim, which will start the operation of deleting the PostgreSQL database from your cloud provider.
-
-```console
-kubectl -n demo delete -f cluster/examples/database/${provider}/postgresql/resource-claim.yaml
-```
-
-Next. delete the `ResourceClass` "blueprint":
-
-```console
-kubectl delete -f cluster/examples/database/${provider}/postgresql/resource-class.yaml
-```
-
-Finally, delete the cloud provider credentials from your local environment:
-
-```console
-kubectl delete -f cluster/examples/database/${provider}/postgresql/provider.yaml
-```
diff --git a/docs/v0.3/quick-start-gcp.md b/docs/v0.3/quick-start-gcp.md
deleted file mode 100644
index bf570188..00000000
--- a/docs/v0.3/quick-start-gcp.md
+++ /dev/null
@@ -1,185 +0,0 @@
----
-title: Provision a MySQL Database on GCP
-toc: true
-weight: 240
-indent: true
----
-# Provisioning a MySQL Database on GCP
-
-Now that Crossplane and the GCP stack are installed in your Kubernetes cluster,
-and your GCP account credentials have been configured in
-`crossplane-gcp-provider-key.json`, a MySQL database can easily be provisioned
-on GCP.
-
-## Namespaces
-
-Namespaces allow for logical grouping of resources in Kubernetes. For this
-example, create one for GCP-specific infrastructure resources, and one for
-portable application resources:
-
-```bash
-kubectl create namespace gcp-infra-dev
-kubectl create namespace app-project1-dev
-```
-
-## Provider
-
-The `Provider` and `Secret` resources work together to store your GCP account
-credentials in Kubernetes. Because these resources are GCP-specific, create them
-in the `gcp-infra-dev` namespace. You will need to set the
-`$BASE64ENCODED_GCP_PROVIDER_CREDS` and `$PROJECT_ID` variables before creating:
-
-```bash
-export PROJECT_ID=[your-demo-project-id]
-export BASE64ENCODED_GCP_PROVIDER_CREDS=$(base64 crossplane-gcp-provider-key.json | tr -d "\n")
-```
-
-```bash
-cat > provider.yaml < cloudsql.yaml < mysql-class.yaml < mysql-claim.yaml <
-
-
-[console]: https://console.cloud.google.com
diff --git a/docs/v0.3/quick-start.md b/docs/v0.3/quick-start.md
deleted file mode 100644
index 492168c7..00000000
--- a/docs/v0.3/quick-start.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: Getting Started
-toc: true
-weight: 210
----
-# Quick Start Guide
-
-This quick start will demonstrate using Crossplane to deploy a portable MySQL
-database on a single cloud provider, Google Cloud Platform. It serves as an initial introduction to
-Crossplane, but only displays a small portion of its functionality.
-
-The general steps for this example are as follows:
-
-1. [Install Crossplane and the GCP stack](install-crossplane.md) into your Kubernetes cluster.
-1. [Configure GCP credentials](cloud-providers/gcp/gcp-provider.md) in Crossplane.
-1. [Provision a MySQL database](quick-start-gcp.md) on GCP.
-
-## Next Steps
-
-* Add additional [cloud provider stacks](cloud-providers.md) to Crossplane.
-* Explore the [Services Guide](services-guide.md) and the [Stacks Guide](stacks-guide.md).
-* Learn more about [Crossplane concepts](concepts.md).
-* See what services are [currently supported](api.md) for each provider.
-* Build [your own stacks](developer-guide.md)!
diff --git a/docs/v0.3/related-projects.md b/docs/v0.3/related-projects.md
deleted file mode 100644
index 33974f49..00000000
--- a/docs/v0.3/related-projects.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Related Projects
-toc: true
-weight: 850
-indent: true
----
-# Related Projects
-
-While there are many projects that address similar issues, none of them encapsulate the full use case that Crossplane addresses. This list is not exhaustive and is not meant to provide a deep analysis of the following projects, but instead to motivate why Crossplane was created.
-
-## Open Service Broker and Service Catalog
-
-The [Open Service Broker](https://www.openservicebrokerapi.org/) and the [Kubernetes Service Catalog](https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/) are able to dynamically provision managed services in multiple cloud providers from Kubernetes. As a result it shares similar goals with Crossplane. However, service broker is not designed for workload portability, does not have a good separation of concern, and does not offer any integration with workload and resource scheduling. Service brokers can not span multiple cloud providers at once.
-
-## Kubernetes Federation
-
-The [federation-v2](https://github.com/kubernetes-sigs/federation-v2) project offers a single control plane that can span multiple Kubernetes clusters. It’s being incubated in SIG-multicluster. Crossplane shares some of the goals of managing multiple Kubernetes clusters and also the core principles of creating a higher level control plane, scheduler and controllers that span clusters. While the federation-v2 project is scoped to just Kubernetes clusters, Crossplane supports non-container workloads, and orchestrating resources that run as managed services including databases, message queues, buckets, and others. The federation effort focuses on defining Kubernetes objects that can be templatized, and propagated to other Kubernetes clusters. Crossplane focuses on defining portable workload abstractions across cloud providers and offerings. We have considered taking a dependency on the federation-v2 work within Crossplane, although it’s not clear at this point if this would accelerate the Crossplane effort.
-
-## AWS Service Operator
-
-The [AWS Service Operator](https://github.com/awslabs/aws-service-operator) is a recent project that implements a set of Kubernetes controllers that are able to provision managed services in AWS. It defines a set of CRDs for managed services like DynamoDB, and controllers that can provision them via AWS CloudFormation. It is similar to Crossplane in that it can provision managed services in AWS. Crossplane goes a lot further by offering workload portability across cloud multiple cloud providers, separation of concern, and a scheduler for workload and resources.
-
-## AWS CloudFormation, GCP Deployment Manager, and Others
-
-These products offer a declarative model for deploying and provisioning infrastructure in each of the respective cloud providers. They only work for one cloud provider and do not solve the problem of workload portability. These products are generally closed source, and offer little or no extensibility points. We have considered using some of these products as a way to implement resource controllers in Crossplane.
-
-## Terraform
-
-[Terraform](https://www.terraform.io/) is a popular tool for provisioning infrastructure across cloud providers. It offers a declarative configuration language with support for templating, composability, referential integrity and dependency management. Terraform can dynamically provision infrastructure and perform changes when the tool is run by a human. Unlike Crossplane, Terraform does not support workload portability across cloud providers, and does not have any active controllers that can react to failures, or make changes to running infrastructure without human intervention. Terraform attempts to solve multicloud at the tool level, while Crossplane is at the API and control plane level. Terraform is open source under a MPL license, and follows an open core business model, with a number of its features closed source. We are evaluating whether we can use Terraform to accelerate the development of resource controllers in Crossplane.
-
-## Pulumi
-
-[Pulumi](https://www.pulumi.com/) is a product that is based on terraform and uses most of its providers. Instead of using a configuration language, Pulumi uses popular programming languages like Typescript to capture the configuration. At runtime, Pulumi generates a DAG of resources just like terraform and applies it to cloud providers. Pulumi has an early model for workload portability that is implemented using language abstractions. Unlike Crossplane, it does not have any active controllers that can react to failures, or make changes to running infrastructure without human intervention, nor does it support workload scheduling. Pulumi attempts to solve multicloud scenarios at the language level, while Crossplane is at the API and control plane level. Pulumi is open source under a APL2 license but a number of features require using their SaaS offering.
diff --git a/docs/v0.3/services-developer-guide.md b/docs/v0.3/services-developer-guide.md
deleted file mode 100644
index 8d7ce975..00000000
--- a/docs/v0.3/services-developer-guide.md
+++ /dev/null
@@ -1,1049 +0,0 @@
----
-title: Services Developer Guide
-toc: true
-weight: 720
-indent: true
----
-# Services Developer Guide
-
-Crossplane Services supports managed service provisioning using `kubectl`. It
-applies the Kubernetes pattern for Persistent Volume (PV) claims and classes to
-managed service provisioning with support for a strong separation of concern
-between app teams and cluster administrators. This guide will walk through the
-process of adding support for a new managed service.
-
-## What Makes a Crossplane Managed Service?
-
-Crossplane builds atop Kubernetes's powerful architecture in which declarative
-configuration, known as resources, are continually 'reconciled' with reality by
-one or more controllers. A controller is an endless loop that:
-
-1. Observes the desired state (the declarative configuration resource).
-1. Observes the actual state (the thing said configuration resource represents).
-1. Tries to make the actual state match the desired state.
-
-A typical Crossplane managed service consists of five configuration resources
-and three controllers. The GCP Stack's support for Google Cloud Memorystore
-illustrates this. First, the configuration resources:
-
-1. A [managed resource]. Managed resources are high-fidelity representations of
- a resource in an external system such as a cloud provider's API. Managed
- resources are _non-portable_ across external systems (i.e. cloud providers);
- they're tightly coupled to the implementation details of the external
- resource they represent. Managed resources are defined by a Stack. The GCP
- Stack's [`CloudMemorystoreInstance`] resource is an example of a managed
- resource.
-1. A [resource claim]. Resource claims are abstract declarations of a need for a
- service. Resource claims are frequently portable across external systems.
- Crossplane defines a series of common resource claim kinds, including
- [`RedisCluster`]. A resource claim is satisfied by _binding_ to a managed
- resource.
-1. A non-portable [resource class]. Non-portable resource classes represent a
- class of a specific kind of managed resource. They are the template used to
- create a new managed resource in order to satisfy a resource claim during
- [dynamic provisioning]. Non-portable resource classes are tightly coupled to
- the managed resources they template. [`CloudMemorystoreInstanceClass`] is an
- example of a non-portable resource class.
-1. A portable [resource class]. Portable resource classes are a pointer from a
- resource claim to a non-portable resource class that should be used for
- dynamic provisioning. [`RedisClusterClass`] is an example of a portable
- resource claim.
-1. A provider. Providers enable access to an external system, typically by
- indicating a Kubernetes Secret containing any credentials required to
- authenticate to the system, as well as any other metadata required to
- connect. The GCP [`Provider`] is an example of a provider.
-
-These resources are powered by:
-
-1. The managed resource controller. This controller is responsible for taking
- instances of the aforementioned high-fidelity managed resource kind and
- reconciling them with an external system. Managed resource controllers are
- unaware of resource claims or classes. The `CloudMemorystoreInstance`
- controller watches for changes to `CloudMemorystoreInstance` resources and
- calls Google's Cloud Memorystore API to create, update, or delete an instance
- as necessary.
-1. The resource claim controller. A resource claim controller exists for each
- kind of managed resource that could satisfy a resource claim. This controller
- is unaware of any external system - it responsible only for taking resource
- claims and binding them to a managed resource. The
- `CloudMemorystoreInstance` resource claim controller watches for
- `RedisCluster` resource claims that should be satisfied by a
- `CloudMemorystoreInstance`. It either binds to an explicitly referenced
- `CloudMemorystoreInstance` (static provisioning) or creates a new one and
- then binds to it (dynamic provisioning).
-1. A default resource class controller. The `RedisCluster` default resource
- class controller watches for `RedisCluster` instances that don't explicitly
- reference a managed resource _or_ a portable resource class, and sets a
- default resource class if one is set. Only one instance of this defaulting
- controller exists per resource claim kind.
-
-Crossplane does not require controllers to be written in any particular
-language. The Kubernetes API server is our API boundary, so any process capable
-of [watching the API server] and updating resources can be a Crossplane
-controller.
-
-## Getting Started
-
-At the time of writing all Crossplane Services controllers are written in Go,
-and built using [kubebuilder] v0.2.x and [crossplane-runtime]. Per [What Makes
-a Crossplane Managed Service] it is possible to write a controller using any
-language and tooling with a Kubernetes client, but this set of tools are the
-"[golden path]". They're well supported, broadly used, and provide a shared
-language with the Crossplane maintainers.
-
-This guide assumes the reader is familiar with the Kubernetes [API Conventions]
-and the [kubebuilder book]. If you're not adding a new managed service to an
-existing Crossplane Stack you should start by working through the [Stacks quick
-start] to scaffold a new Stack in which the new types and controllers will live.
-
-## Defining Resource Kinds
-
-Let's assume we want to add Crossplane support for your favourite cloud's
-database-as-a-service. Your favourite cloud brands these instances as "Favourite
-DB instances". Under the hood they're powered by the open source FancySQL
-engine. We'll name the new managed resource kind `FavouriteDBInstance` and the
-new resource claim `FancySQLInstance`.
-
-The first step toward implementing a new managed service is to define the code
-level schema of its configuration resources. These are referred to as
-[resources], (resource) [kinds], and [objects] interchangeably. The kubebuilder
-scaffolding is a good starting point for any new Crossplane API kind, whether
-they'll be a managed resource, resource class, or resource claim:
-
-```shell
-# The resource claim.
-kubebuilder create api \
- --group example --version v1alpha1 --kind FancySQLInstance \
- --resource=true --controller=false
-```
-
-The above command should produce a scaffold similar to the below
-example:
-
-```go
-type FancySQLInstanceSpec struct {
- // INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
- // Important: Run "make" to regenerate code after modifying this file
-}
-
-// FancySQLInstanceStatus defines the observed state of FancySQLInstance
-type FancySQLInstanceStatus struct {
- // INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
- // Important: Run "make" to regenerate code after modifying this file
-}
-
-// +kubebuilder:object:root=true
-
-// FancySQLInstance is the Schema for the fancysqlinstances API
-type FancySQLInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FancySQLInstanceSpec `json:"spec,omitempty"`
- Status FancySQLInstanceStatus `json:"status,omitempty"`
-}
-```
-
-Crossplane requires that these newly generated API type scaffolds be extended
-with a set of struct fields, getters, and setters that are standard to all
-Crossplane resource kinds. The fields and setters differ depending on whether
-the new resource kind is a managed resource, resource claim, or resource class.
-
-Note that in many cases a suitable provider, resource claim, and portable
-resource class will already exist. Frequently adding support for a new managed
-service requires only the definition of a new managed resource and non-portable
-resource class.
-
-### Managed Resource Kinds
-
-Managed resources must:
-
-* Satisfy crossplane-runtime's [`resource.Managed`] interface.
-* Embed a [`ResourceStatus`] struct in their `Status` struct.
-* Embed a [`ResourceSpec`] struct in their `Spec` struct.
-* Embed a `Parameters` struct in their `Spec` struct.
-* Use the `+kubebuilder:subresource:status` [comment marker].
-
-The `Parameters` struct should be a _high fidelity_ representation of the
-writable fields of the external resource's API. Put otherwise, if your favourite
-cloud represents Favourite DB instances as a JSON object then
-`FavouriteDBParameters` should marshal to a something as close to that JSON
-object as possible while still complying with Kubernetes API conventions.
-
-For example, assume the external API object for Favourite DB instance was:
-
-```json
-{
- "id": 42,
- "name": "mycoolinstance",
- "fanciness_level": 100,
- "version": "2.3",
- "status": "ONLINE",
- "hostname": "cool.fcp.example.org"
-}
-```
-
-Further assume the `id`, `status`, and `hostname` fields were output only, and
-the `version` field was optional. The `FavouriteDBInstance` managed resource
-should look as follows:
-
-```go
-// FavouriteDBInstanceParameters define the desired state of an FavouriteDB
-// instance. Most fields map directly to an Instance:
-// https://favourite.example.org/api/v1/db#Instance
-type FavouriteDBInstanceParameters struct {
-
- // We're still working on a standard for naming external resources. See
- // https://github.com/crossplaneio/crossplane/issues/624 for context.
-
- // Name of this instance.
- Name string `json:"name"`
-
- // Note that fanciness_level becomes fancinessLevel below. Kubernetes API
- // conventions trump cloud provider fidelity.
-
- // FancinessLevel specifies exactly how fancy this instance is.
- FancinessLevel int `json:"fancinessLevel"`
-
- // Version specifies what version of FancySQL this instance will run.
- // +optional
- Version *string `json:"version,omitempty"`
-}
-
-// A FavouriteDBInstanceSpec defines the desired state of a FavouriteDBInstance.
-type FavouriteDBInstanceSpec struct {
- runtimev1alpha1.ResourceSpec `json:",inline"`
- FavouriteDBInstanceParameters `json:",inline"`
-}
-
-// A FavouriteDBInstanceStatus represents the observed state of a
-// FavouriteDBInstance.
-type FavouriteDBInstanceStatus struct {
- runtimev1alpha1.ResourceStatus `json:",inline"`
-
- // Note that we add the three "output only" fields here in the status,
- // instead of the parameters. We want this representation to be high
- // fidelity just like the parameters.
-
- // ID of this instance.
- ID int `json:"id,omitempty"`
-
- // Status of this instance.
- Status string `json:"status,omitempty"`
-
- // Hostname of this instance.
- Hostname string `json:"hostname,omitempty"`
-}
-
-// +kubebuilder:object:root=true
-
-// A FavouriteDBInstance is a managed resource that represents a Favourite DB
-// instance.
-// +kubebuilder:subresource:status
-type FavouriteDBInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FavouriteDBInstanceSpec `json:"spec,omitempty"`
- Status FavouriteDBInstanceStatus `json:"status,omitempty"`
-}
-
-
-// SetBindingPhase of this FavouriteDBInstance.
-func (i *FavouriteDBInstance) SetBindingPhase(p runtimev1alpha1.BindingPhase) {
- i.Status.SetBindingPhase(p)
-}
-
-// This example omits several getters and setters that are required to satisfy
-// the resource.Managed interface in the interest of brevity. These methods all
-// set or get a field of one of the embedded structs, similar to SetBindingPhase
-// above.
-```
-
-Note that Crossplane uses the GoDoc strings of API kinds to generate user facing
-API documentation. __Document all fields__ and prefer GoDoc that assumes the
-reader is running `kubectl explain`, or reading an API reference, not reading
-the code.
-
-### Non-Portable Class Kinds
-
-The non-portable resource class kind for a particular managed resource kind are
-typically defined in the same file as their the managed resource. Non-portable
-resource classes must:
-
-* Satisfy crossplane-runtime's [`resource.NonPortableClass`] interface.
-* Have a `SpecTemplate` struct field instead of a `Spec`.
-* Embed a [`NonPortableClassSpecTemplate`] struct in their `SpecTemplate`
- struct.
-* Embed their managed resource's `Parameters` struct in their `SpecTemplate`
- struct.
-* Not have a `Status` struct.
-
-A non-portable resource class for the above `FavouriteDBInstance` would look as
-follows:
-
-```go
-// A FavouriteDBInstanceClassSpecTemplate is a template for the spec of a
-// dynamically provisioned FavouriteDBInstance.
-type FavouriteDBInstanceClassSpecTemplate struct {
- runtimev1alpha1.NonPortableClassSpecTemplate `json:",inline"`
- FavouriteDBInstanceParameters `json:",inline"`
-}
-
-// +kubebuilder:object:root=true
-
-// A FavouriteDBInstanceClass is a non-portable resource class. It defines the
-// desired spec of resource claims that use it to dynamically provision a
-// managed resource.
-type FavouriteDBInstanceClass struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- // SpecTemplate is a template for the spec of a dynamically provisioned
- // FavouriteDBInstance.
- SpecTemplate FavouriteDBInstanceSpecTemplate `json:"specTemplate,omitempty"`
-}
-
-// This example omits getters and setters that are required to satisfy the
-// resource.NonPortableClass interface in the interest of brevity. These methods
-// all set or get a field of one of the embedded structs.
-```
-
-### Resource Claim Kinds
-
-Once the underlying managed resource and its non-portable resource class have
-been defined the next step is to define the resource claim. Resource claim
-controllers typically live alongside their managed resource controllers (i.e. in
-an infrastructure stack), but at the time of writing all resource claim kinds
-are defined in Crossplane core. This is because resource claims can frequently
-be satisfied by binding to managed resources from more than one cloud. Consider
-[opening a Crossplane issue] to propose adding your new resource claim kind to
-Crossplane if it could be satsified by managed resources from more than one
-infrastructure stack.
-
-Resource claims must:
-
-* Satisfy crossplane-runtime's [`resource.Claim`] interface.
-* Use (not embed) a [`ResourceClaimStatus`] struct as their `Status` field.
-* Embed a [`ResourceClaimSpec`] struct in their `Spec` struct.
-* Use the `+kubebuilder:subresource:status` [comment marker].
-
-The `FancySQLInstance` resource claim would look as follows:
-
-```go
-// A FancySQLInstanceSpec defines the desired state of a FancySQLInstance.
-type FancySQLInstanceSpec struct {
- runtimev1alpha1.ResourceClaimSpec `json:",inline"`
-
- // Resource claims typically expose few to no spec fields, instead
- // leveraging resource classes to specify detailed configuration. A resource
- // claim should only support a very small set of fields that:
- //
- // * Are applicable to every conceivable managed resource kind that might
- // ever satisfy the claim kind.
- // * Are more likely than average to be interesting to resource claim
- // authors, who frequently want to be concerned with as few configuration
- // details as possible.
-
- // Version specifies what version of FancySQL this instance will run.
- // +optional
- Version *string `json:"version,omitempty"`
-}
-
-// +kubebuilder:object:root=true
-
-// A FancySQLInstance is a portable resource claim that may be satisfied by
-// binding to FancySQL managed resources such as a Favourite Cloud FavouriteDB
-// instance or an Other Cloud AmbivalentDB instance.
-// +kubebuilder:subresource:status
-type FancySQLInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FancySQLInstanceSpec `json:"spec,omitempty"`
- Status runtimev1alpha1.ResourceClaimStatus `json:"status,omitempty"`
-}
-
-// SetBindingPhase of this FancySQLInstance.
-func (i *FancySQLInstance) SetBindingPhase(p runtimev1alpha1.BindingPhase) {
- i.Status.SetBindingPhase(p)
-}
-
-// This example omits several getters and setters that are required to satisfy
-// the resource.Claim interface in the interest of brevity. These methods all
-// set or get a field of one of the embedded structs, similar to SetBindingPhase
-// above.
-```
-
-### Portable Resource Class Kinds
-
-Portable resource classes are typically defined alongside the resource claim
-they align with, similar to how non-portable resource classes are defined
-alongside the managed resources they align with.
-
-Portable resource classes must:
-
-* Satisfy crossplane-runtime's [`resource.PortableClass`] interface.
-* Directly embed a [`PortableClass`] struct.
-* Have no `Spec` field.
-* Have no `Status` field.
-* Have a corresponding List type that sastisfies the
- [`resource.PortableClassList`] interface.
-
-The `FancySQLInstanceClass` portable resource class would look as follows:
-
-```go
-// FancySQLInstanceClass contains a namespace-scoped portable class for
-// FancySQLInstance
-type FancySQLInstanceClass struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- runtimev1alpha1.PortableClass `json:",inline"`
-}
-
-// +kubebuilder:object:root=true
-
-// FancySQLInstanceClassList contains a list of FancySQLInstanceClass.
-type FancySQLInstanceClassList struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ListMeta `json:"metadata,omitempty"`
-
- Items []FancySQLInstanceClass `json:"items"`
-}
-
-// SetPortableClassItems of this FancySQLInstanceClassList.
-func (rc *FancySQLInstanceClassList) SetPortableClassItems(r []resource.PortableClass) {
- items := make([]FancySQLInstanceClass, 0, len(r))
- for i := range r {
- if item, ok := r[i].(*FancySQLInstanceClass); ok {
- items = append(items, *item)
- }
- }
- rc.Items = items
-}
-
-// GetPortableClassItems of this FancySQLInstanceClassList.
-func (rc *FancySQLInstanceClassList) GetPortableClassItems() []resource.PortableClass {
- items := make([]resource.PortableClass, len(rc.Items))
- for i, item := range rc.Items {
- item := item
- items[i] = resource.PortableClass(&item)
- }
- return items
-}
-```
-
-### Provider Kinds
-
-You'll typically only need to add a new Provider kind if you're creating an
-infrastructure stack that adds support for a new infrastructure provider.
-
-Providers must:
-
-* Be named exactly `Provider`.
-* Have a `Spec` struct with a `Secret` field indicating where to find
- credentials for this provider.
-
-The Favourite Cloud `Provider` would look as follows. Note that the cloud to
-which it belongs should be indicated by its API group, i.e. its API Version
-would be `favouritecloud.crossplane.io/v1alpha1` or similar.
-
-```go
-// A ProviderSpec defines the desired state of a Provider.
-type ProviderSpec struct {
-
- // A Secret containing credentials for a Favourite Cloud Service Account
- // that will be used to authenticate to this Provider.
- Secret corev1.SecretKeySelector `json:"credentialsSecretRef"`
-}
-
-// +kubebuilder:object:root=true
-
-// A Provider configures a Favourite Cloud 'provider', i.e. a connection to a
-// particular Favourite Cloud project using a particular Favourite Cloud service
-// account.
-type Provider struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec ProviderSpec `json:"spec,omitempty"`
-}
-```
-
-### Finishing Touches
-
-At this point we've defined all of the resource kinds necessary to start
-building controllers - a managed resource, a non-portable resource class, a
-resource claim, and a portable resource class. Before moving on to the
-controllers:
-
-* Add any kubebuilder [comment markers] that may be useful for your resource.
- Comment markers can be used to validate input, or add additional columns to
- the standard `kubectl get` output, among other things.
-* Run `make generate && make manifests` (or `make reviewable` if you're working
- in one of the projects in the [crossplaneio org]) to generate Custom Resource
- Definitions and additional helper methods for your new resource kinds.
-* Make sure any package documentation (i.e. `// Package v1alpha1...` GoDoc,
- including package level comment markers) are in a file named `doc.go`.
- kubebuilder adds them to `groupversion_info.go`, but several code generation
- tools only check `doc.go`.
-
-Finally, add convenience [`GroupVersionKind`] variables for each new resource
-kind. These are typically added to either `register.go` or
-`groupversion_info.go` depending on which version of kubebuilder scaffolded the
-API type:
-
-```go
-// FancySQLInstance type metadata.
-var (
- FancySQLInstanceKind = reflect.TypeOf(FancySQLInstance{}).Name()
- FancySQLInstanceKindAPIVersion = FancySQLInstanceKind + "." + GroupVersion.String()
- FancySQLInstanceGroupVersionKind = GroupVersion.WithKind(FancySQLInstanceKind)
-)
-```
-
-Consider opening a draft pull request and asking a Crossplane maintainer for
-review before you start work on the controller!
-
-## Adding Controllers
-
-Crossplane controllers, like those scaffolded by kubebuilder, are built around
-the [controller-runtime] library. controller-runtime flavoured controllers
-encapsulate most of their domain-specific logic in a [`reconcile.Reconciler`]
-implementation. Most Crossplane controllers are one of the three kinds mentioned
-under [What Makes a Crossplane Managed Service]. Each of these controller kinds
-are similar enough across implementations that [crossplane-runtime] provides
-'default' reconcilers. These reconcilers encode what the Crossplane community
-has learned about managing external systems and narrow the problem space from
-reconciling a Kubernetes resource kind with an arbitrary system down to
-Crossplane-specific tasks.
-
-crossplane-runtime provides the following `reconcile.Reconcilers`:
-
-* The [`resource.ManagedReconciler`] reconciles managed resources with external
- systems by instantiating a client of the external API and using it to create,
- update, or delete the external resource as necessary.
-* [`resource.ClaimReconciler`] reconciles resource claims with managed resources
- by either binding or dynamically provisioning and then binding them.
-* [`resource.DefaultClassReconciler`] sets default resource classes for resource
- claims that need them.
-
-Crossplane controllers typically differ sufficiently from those scaffolded by
-kubebuilder that there is little value in using kubebuilder to generate a
-controller scaffold.
-
-### Managed Resource Controllers
-
-Managed resource controllers should use [`resource.NewManagedReconciler`] to
-wrap a managed-resource specific implementation of
-[`resource.ExternalConnecter`]. Parts of `resource.ManagedReconciler`'s
-behaviour is customisable; refer to the [`resource.NewManagedReconciler`] GoDoc
-for a list of options. The following is an example controller for the
-`FavouriteDBInstance` managed resource we defined earlier:
-
-```go
-import (
- "context"
- "fmt"
- "strings"
-
- "github.com/pkg/errors"
- corev1 "k8s.io/api/core/v1"
- "k8s.io/apimachinery/pkg/types"
- ctrl "sigs.k8s.io/controller-runtime"
- "sigs.k8s.io/controller-runtime/pkg/client"
-
- // An API client of the hypothetical FavouriteDB service.
- "github.com/fcp-sdk/v1/services/database"
-
- runtimev1alpha1 "github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1"
- "github.com/crossplaneio/crossplane-runtime/pkg/meta"
- "github.com/crossplaneio/crossplane-runtime/pkg/resource"
-
- "github.com/crossplaneio/stack-fcp/apis/database/v1alpha2"
- fcpv1alpha2 "github.com/crossplaneio/stack-fcp/apis/v1alpha2"
-)
-
-type FavouriteDBInstanceController struct{}
-
-// SetupWithManager instantiates a new controller using a resource.ManagedReconciler
-// configured to reconcile FavouriteDBInstances using an ExternalClient produced by
-// connecter, which satisfies the ExternalConnecter interface.
-func (c *FavouriteDBInstanceController) SetupWithManager(mgr ctrl.Manager) error {
- return ctrl.NewControllerManagedBy(mgr).
- Named(strings.ToLower(fmt.Sprintf("%s.%s", v1alpha2.FavouriteDBInstanceKind, v1alpha2.Group))).
- For(&v1alpha2.FavouriteDBInstance{}).
- Complete(resource.NewManagedReconciler(mgr,
- resource.ManagedKind(v1alpha2.FavouriteDBInstanceGroupVersionKind),
- resource.WithExternalConnecter(&connecter{client: mgr.GetClient()})))
-}
-
-// Connecter satisfies the resource.ExternalConnecter interface.
-type connecter struct{ client client.Client }
-
-// Connect to the supplied resource.Managed (presumed to be a
-// FavouriteDBInstance) by using the Provider it references to create a new
-// database client.
-func (c *connecter) Connect(ctx context.Context, mg resource.Managed) (resource.ExternalClient, error) {
- // Assert that resource.Managed we were passed in fact contains a
- // FavouriteDBInstance. We told NewControllerManagedBy that this was a
- // controller For FavouriteDBInstance, so something would have to go
- // horribly wrong for us to encounter another type.
- i, ok := mg.(*v1alpha2.FavouriteDBInstance)
- if !ok {
- return nil, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Get the Provider referenced by the FavouriteDBInstance.
- p := &fcpv1alpha2.Provider{}
- if err := c.client.Get(ctx, meta.NamespacedNameOf(i.Spec.ProviderReference), p); err != nil {
- return nil, errors.Wrap(err, "cannot get Provider")
- }
-
- // Get the Secret referenced by the Provider.
- s := &corev1.Secret{}
- n := types.NamespacedName{Namespace: p.Namespace, Name: p.Spec.Secret.Name}
- if err := c.client.Get(ctx, n, s); err != nil {
- return nil, errors.Wrap(err, "cannot get Provider secret")
- }
-
- // Create and return a new database client using the credentials read from
- // our Provider's Secret.
- client, err := database.NewClient(ctx, s.Data[p.Spec.Secret.Key])
- return &external{client: client}, errors.Wrap(err, "cannot create client")
-}
-
-// External satisfies the resource.ExternalClient interface.
-type external struct{ client database.Client }
-
-// Observe the existing external resource, if any. The resource.ManagedReconciler
-// calls Observe in order to determine whether an external resource needs to be
-// created, updated, or deleted.
-func (e *external) Observe(ctx context.Context, mg resource.Managed) (resource.ExternalObservation, error) {
- i, ok := mg.(*v1alpha2.FavouriteDBInstance)
- if !ok {
- return resource.ExternalObservation{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Use our FavouriteDB API client to get an up to date view of the external
- // resource.
- existing, err := e.client.GetInstance(ctx, i.Spec.Name)
-
- // If we encounter an error indicating the external resource does not exist
- // we want to let the resource.ManagedReconciler know so it can create it.
- if database.IsNotFound(err) {
- return resource.ExternalObservation{ResourceExists: false}, nil
- }
-
- // Any other errors are wrapped (as is good Go practice) and returned to the
- // resource.ManagedReconciler. It will update the "Synced" status condition
- // of the managed resource to reflect that the most recent reconcile failed
- // and ensure the reconcile is reattempted after a brief wait.
- if err != nil {
- return resource.ExternalObservation{}, errors.Wrap(err, "cannot get instance")
- }
-
- // The external resource exists. Copy any output-only fields to their
- // corresponding entries in our status field.
- i.Status.Status = existing.GetStatus()
- i.Status.Hostname = existing.GetHostname()
- i.Status.ID = existing.GetID()
-
- // Update our "Ready" status condition to reflect the status of the external
- // resource. Most managed resources use the below well known reasons that
- // the "Ready" status may be true or false, but managed resource authors
- // are welcome to define and use their own.
- switch i.Status.Status {
- case database.StatusOnline:
- // If the resource is available we also want to mark it as bindable to
- // resource claims.
- resource.SetBindable(i)
- i.SetConditions(runtimev1alpha1.Available())
- case database.StatusCreating:
- i.SetConditions(runtimev1alpha1.Creating())
- case database.StatusDeleting:
- i.SetConditions(runtimev1alpha1.Deleting())
- }
-
- // Finally, we report what we know about the external resource. In this
- // hypothetical case FancinessLevel is the only field that can be updated
- // after creation time, so the resource does not need to be updated if
- // the actual fanciness level matches our desired fanciness level. Any
- // ConnectionDetails we return will be published to the managed resource's
- // connection secret if it specified one.
- o := resource.ExternalObservation{
- ResourceExists: true,
- ResourceUpToDate: existing.GetFancinessLevel == i.Spec.FancinessLevel,
- ConnectionDetails: resource.ConnectionDetails{
- runtimev1alpha1.ResourceCredentialsSecretUserKey: []byte(existing.GetUsername()),
- runtimev1alpha1.ResourceCredentialsSecretEndpointKey: []byte(existing.GetHostname()),
- },
- }
-
- return o, nil
-}
-
-// Create a new external resource based on the specification of our managed
-// resource. resource.ManagedReconciler only calls Create if Observe reported
-// that the external resource did not exist.
-func (e *external) Create(ctx context.Context, mg resource.Managed) (resource.ExternalCreation, error) {
- i, ok := mg.(*v1alpha2.FavouriteDBInstance)
- if !ok {
- return resource.ExternalCreation{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
- // Indicate that we're about to create the instance. Remember ExternalClient
- // authors can use a bespoke condition reason here in cases where Creating
- // doesn't make sense.
- i.SetConditions(runtimev1alpha1.Creating())
-
- // Create must return any connection details that are set or returned only
- // at creation time. The resource.ManagedReconciler will merge any details
- // with those returned during the Observe phase.
- password := database.GeneratePassword()
- cd := resource.ConnectionDetails{runtimev1alpha1.ResourceCredentialsSecretPasswordKey: []byte(password)}
-
- // Create a new instance.
- new := database.Instance{Name: i.Name, FancinessLevel: i.FancinessLevel, Version: i.Version}
- err := e.client.CreateInstance(ctx, new, password)
-
- // Note that we use resource.Ignore to squash any error that indicates the
- // external resource already exists. Create implementations must not return
- // an error if asked to create a resource that already exists. Real managed
- // resource controllers are advised to avoid unintentially 'adoptign' an
- // existing, unrelated external resource, per
- // https://github.com/crossplaneio/crossplane-runtime/issues/27
- return resource.ExternalCreation{ConnectionDetails: cd}, errors.Wrap(resource.Ignore(database.IsExists, err), "cannot create instance")
-}
-
-// Update the existing external resource to match the specifications of our
-// managed resource. resource.ManagedReconciler only calls Update if Observe
-// reported that the external resource was not up to date.
-func (e *external) Update(ctx context.Context, mg resource.Managed) (resource.ExternalUpdate, error) {
- i, ok := mg.(*v1alpha2.FavouriteDBInstance)
- if !ok {
- return resource.ExternalUpdate{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Recall that FancinessLevel is the only field that we _can_ update.
- new := database.Instance{Name: i.Name, FancinessLevel: i.FancinessLevel}
- err := e.client.UpdateInstance(ctx, new)
- return resource.ExternalUpdate{}, errors.Wrap(err, "cannot update instance")
-}
-
-// Delete the external resource. resource.ManagedReconciler only calls Delete
-// when a managed resource with the 'Delete' reclaim policy has been deleted.
-func (e *external) Delete(ctx context.Context, mg resource.Managed) error {
- i, ok := mg.(*v1alpha2.FavouriteDBInstance)
- if !ok {
- return errors.New("managed resource is not a FavouriteDBInstance")
- }
- // Indicate that we're about to delete the instance.
- i.SetConditions(runtimev1alpha1.Deleting())
-
- // Delete the instance.
- err := e.client.DeleteInstance(ctx, i.Spec.Name)
-
- // Note that we use resource.Ignore to squash any error that indicates the
- // external resource does not exist. Delete implementations must not return
- // an error when asked to delete a non-existent external resource.
- return errors.Wrap(resource.Ignore(database.IsNotFound, err), "cannot delete instance")
-}
-```
-
-### Resource Claim Controllers
-
-Resource claim controllers should use [`resource.NewClaimReconciler`] to wrap a
-managed-resource specific implementation of [`resource.ManagedConfigurator`].
-Parts of `resource.ClaimReconciler`'s behaviour is customisable; refer to the
-[`resource.NewClaimReconciler`] GoDoc for a list of options. Note that unlike
-their resource claim kinds, resource claim controllers are always part of the
-infrastructure stack that defines the managed resource they reconcile claims
-with. The following is an example controller that reconciles the
-`FancySQLInstance` resource claim with the `FavouriteDBInstance` managed
-resource:
-
-```go
-import (
- "context"
- "fmt"
- "strings"
-
- "github.com/pkg/errors"
- corev1 "k8s.io/api/core/v1"
- ctrl "sigs.k8s.io/controller-runtime"
- "sigs.k8s.io/controller-runtime/pkg/source"
-
- runtimev1alpha1 "github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1"
- "github.com/crossplaneio/crossplane-runtime/pkg/resource"
-
- // Note that the hypothetical FancySQL resource claim is part of Crossplane,
- // not stack-fcp, because it is (hypothetically) portable across multiple
- // infrastructure stacks.
- databasev1alpha1 "github.com/crossplaneio/crossplane/apis/database/v1alpha1"
-
- "github.com/crossplaneio/stack-fcp/apis/database/v1alpha2"
-)
-
-type FavouriteDBInstanceClaimController struct{}
-
-// SetupWithManager instantiates a new controller using a resource.ClaimReconciler
-// configured to reconcile FancySQLInstances by binding them to FavouriteDBInstances.
-func (c *FavouriteDBInstanceClaimController) SetupWithManager(mgr ctrl.Manager) error {
- // It's Crossplane convention to name resource claim controllers
- // "claimkind.resourcekind.resourceapigroup", for example in this case
- // "fancysqlinstance.favouritedbinstance.fcp.crossplane.io".
- name := strings.ToLower(fmt.Sprintf("%s.%s.%s",
- databasev1alpha1.FancySQLInstanceKind,
- v1alpha2.FavouriteDBInstanceKind,
- v1alpha2.Group))
-
- // The controller below watches for changes to both FancySQLInstance and
- // FavouriteDBInstance kind resources. We use watch predicates to filter
- // out any requests to reconcile resources that we're not interested in.
- p := resource.NewPredicates(resource.AnyOf(
- // We want to reconcile FancySQLInstance kind resource claims that
- // explicitly set their .spec.resourceRef to a FavouriteDBInstance kind
- // managed resource.
- resource.HasManagedResourceReferenceKind(resource.ManagedKind(v1alpha2.FavouriteDBInstanceGroupVersionKind)),
-
- // We want to reconcile FavouriteDBInstance managed resources that were
- // dynamically provisioned using the FavouriteDBInstanceClass. Note that
- // this predicate will soon be replaced by resource.IsManagedKind per
- // https://github.com/crossplaneio/crossplane-runtime/issues/28
- resource.HasDirectClassReferenceKind(resource.NonPortableClassKind(v1alpha2.FavouriteDBInstanceClassGroupVersionKind)),
-
- // We want to reconcile FancySQLInstance kind resource claims that
- // indirectly reference a FavouriteDBInstanceClass via a
- // FancySQLInstanceClass.
- resource.HasIndirectClassReferenceKind(mgr.GetClient(), mgr.GetScheme(), resource.ClassKinds{
- Portable: databasev1alpha1.FancySQLInstanceClassGroupVersionKind,
- NonPortable: v1alpha2.FavouriteDBInstanceClassGroupVersionKind,
- })))
-
- // Create a new resource claim reconciler...
- r := resource.NewClaimReconciler(mgr,
- // ..that uses the supplied claim, class, and managed resource kinds.
- resource.ClaimKind(databasev1alpha1.FancySQLInstanceGroupVersionKind),
- resource.ClassKinds{
- Portable: databasev1alpha1.FancySQLInstanceClassGroupVersionKind,
- NonPortable: v1alpha2.FavouriteDBInstanceClassGroupVersionKind,
- },
- resource.ManagedKind(v1alpha2.FavouriteDBInstanceGroupVersionKind),
- // The resource claim reconciler assumes managed resources do not
- // use the status subresource for compatibility with older managed
- // resource kinds, so well behaved resources must explicitly tell the
- // reconciler to update the status subresource per
- // https://github.com/crossplaneio/crossplane-runtime/issues/29
- resource.WithManagedBinder(resource.NewAPIManagedStatusBinder(mgr.GetClient())),
- resource.WithManagedFinalizer(resource.NewAPIManagedStatusUnbinder(mgr.GetClient())),
- // The following configurators configure how a managed resource will be
- // configured when one must be dynamically provisioned.
- resource.WithManagedConfigurators(
- resource.ManagedConfiguratorFn(ConfigureFavouriteDBInstance),
- resource.NewObjectMetaConfigurator(mgr.GetScheme()),
- ))
-
- // Note that we watch for both FancySQLInstance and FavouriteDBInstance
- // resources. When the latter passes our predicates we look up the resource
- // claim it references and reconcile that claim.
- return ctrl.NewControllerManagedBy(mgr).
- Named(name).
- Watches(&source.Kind{Type: &v1alpha2.FavouriteDBInstance{}}, &resource.EnqueueRequestForClaim{}).
- For(&databasev1alpha1.FancySQLInstance{}).
- WithEventFilter(p).
- Complete(r)
-}
-
-// ConfigureFavouriteDBInstance is responsible for updating the supplied managed
-// resource using the supplied non-portable resource class.
-func ConfigureFavouriteDBInstance(_ context.Context, cm resource.Claim, cs resource.NonPortableClass, mg resource.Managed) error {
- if _, ok := cm.(*databasev1alpha1.FancySQLInstance); !ok {
- return errors.New("resource claim is not a FancySQLInstance")
- }
-
- class, ok := cs.(*v1alpha2.FavouriteDBInstanceClass)
- if !ok {
- return errors.New("resource class is not a FavouriteDBInstanceClass")
- }
-
- instance, ok := mg.(*v1alpha2.FavouriteDBInstance)
- if !ok {
- return errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- instance.Spec = v1alpha2.FavouriteDBInstanceSpec{
- ResourceSpec: runtimev1alpha1.ResourceSpec{
- // It's typical for dynamically provisioned managed resources to
- // store their connection details in a Secret named for the claim's
- // UID. Managed resource secrets are not intended for human
- // consumption; they're copied to the resource claim's secret when
- // the resource is bound.
- WriteConnectionSecretToReference: corev1.LocalObjectReference{Name: string(cm.GetUID())},
- ProviderReference: class.SpecTemplate.ProviderReference,
- ReclaimPolicy: class.SpecTemplate.ReclaimPolicy,
- },
- FavouriteDBInstanceParameters: class.SpecTemplate.FavouriteDBInstanceParameters,
- }
-
- return nil
-}
-```
-
-### Default Resource Class Controller
-
-When adding support for a new resource claim kind a default resource class
-controller is also necessary. This controller watches for resource claims that
-don't have a managed resource reference _or_ a portable resource class reference
-and sets their resource class reference to the default portable class for their
-namespace, if one exists. Default resource class controllers should live near
-the resource claim and portable resource class kind definitions; frequently in
-Crossplane proper.
-
-The following controller sets default resource classes for `FancySQLInstance`
-resource claims:
-
-```go
-import (
- "fmt"
- "strings"
-
- ctrl "sigs.k8s.io/controller-runtime"
-
- "github.com/crossplaneio/crossplane-runtime/pkg/resource"
-
- databasev1alpha1 "github.com/crossplaneio/crossplane/apis/database/v1alpha1"
-)
-
-type FancySQLInstanceController struct{}
-
-func (c *FancySQLInstanceController) SetupWithManager(mgr ctrl.Manager) error {
- return ctrl.NewControllerManagedBy(mgr).
- Named(strings.ToLower(fmt.Sprintf("default.%s.%s", databasev1alpha1.FancySQLInstanceKind, databasev1alpha1.Group))).
- For(&databasev1alpha1.FancySQLInstance{}).
- WithEventFilter(resource.NewPredicates(resource.HasNoPortableClassReference())).
- WithEventFilter(resource.NewPredicates(resource.HasNoManagedResourceReference())).
- Complete(resource.NewDefaultClassReconciler(mgr,
- resource.ClaimKind(databasev1alpha1.FancySQLInstanceGroupVersionKind),
- resource.PortableClassKind{
- Singular: databasev1alpha1.FancySQLInstanceClassGroupVersionKind,
- Plural: databasev1alpha1.FancySQLInstanceClassListGroupVersionKind,
- },
- ))
-}
-```
-
-### Wrapping Up
-
-Once all your controllers are in place you'll want to test them. Note that most
-projects under the [crossplaneio org] [favor] table driven tests that use Go's
-standard library `testing` package over kubebuilder's Gingko based tests.
-
-Finally, don't forget to plumb any newly added resource kinds and controllers up
-to your controller manager. Simple stacks may do this for each type within
-within `main()`, but most more complicated stacks take an approach in which each
-package exposes an `AddToScheme` (for resource kinds) or `SetupWithManager` (for
-controllers) function that invokes the same function within its child packages,
-resulting in a `main.go` like:
-
-```go
-import (
- "time"
-
- "sigs.k8s.io/controller-runtime/pkg/client/config"
- "sigs.k8s.io/controller-runtime/pkg/manager"
- "sigs.k8s.io/controller-runtime/pkg/runtime/signals"
-
- "github.com/crossplaneio/crossplane/apis"
-
- fcpapis "github.com/crossplaneio/stack-fcp/apis"
- "github.com/crossplaneio/stack-fcp/pkg/controller"
-)
-
-func main() {
- cfg, err := config.GetConfig()
- if err != nil {
- panic(err)
- }
-
- mgr, err := manager.New(cfg, manager.Options{SyncPeriod: 1 * time.Hour})
- if err != nil {
- panic(err)
- }
-
- if err := apis.AddToScheme(mgr.GetScheme()); err != nil {
- panic(err)
- }
-
- if err := fcpapis.AddToScheme(mgr.GetScheme()); err != nil {
- panic(err)
- }
-
- if err := controller.SetupWithManager(mgr); err != nil {
- panic(err)
- }
-
- panic(mgr.Start(signals.SetupSignalHandler()))
-}
-```
-
-## In Review
-
-In this guide we walked through the process of defining all of the resource
-kinds and controllers necessary to build support for a new managed service;
-possibly even a completely new infrastructure stack. Please do not hesitate to
-[reach out] to the Crossplane maintainers and community for help designing and
-implementing support for new managed services. [#sig-services] would highly
-value any feedback you may have about the services development process!
-
-[What Makes a Crossplane Managed Service]: #what-makes-a-crossplane-managed-service
-[managed resource]: concepts.md#managed-resource
-[resource claim]: concepts.md#resource-claim
-[resource class]: concepts.md#resource-class
-[dynamic provisioning]: concepts.md#dynamic-and-static-provisioning
-[`CloudMemorystoreInstance`]: https://github.com/crossplaneio/stack-gcp/blob/42ebb8b71/gcp/apis/cache/v1alpha2/cloudmemorystore_instance_types.go#L146
-[`CloudMemorystoreInstanceClass`]: https://github.com/crossplaneio/stack-gcp/blob/42ebb8b71/gcp/apis/cache/v1alpha2/cloudmemorystore_instance_types.go#L237
-[`Provider`]: https://github.com/crossplaneio/stack-gcp/blob/24ab7381b/gcp/apis/v1alpha2/types.go#L37
-[`RedisCluster`]: https://github.com/crossplaneio/crossplane/blob/3c6cf4e/apis/cache/v1alpha1/rediscluster_types.go#L40
-[`RedisClusterClass`]: https://github.com/crossplaneio/crossplane/blob/3c6cf4e/apis/cache/v1alpha1/rediscluster_types.go#L116
-[watching the API server]: https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
-[kubebuilder]: https://kubebuilder.io/
-[controller-runtime]: https://github.com/kubernetes-sigs/controller-runtime
-[crossplane-runtime]: https://github.com/crossplaneio/crossplane-runtime/
-[golden path]: https://charity.wtf/2018/12/02/software-sprawl-the-golden-path-and-scaling-teams-with-agency/
-[API Conventions]: https://github.com/kubernetes/community/blob/c6e1e89a/contributors/devel/sig-architecture/api-conventions.md
-[kubebuilder book]: https://book.kubebuilder.io/
-[Stacks quick start]: https://github.com/crossplaneio/crossplane-cli/blob/357d18e7b/README.md#quick-start-stacks
-[resources]: https://kubebuilder.io/cronjob-tutorial/gvks.html#kinds-and-resources
-[kinds]: https://kubebuilder.io/cronjob-tutorial/gvks.html#kinds-and-resources
-[objects]: https://kubernetes.io/docs/concepts/#kubernetes-objects
-[comment marker]: https://kubebuilder.io/reference/markers.html
-[comment markers]: https://kubebuilder.io/reference/markers.html
-[`resource.Managed`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#Managed
-[`resource.Claim`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#Claim
-[`resource.PortableClass`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#PortableClass
-[`resource.PortableClassList`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#PortableClassList
-[`resource.NonPortableClass`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#NonPortableClass
-[`resource.ManagedReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#ManagedReconciler
-[`resource.NewManagedReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#NewManagedReconciler
-[`resource.ClaimReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#ClaimReconciler
-[`resource.NewClaimReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#NewClaimReconciler
-[`resource.DefaultClassReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#DefaultClassReconciler
-[`resource.NewDefaultClassReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#NewDefaultClassReconciler
-[`resource.ExternalConnecter`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#ExternalConnecter
-[`resource.ExternalClient`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#ExternalClient
-[`resource.ManagedConfigurator`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#ManagedConfigurator
-[`ResourceSpec`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1#ResourceSpec
-[`ResourceStatus`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1#ResourceStatus
-[`ResourceClaimSpec`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1#ResourceClaimSpec
-[`ResourceClaimStatus`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1#ResourceClaimStatus
-[`NonPortableClassSpecTemplate`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1#NonPortableClassSpecTemplate
-[`PortableClass`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1#PortableClass
-['resource.ExternalConnecter`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#ExternalConnecter
-[opening a Crossplane issue]: https://github.com/crossplaneio/crossplane/issues/new/choose
-[`GroupVersionKind`]: https://godoc.org/k8s.io/apimachinery/pkg/runtime/schema#GroupVersionKind
-[`reconcile.Reconciler`]: https://godoc.org/sigs.k8s.io/controller-runtime/pkg/reconcile#Reconciler
-[favor]: https://github.com/crossplaneio/crossplane/issues/452
-[reach out]: https://github.com/crossplaneio/crossplane#contact
-[#sig-services]: https://crossplane.slack.com/messages/sig-services
-[crossplaneio org]: https://github.com/crossplaneio
diff --git a/docs/v0.3/services-guide.md b/docs/v0.3/services-guide.md
deleted file mode 100644
index 8b24d3db..00000000
--- a/docs/v0.3/services-guide.md
+++ /dev/null
@@ -1,769 +0,0 @@
----
-title: Services Guide
-toc: true
-weight: 410
----
-# Services Guide
-Welcome to the Crossplane Services Guide!
-
-Crossplane Services enables managed service provisioning from `kubectl`
-including for databases, caches, buckets and more, including secure usage with
-Kubernetes `Secrets`.
-
-Crossplane Service follows established Kubernetes patterns like Persistent
-Volume Claims (PVC) to support dynamic provisioning of managed services and a
-clean separation of concerns between app teams and cluster administrators.
-
-In this document, we will:
- * Manually provision a new managed Kubernetes cluster and install Crossplane.
- * Learn how to provision managed services from `kubectl`.
- * Introduce cloud-specific guides with step-by-step instructions:
- * [GCP Services Guide][gcp-services-guide]
- * [AWS Services Guide][aws-services-guide]
- * [Azure Services Guide][azure-services-guide]
- * Explore how workload portability is achieved and how to configure shared clusters for multiple teams using namespaces.
- * Provide next steps for learning more about Crossplane!
-
-We will **not**:
- * Learn first principles (see the concepts document for that level of detail)
- * Deploy Crossplane as a dedicated control plane, it will run embedded in a single Kuberetes cluster.
- * Use advanced workload scheduling or multi-cluster management.
-
-If you have any questions, please drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us]!
-
-Let's go!
-
-# Concepts
-There are a bunch of things you might want to know to fully understand what's
-happening in this document. This guide won't cover them, but there are other
-ones that do. Here are some links!
- * [Crossplane concepts][crossplane-concepts]
- * [Kubernetes concepts][kubernetes-concepts]
-
-# Before you get started
-This guide assumes you are using a *nix-like environment. It also assumes you have a basic working familiarity with the following:
- * The terminal environment
- * Setting up cloud provider accounts for the cloud provider you want to use
-
-You will need:
- * A *nix-like environment
- * A cloud provider account, for the cloud provider of your choice (out of the supported providers)
-
-# Provisioning managed services from kubectl
-Crossplane can be added to existing Kubernetes clusters and cleanly layers on
-top of clusters provisioned by GKE, EKS, AKS, and more. Cluster administrators
-install Crossplane, set cloud credentials, and offer classes of service for
-self-service provisioning using `kubectl`. Application teams can provision
-managed services with `Resource Claims` without having to worry about
-cloud-specific infrastructure details or manage credentials.
-
-
-# Overview
-
-This guide shows how to provision a managed `MySQLInstance` and securely consume it from a Wordpress `Deployment`.
-
-To provision a portable `MySQLInstance` for the Wordpress app we'd like to enable app teams to:
-
-```sh
-kubectl create -f mysql-claim.yaml
-```
-with mysql-claim.yaml:
-```yaml
-apiVersion: database.crossplane.io/v1alpha2
-kind: MySQLInstance
-metadata:
- name: mysql-claim
- namespace: app-project1-dev
-spec:
- classRef:
- name: mysql-standard
- writeConnectionSecretToRef:
- name: mysql-claim-secret
- engineVersion: "5.6"
-```
-
-Note there are no references in this `Resource Claim` to anything
-cloud-specific. As such any environment can be configured to satisfy this claim,
-using different configurations for different environments (dev, staging, prod),
-or different managed service providers such as CloudSQL, RDS, or Azure DB.
-
-This portable experience is typically accomplished by:
-1. Defining **cloud-specific** `Resource Classes` in an infrastructure namespace.
-1. Offering **portable** `Resource Classes` in an app project namespace for provisioning with `kubectl`.
-1. Creating **portable** `Resource Claims` using `kubectl` to provision a managed service.
-
-This enables the following usage: app -> portable claim -> portable class -> cloud-specific class -> provider.
-
-## Steps
-### A) One-time cluster setup
- 1. Manually provision a managed Kubernetes target cluster: GKE, EKA, AKS.
- 1. Install Crossplane into the target cluster.
- 1. Install a cloud provider Stack: GCP, AWS, Azure.
- 1. Connect a cloud provider account to a shared infrastructure namespace.
- 1. Create cloud-specific classes of service with best-practice configurations.
-
-### B) Onboard app projects in a shared cluster
- 1. Create an app project namespace `app-project1-dev`.
- 1. Add portable classes of service for managed service provisioning using `kubectl`.
- 1. Set default classes of service.
-
-### C) Deploy Wordpress with a managed MySQLInstance
- 1. Provision a `MySQLInstance` using `kubectl`.
- 1. Securely connect to the database using a generated Kubernetes `Secret`.
- 1. Verify Wordpress is working correctly.
- 1. Delete all resources.
- 1. Verify everything was cleanly deleted.
-
-## Resulting Kubernetes objects
-
-In an AWS envionment offering multiple classes of service, the following Kubernetes objects would result:
-```text
-namespaces
-└── aws-infra-dev
- └── provider # AWS provider configuration
- └── provider-creds # AWS provider account credentials
- └── rds-mysql-standard # RDS-specific class, non-portable config
- └── rds-mysql-replicated # RDS-specific class, non-portable config
- └── rds-postgres-standard # RDS-specific class, non-portable config
- └── rds-postgres-replicated # RDS-specific class, non-portable config
-└── app-project1-dev
- └── mysql-standard # portable MySQL class of service
- └── mysql-replicated # portable MySQL class of service
- └── postgres-standard # portable PostgreSQL class of service
- └── postgres-ha # portable PostgreSQL class of service
- └── mysql-claim # portable MySQL claim for mysql-standard class of service
- └── mysql-claim-secret # generated secret to access database
- └── wordpress-deployment # standard Kubernetes deployment
- └── wordpress-service # standard Kubernetes service
-```
-
-# Cloud-specific Guides
-Use these step-by-step guides to provision a managed `MySQLInstance` and
-securely consume it from a Wordpress `Deployment`:
- * [GCP Services Guide][gcp-services-guide]
- * [AWS Services Guide][aws-services-guide]
- * [Azure Services Guide][azure-services-guide]
-
-# Reviewing what happened across providers
-This section reviews the general flow of the cloud-specific guides, how workload
-portability is achieved using resource claims and classes, and techniques to
-organize a shared cluster using namespaces.
-
-## A) One-time cluster setup
-### Managed Kubernetes Cluster
-Provision a new managed Kubernetes cluster, following the cloud-specific guides
-for [GCP][gcp-services-guide], [AWS][aws-services-guide], or [Azure][azure-services-guide]
-
-### Install Crossplane
- 1. [Install Crossplane from the alpha channel][install-crossplane-alpha].
- 1. [Install a cloud provider Stack][install-provider-stacks]
-from the [Stacks registry][stack-registry] from one of:
-[stack-gcp][stack-gcp], [stack-aws][stack-aws], or [stack-azure][stack-azure].
-
-### Connect Crossplane to a Cloud Provider
-Crossplane supports connecting multiple cloud provider accounts from a single
-cluster, so different environments (dev, staging, prod) can use separate
-accounts, projects, and/or credentials.
-
-While the guides use a single infrastructure namespace (gcp-infra-dev,
-aws-infra-dev, or azure-infra-dev), you can create as many as you like using
-whatever naming works best for your organization.
-
-To connect an infrastructure namespace to a cloud provider:
- 1. Create an infrastructure namespace in the Kubernetes cluster.
- 1. [Obtain Cloud Provider Credentials][cloud-provider-creds]
-and export to `BASE64ENCODED_PROVIDER_CREDS`.
- 1. Add a Crossplane `Provider`.
-
-For example, based on your cloud provider, add a `Provider` to your infrastructure namespace:
-
-gcp-provider.yaml
-```yaml
----
-apiVersion: v1
-data:
- credentials.json: $BASE64ENCODED_PROVIDER_CREDS
-kind: Secret
-metadata:
- name: provider-creds
- namespace: gcp-infra-dev
-type: Opaque
----
-## Crossplane GCP Provider
-apiVersion: gcp.crossplane.io/v1alpha2
-kind: Provider
-metadata:
- name: provider
- namespace: gcp-infra-dev
-spec:
- credentialsSecretRef:
- name: provider-creds
- key: credentials.json
- projectID: $PROJECT_ID
-```
-
-aws-provider.yaml
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
- name: provider-creds
- namespace: aws-infra-dev
-type: Opaque
-data:
- credentials: $BASE64ENCODED_PROVIDER_CREDS
----
-## Crossplane AWS Provider
-apiVersion: aws.crossplane.io/v1alpha2
-kind: Provider
-metadata:
- name: provider
- namespace: aws-infra-dev
-spec:
- credentialsSecretRef:
- key: credentials
- name: provider-creds
- region: $REGION
-```
-
-azure-provider.yaml
-```yaml
----
-apiVersion: v1
-kind: Secret
-metadata:
- name: provider-creds
- namespace: azure-infra-dev
-type: Opaque
-data:
- credentials: $BASE64ENCODED_PROVIDER_CREDS
----
-## Crossplane Azure Provider
-apiVersion: azure.crossplane.io/v1alpha2
-kind: Provider
-metadata:
- name: provider
- namespace: azure-infra-dev
-spec:
- credentialsSecretRef:
- name: provider-creds
- key: credentials
-```
-
-The `Provider` defined in the infrastructure namespace will be referenced by cloud-specific `Resource Classes` in the next step.
-
-### Create classes of service with best-practice configurations
-**Cloud-specific** `Resource Classes` capture reusable, best-practice configurations for a specific managed service.
-
-For example, Wordpress requires a MySQL database which can be satisfied by CloudSQL, RDS, or Azure DB.
-
-Based on your cloud provider, add a **cloud-specific** `Resource Class` to your infrastructure namespace:
-
-rds-mysql-standard.yaml
-```yaml
----
-apiVersion: database.aws.crossplane.io/v1alpha2
-kind: RDSInstanceClass
-metadata:
- name: rds-mysql-standard
- namespace: aws-infra-dev
-specTemplate:
- class: db.t2.small
- masterUsername: masteruser
- securityGroups:
- - # sg-ab1cdefg
- - # sg-05adsfkaj1ksdjak
- size: 20
- engine: mysql
- providerRef:
- name: demo
- namespace: aws-infra-dev
- reclaimPolicy: Delete
-```
-
-cloudsql--mysql-standard.yaml
-```yaml
----
-apiVersion: database.gcp.crossplane.io/v1alpha2
-kind: CloudsqlInstanceClass
-metadata:
- name: cloudsql-mysql-standard
- namespace: gcp-infra-dev
-specTemplate:
- databaseVersion: MYSQL_5_6
- tier: db-custom-1-3840
- region: us-west2
- storageType: PD_SSD
- storageGB: 10
- providerRef:
- name: demo
- namespace: gcp-infra-dev
- reclaimPolicy: Delete
-```
-
-azuredb-mysql-standard.yaml
-```yaml
----
-apiVersion: database.azure.crossplane.io/v1alpha2
-kind: SQLServerClass
-metadata:
- name: azuredb-mysql-standard
- namespace: azure-infra-dev
-specTemplate:
- adminLoginName: myadmin
- resourceGroupName: group-westus-1
- location: West US
- sslEnforced: false
- version: "5.6"
- pricingTier:
- tier: Basic
- vcores: 1
- family: Gen5
- storageProfile:
- storageGB: 25
- backupRetentionDays: 7
- geoRedundantBackup: false
- providerRef:
- name: demo
- namespace: azure-infra-dev
- reclaimPolicy: Delete
-```
-
-Creating multiple classes of service in an AWS environment results in these Kubernetes objects:
-
-```text
-namespaces
-└── aws-infra-dev
- └── provider # AWS provider configuration
- └── provider-creds # AWS provider account credentials
- └── rds-mysql-standard # RDS-specific class, non-portable config
- └── rds-mysql-replicated # RDS-specific class, non-portable config
- └── rds-postgres-standard # RDS-specific class, non-portable config
- └── rds-postgres-replicated # RDS-specific class, non-portable config
-```
-
-However, cloud-specific `Resource Classes` are not portable across providers so
-we need something to represent a portable class of service for use in a portable
-`Resource Claim`.
-
-The next section covers how to offer a cloud-specific `Resource Class` as a
-portable class of service, so an app team can provision managed services using
-`kubectl` in a portable way.
-
-## B) Onboard app projects in a shared cluster
-### Offer Portable Classes of Service in App Project Namespaces
-[Portable Resource Classes][concept-portable-class]
-define a named class of service that can be used by portable `Resource Claims`
-in the same namespace. When used in a project namespace, this enables the
-project to provision portable managed services using `kubectl`.
-
-```sh
-kubectl create -f mysql-claim.yaml
-```
-with mysql-claim.yaml:
-```yaml
-apiVersion: database.crossplane.io/v1alpha2
-kind: MySQLInstance
-metadata:
- name: mysql-claim
- namespace: app-project1-dev
-spec:
- classRef:
- name: mysql-standard
- writeConnectionSecretToRef:
- name: mysql-claim-secret
- engineVersion: "5.6"
-```
-Note the portable `Resource Claim` below uses a `spec.classRef.name` of
-`mysql-standard` to reference a portable `Resource Class` in the same namespace.
-It has no knowledge of which cloud provider will satisfy this claim or how a
-suitable cloud-specific `Resource Class` will be selected.
-
-Adding portable classes of service to the `app-project1-dev` namespace, results in these Kubernetes objects:
-```text
-└── app-project1-dev
- └── mysql-standard # portable MySQL class of service
- └── mysql-replicated # portable MySQL class of service
- └── postgres-standard # portable PostgreSQL class of service
- └── postgres-ha # portable PostgreSQL class of service
-```
-
-These portable `Resource Classes` could be defined as follows for an AWS dev
-environment, but alternate configurations could be provided for different
-environments (staging, prod) or different cloud provider like GCP or Azure, to
-satisfy the named classes of service:
-
-mysql-standard.yaml
-```yaml
-apiVersion: database.crossplane.io/v1alpha1
-kind: MySQLInstanceClass
-metadata:
- name: mysql-standard
- namespace: app-project1-dev
- labels:
- default: true
-classRef:
- kind: RDSInstanceClass
- apiVersion: database.aws.crossplane.io/v1alpha1
- name: rds-mysql-standard
- namespace: aws-infra-dev
-```
-
-mysql-replicated.yaml
-```yaml
-apiVersion: database.crossplane.io/v1alpha1
-kind: MySQLInstanceClass
-metadata:
- name: mysql-replicated
- namespace: app-project1-dev
-classRef:
- kind: RDSInstanceClass
- apiVersion: database.aws.crossplane.io/v1alpha1
- name: rds-mysql-replicated
- namespace: aws-infra-dev
-```
-
-postgres-standard.yaml
-```yaml
-apiVersion: database.crossplane.io/v1alpha1
-kind: PostgreSQLInstanceClass
-metadata:
- name: postgres-standard
- namespace: app-project1-dev
- labels:
- default: true
-classRef:
- kind: RDSInstanceClass
- apiVersion: database.aws.crossplane.io/v1alpha1
- name: rds-postgres-standard
- namespace: aws-infra-prod
-```
-
-postgres-ha.yaml
-```yaml
-apiVersion: database.crossplane.io/v1alpha1
-kind: PostgreSQLInstanceClass
-metadata:
- name: postgres-ha
- namespace: app-project1-dev
-classRef:
- kind: RDSInstanceClass
- apiVersion: database.aws.crossplane.io/v1alpha1
- name: rds-postgres-ha
- namespace: aws-infra-prod
-```
-
-Note that some portable `Resource Classes` are marked with
-[`label.default: true`][concept-default-class]
-to indicate it's the default class of service for a given claim kind in the
-`app-project1-dev` namespace.
-
-`Resource Claims` can rely on the default class of service in the same namespace for a given claim kind by omitting `spec.classRef`.
-
-Claim-based provisioning and use of default `Resource Classes` will be covered in the next section.
-
-With multiple classes of service available in the `app-project1-dev` namespace, these Kuberntes objects would be present:
-```text
-namespaces
-└── aws-infra-dev
- └── provider # AWS provider configuration
- └── provider-creds # AWS provider account credentials
- └── rds-mysql-standard # RDS-specific class, non-portable config
- └── rds-mysql-replicated # RDS-specific class, non-portable config
- └── rds-postgres-standard # RDS-specific class, non-portable config
- └── rds-postgres-replicated # RDS-specific class, non-portable config
-└── app-project1-dev
- └── mysql-standard # portable MySQL class of service
- └── mysql-replicated # portable MySQL class of service
- └── postgres-standard # portable PostgreSQL class of service
- └── postgres-ha # portable PostgreSQL class of service
-```
-
-
-## C) Deploy Wordpress with a managed MySQLInstance
-### Provision a MySQLInstance from kubectl
-Managed services can be provisioned in a portable way using `kubectl`, with the
-`app-project1-dev` namespace populated with available classes of service.
-
-```sh
-kubectl create -f mysql-claim.yaml
-```
-with mysql-claim.yaml:
-```yaml
-apiVersion: database.crossplane.io/v1alpha2
-kind: MySQLInstance
-metadata:
- name: mysql-claim
- namespace: app-project1-dev
-spec:
- classRef:
- name: mysql-standard
- writeConnectionSecretToRef:
- name: mysql-claim-secret
- engineVersion: "5.6"
-```
-
-The `spec.classRef` can be omitted from a `Resource Claim` to rely on the
-default class of service in the same namespace.
-```yaml
-apiVersion: database.crossplane.io/v1alpha2
-kind: MySQLInstance
-metadata:
- name: mysql-claim
- namespace: app-project1-dev
-spec:
- writeConnectionSecretToRef:
- name: mysql-claim-secret
- engineVersion: "5.6"
-```
-
-The `Binding Status` of a `Resource Claim` will indicate `Bound` when the
-underlying managed service has been provisioned and the connection secret is
-available for use.
-
-```sh
-kubectl get mysqlinstances -n app-project1-dev
-```
-Output:
-```sh
-NAME STATUS CLASS VERSION AGE
-mysql-claim Bound mysql-standard 5.6 11
-```
-
-### Securely consume the MySQLInstance from a Wordpress Deployment
-```sh
-kubectl create -f wordpress-app.yaml
-```
-with wordpress-app.yaml:
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- name: wordpress-deployment
- namespace: app-project1-dev
- labels:
- app: wordpress
-spec:
- selector:
- matchLabels:
- app: wordpress
- template:
- metadata:
- labels:
- app: wordpress
- spec:
- containers:
- - name: wordpress
- image: wordpress:4.6.1-apache
- env:
- - name: WORDPRESS_DB_HOST
- valueFrom:
- secretKeyRef:
- name: mysql-claim-secret
- key: endpoint
- - name: WORDPRESS_DB_USER
- valueFrom:
- secretKeyRef:
- name: mysql-claim-secret
- key: username
- - name: WORDPRESS_DB_PASSWORD
- valueFrom:
- secretKeyRef:
- name: mysql-claim-secret
- key: password
- ports:
- - containerPort: 80
- name: wordpress
----
-apiVersion: v1
-kind: Service
-metadata:
- name: wordpress-service
- namespace: app-project1-dev
- labels:
- app: wordpress
-spec:
- ports:
- - port: 80
- selector:
- app: wordpress
- type: LoadBalancer
-```
-
-### Cleanly Delete Wordpress and the MySQLInstance
-```sh
-kubectl delete -f wordpress-app.yaml
-kubectl delete -f mysql-claim.yaml
-```
-
-# Summary
-In this example we saw how to:
- * Add Crossplane to a managed Kubernetes cluster.
- * Install a cloud provider Stack for GCP, AWS, or Azure to add managed service provisoining.
- * Define cloud-specific classes of service in an infrastructure namespace.
- * Offer portable classes of service in an app project namespace.
- * Provision a managed MySQLInstance using kubectl.
- * Securely connect to the MySQLInstance from a Wordpress Deployment.
- * Cleanly delete all resources.
-
-After one-time setup was done and app projects were onboarded into the shared
-cluster, managed services could be provisioned using `kubectl` with portable
-claims in a project namespace.
-
-Resources were configured in infrastructure and app project namespaces:
-```text
-namespaces
-└── aws-infra-dev
- └── provider # AWS provider configuration
- └── provider-creds # AWS provider account credentials
- └── rds-mysql-standard # RDS-specific class, non-portable config
- └── rds-mysql-replicated # RDS-specific class, non-portable config
- └── rds-postgres-standard # RDS-specific class, non-portable config
- └── rds-postgres-replicated # RDS-specific class, non-portable config
-└── app-project1-dev
- └── mysql-standard # portable MySQL class of service
- └── mysql-replicated # portable MySQL class of service
- └── postgres-standard # portable PostgreSQL class of service
- └── postgres-ha # portable PostgreSQL class of service
- └── mysql-claim # portable MySQL claim for mysql-standard class of service
- └── mysql-claim-secret # generated secret to access database
- └── wordpress-deployment # standard Kubernetes deployment
- └── wordpress-service # standard Kubernetes service
-```
-
-Crossplane Services brings managed service provisioning to `kubectl` and enables
-cluster admins to offer multiple classes of service to accelerate app delivery
-while ensuring best-practices and security in your cloud of choice.
-
-Claim-based provisioning supports portability into different cloud environments
-since the app only depends on named or default classes of service that can
-provide wire-compatible managed services (MySQL, PostgreSQL, Redis, and more)
-independent of how a given cloud provider satisfies the claim. Claim-based
-provisioning also supports differentiated cloud services, so all managed
-services can work with Crossplane.
-
-If you have any questions, please drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us]!
-
-# Learn More
-This guide covered deploying Crossplane into a single managed Kubernetes
-cluster, and using cloud provider Stacks to provision a managed MySQL instance for
-use with a Wordpress Deployment. However, this involved configuring multiple
-Kubernetes objects to get a fully functioning Wordpress instance securely
-deployed.
-
-Stacks can also be used to simplify app management and automate operations. Our
-next guide shows how an App Stack can automate most of the steps covered in this
-guide and be run from a dedicated control plane that: (a) dynamically provisions
-the target cluster, (b) provisions the managed services, and (c) deploys the app
-itself with secure connectivity.
-
-App Stacks simplify operations for an app by moving the steps covered in this guide into a Kubernetes controller that owns an app CRD (custom resource definition) with a handful of settings required to deploy a new app instance, complete with the managed services it depends on.
-
-## Next Steps
-* [Crossplane Stacks Guide][stack-user-guide] to deploy the same Wordpress instance with a
- single yaml file, using the [portable Wordpress App Stack][stack-wordpress].
-* [Extend a Stack][stack-developer-guide] to add more cloud services to:
- [stack-gcp][stack-gcp], [stack-aws][stack-aws], or [stack-azure][stack-azure].
-* [Build a new Stack][stack-developer-guide] to add more cloud providers or
- independent cloud services.
-
-If you have any questions, please drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us]!
-
-## References
-### Concepts
-* [Crossplane Concepts][crossplane-concepts]
-* [Claims][concept-claim]
-* [Classes][concept-class]
-* [Portable Classes][concept-portable-class]
-* [Default Classes][concept-default-class]
-* [Workloads][concept-workload]
-* [Stacks][concept-stack]
-* [Stacks Design][stack-design]
-* [Stacks Manager][stack-manager]
-* [Stacks Registry][stack-registry]
-* [Stack Install Flow][stack-install-docs]
-* [Stack Package Format][stack-format-docs]
-
-### Getting Started
-* [Install Crossplane][install-crossplane]
-* [Install Provider Stacks][install-provider-stacks]
-* [Cloud Provider Credentials][cloud-provider-creds]
-* [Crossplane CLI][crossplane-cli]
-* [Crossplane CLI Docs][crossplane-cli-docs]
-
-**GCP**
-* [GCP Services Guide][gcp-services-guide]
-* [GCP Stack][stack-gcp]
-* [GCP Docs][gcp-docs]
-
-**AWS**
-* [AWS Services Guide][aws-services-guide]
-* [AWS Stack][stack-aws]
-* [AWS Docs][aws-docs]
-
-**AWS**
-* [Azure Services Guide][azure-services-guide]
-* [Azure Stack][stack-azure]
-* [Azure Docs][azure-docs]
-
-### Using and Building Stacks
-* [Stacks Guide][stack-user-guide]
-* [Stacks Developer Quick Start][stack-quick-start]
-* [Stacks Developer Guide][stack-developer-guide]
-
-### Kubernetes
-* [Kubernetes Concepts][kubernetes-concepts]
-* [Kubernetes Docs][kubernetes-docs]
-* [kubectl docs][kubectl-docs]
-
-### Learn More
-* [Join Crossplane Slack][join-crossplane-slack]
-* [Contact Us][contact-us]
-* [Learn More][learn-more]
-
-
-[crossplane-concepts]: concepts.md
-[concept-claim]: concepts.md#resource-claims-and-resource-classes
-[concept-class]: concepts.md#resource-claims-and-resource-classes
-[concept-workload]: concepts.md#resources-and-workloads
-[concept-stack]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#crossplane-stacks
-[concept-portable-class]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-default-resource-class.md#proposal-default-class-reference-v2--claim-portability
-[concept-default-class]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-default-resource-class.md#denote-default-via-label
-
-[kubernetes-concepts]: https://kubernetes.io/docs/concepts/
-[kubernetes-docs]: https://kubernetes.io/docs/home/
-[kubectl-docs]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
-
-[install-crossplane]: install-crossplane.md
-[install-crossplane-alpha]: install-crossplane.html#alpha
-[install-provider-stacks]: install-crossplane.md#installing-cloud-provider-stacks
-[cloud-provider-creds]: cloud-providers.md
-
-[crossplane-cli]: https://github.com/crossplaneio/crossplane-cli
-[crossplane-cli-docs]: https://github.com/crossplaneio/crossplane-cli/blob/master/README.md
-
-[stack-quick-start]: https://github.com/crossplaneio/crossplane-cli#quick-start-stacks
-[stack-registry]: https://hub.docker.com/search?q=crossplane&type=image
-[stack-design]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#crossplane-stacks
-[stack-manager]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#terminology
-[stack-install-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#installation-flow
-[stack-format-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#stack-package-format
-[stack-user-guide]: stacks-guide.md
-[stack-developer-guide]: developer-guide.md
-[contact-us]: https://github.com/crossplaneio/crossplane#contact
-[join-crossplane-slack]: https://slack.crossplane.io
-
-[stack-gcp]: https://github.com/crossplaneio/stack-gcp
-[stack-aws]: https://github.com/crossplaneio/stack-aws
-[stack-azure]: https://github.com/crossplaneio/stack-azure
-[stack-wordpress]: https://github.com/crossplaneio/sample-stack-wordpress
-
-[gcp-services-guide]: services/gcp-services-guide.md
-[aws-services-guide]: services/aws-services-guide.md
-[azure-services-guide]: services/azure-services-guide.md
-
-[aws-docs]: https://docs.aws.amazon.com/
-[gcp-docs]: https://cloud.google.com/docs/
-[azure-docs]: https://docs.microsoft.com/azure/
-
-[learn-more]: learn-more.md
diff --git a/docs/v0.3/services/aws-services-guide.md b/docs/v0.3/services/aws-services-guide.md
deleted file mode 100644
index db1e65dc..00000000
--- a/docs/v0.3/services/aws-services-guide.md
+++ /dev/null
@@ -1,929 +0,0 @@
----
-title: Using AWS Services
-toc: true
-weight: 430
-indent: true
----
-
-# Deploying Wordpress in Amazon Web Services (AWS)
-
-This user guide will walk you through Wordpress application deployment using
-Crossplane managed resources and the official Wordpress Docker image.
-
-## Table of Contents
-
-1. [Pre-requisites](#pre-requisites)
-1. [Preparation](#preparation)
-1. [Set Up an EKS Cluster](#set-up-an-eks-cluster)
-1. [Set Up RDS Configurations](#set-up-rds-configurations)
-1. [Set Up Crossplane](#set-up-crossplane)
-1. [Install Wordpress](#install-wordpress)
-1. [Uninstall](#uninstall)
-1. [Conclusion and Next Steps](#conclusion-and-next-steps)
-
-## Pre-requisites
-
-These tools are required to complete this guide. They must be installed on your
-local machine.
-
-* [AWS CLI][aws-cli-install]
-* [kubectl][install-kubectl]
-* [Helm][using-helm], minimum version `v2.10.0+`.
-* [jq][jq-docs] - command line JSON processor `v1.5+`
-
-## Preparation
-
-This guide assumes that you have already [installed][aws-cli-install] and
-[configured][aws-cli-configure].
-
-*Note: the following session variables are used throughout this guide. You may
-use the values below or create your own.*
-
-### Set Up an EKS Cluster
-
-We will create an EKS cluster, follwoing the steps provided in [AWS
-documentation][aws-create-eks].
-
-#### Create and Configure an EKS compatible VPN
-
-First, we will need to create a VPC, and its related resources. This can be done
-by creating a compatible **CloudFormation stack**, provided in [EKS official
-documentation][sample-cf-stack]. This stack consumes a few parameters, that we
-will provide by the following variables:
-
-```bash
-# we give an arbitrary name to the stack.
-# this name has to be unique within an aws account and region
-VPC_STACK_NAME=crossplane-example
-
-# any aws region that supports eks clusters
-REGION=eu-west-1
-
-# a sample stack that can be used to create an EKS-compatible
-# VPC and other the related resources
-STACK_URL=https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2019-02-11/amazon-eks-vpc-sample.yaml
-```
-
-Once all these variables are set, create the stack:
-
-```bash
-# generate and run the CloudFormation Stack
-aws cloudformation create-stack \
- --template-url="${STACK_URL}" \
- --region "${REGION}" \
- --stack-name "${VPC_STACK_NAME}" \
- --parameters \
- ParameterKey=VpcBlock,ParameterValue=192.168.0.0/16 \
- ParameterKey=Subnet01Block,ParameterValue=192.168.64.0/18 \
- ParameterKey=Subnet02Block,ParameterValue=192.168.128.0/18 \
- ParameterKey=Subnet03Block,ParameterValue=192.168.192.0/18
-```
-
-The output of this command will look like:
-
->```bash
->{
-> "StackId": "arn:aws:cloudformation:eu-west-1:123456789012:stack/crossplane-example-workers/de1d4770-d9f0-11e9-a293-02673541b8d0"
->}
->```
-
-Creating the stack continues in the background and could take a few minutes to
-complete. You can check its status by running:
-
-```bash
-aws cloudformation describe-stacks --output json --stack-name ${VPC_STACK_NAME} --region $REGION | jq -r '.Stacks[0].StackStatus'
-```
-
-Once the output of the above command is `CREATE_COMPLETE`, the stack creation is
-completed, and you can retrieve some of the properties of the created resources.
-These properties will later be consumed in other resources.
-
-```bash
-VPC_ID=$(aws cloudformation describe-stacks --output json --stack-name ${VPC_STACK_NAME} --region ${REGION} | jq -r '.Stacks[0].Outputs[]|select(.OutputKey=="VpcId").OutputValue')
-
-# comma separated list of Subnet IDs
-SUBNET_IDS=$(aws cloudformation describe-stacks --output json --stack-name ${VPC_STACK_NAME} --region ${REGION} | jq -r '.Stacks[0].Outputs[]|select(.OutputKey=="SubnetIds").OutputValue')
-
-# the ID of security group that later will be used for the EKS cluster
-EKS_SECURITY_GROUP=$(aws cloudformation describe-stacks --output json --stack-name ${VPC_STACK_NAME} --region ${REGION} | jq -r '.Stacks[0].Outputs[]|select(.OutputKey=="SecurityGroups").OutputValue')
-```
-
-#### Create an IAM Role for the EKS cluster
-
-For the EKS cluster to be able to access different resources, it needs to be
-given the required permissions through an **IAM Role**. In this section we
-create a role and assign the required policies. Later we will make EKS to assume
-this role.
-
-```bash
-EKS_ROLE_NAME=crossplane-example-eks-role
-
-# the policy that determines what principal can assume this role
-ASSUME_POLICY='{
- "Version": "2012-10-17",
- "Statement": {
- "Effect": "Allow",
- "Principal": {
- "Service": "eks.amazonaws.com"
- },
- "Action": "sts:AssumeRole"
- }
-}'
-
-# Create a Role that can be assumed by EKS
-aws iam create-role \
- --role-name "${EKS_ROLE_NAME}" \
- --region "${REGION}" \
- --assume-role-policy-document "${ASSUME_POLICY}"
-```
-
-The output should be the created role in JSON. Next, you'll attach the required
-policies to this role:
-
-```bash
-# attach the required policies
-aws iam attach-role-policy --role-name "${EKS_ROLE_NAME}" --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy > /dev/null
-aws iam attach-role-policy --role-name "${EKS_ROLE_NAME}" --policy-arn arn:aws:iam::aws:policy/AmazonEKSServicePolicy > /dev/null
-```
-
-Now lets retrieve the **ARN** of this role and store it in a variable. We later
-assign this to the EKS.
-
-```bash
-EKS_ROLE_ARN=$(aws iam get-role --output json --role-name "${EKS_ROLE_NAME}" | jq -r .Role.Arn)
-```
-
-#### Creating the EKS cluster
-
-At this step we create an EKS cluster:
-
-```bash
-CLUSTER_NAME=crossplane-example-cluster
-K8S_VERSION=1.14
-
-aws eks create-cluster \
- --region "${REGION}" \
- --name "${CLUSTER_NAME}" \
- --kubernetes-version "${K8S_VERSION}" \
- --role-arn "${EKS_ROLE_ARN}" \
- --resources-vpc-config subnetIds="${SUBNET_IDS}",securityGroupIds="${EKS_SECURITY_GROUP}"
-```
-
-An EKS cluster should have started provisioning, which could take take up to 15
-minutes. You can check the status of the cluster by periodically running:
-
-```bash
-aws eks describe-cluster --name "${CLUSTER_NAME}" --region "${REGION}" | jq -r .cluster.status
-```
-
-Once the provisioning is completed, the above command will return `ACTIVE`.
-
-#### Configuring `kubectl` to communicate with the EKS cluster
-
-Once the cluster is created and is `ACTIVE`, we configure `kubectl` to target
-this cluster:
-
-```bash
-# this environment variable tells kubectl what config file to use
-# its value is an arbitrary name, which will be used to name
-# the eks cluster configuration file
-export KUBECONFIG=~/.kube/eks-config
-
-# this command will populate the eks k8s config file
-aws eks update-kubeconfig \
- --name "${CLUSTER_NAME}"\
- --region "${REGION}"\
- --kubeconfig "${KUBECONFIG}"
-```
-
-The output will look like:
-
->```bash
->Added new context arn:aws:eks:eu-west-1:123456789012:cluster/crossplane-example-cluster to /path/to/.kube/eks-config
->```
-
-Now `kubectl` should be configured to talk to the EKS cluster. To verify this
-run:
-
-```bash
-kubectl cluster-info
-```
-
-Which should produce something like:
-
->```bash
->Kubernetes master is running at https://12E34567898A607F40B3C2FDDF42DC5.sk1.eu-west-1.eks.amazonaws.com
->```
-
-#### Creating Worker Nodes for the EKS cluster
-
-The worker nodes of an EKS cluster are not managed by the cluster itself.
-Instead, a set of EC2 instances, along with other resources and configurations
-are needed to be provisioned. In this section, we will create another
-CloudFormation stack to setup a worker node configuration, which is described in
-[EKS official documentation][sample-workernodes-stack].
-
-Before creating the stack, we will need to create a [Key Pair][aws-key-pair].
-This key pair will be used to log into the worker nodes. Even though we don't
-need to log into the worker nodes for the purpose of this guide, the worker
-stack would fail without providing it.
-
-```bash
-# an arbitrary name for the keypair
-KEY_PAIR=crossplane-example-kp
-
-# an arbitrary name for the workers stack
-# this name has to be unique within an aws account and region
-WORKERS_STACK_NAME=crossplane-example-workers
-
-# the id for the AMI image that will be used for worker nodes
-# there is a specific id for each region and k8s version
-NODE_IMAGE_ID="ami-0497f6feb9d494baf"
-
-# a sample stack that can be used to launch worker nodes
-WORKERS_STACK_URL=https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2019-02-11/amazon-eks-nodegroup.yaml
-
-# generate a KeyPair. the output will be the RSA private key value
-# which we do not need and will ignore
-aws ec2 create-key-pair --key-name "${KEY_PAIR}" --region="${REGION}" > /dev/null
-
-# create the workers stack
-aws cloudformation create-stack \
- --template-url="${WORKERS_STACK_URL}" \
- --region "${REGION}" \
- --stack-name "${WORKERS_STACK_NAME}" \
- --capabilities CAPABILITY_IAM \
- --parameters \
- ParameterKey=ClusterName,ParameterValue="${CLUSTER_NAME}" \
- ParameterKey=ClusterControlPlaneSecurityGroup,ParameterValue="${EKS_SECURITY_GROUP}" \
- ParameterKey=NodeGroupName,ParameterValue="crossplane-eks-nodes" \
- ParameterKey=NodeAutoScalingGroupMinSize,ParameterValue=1 \
- ParameterKey=NodeAutoScalingGroupDesiredCapacity,ParameterValue=1 \
- ParameterKey=NodeInstanceType,ParameterValue="m3.medium" \
- ParameterKey=NodeImageId,ParameterValue="${NODE_IMAGE_ID}" \
- ParameterKey=KeyName,ParameterValue="${KEY_PAIR}" \
- ParameterKey=VpcId,ParameterValue="${VPC_ID}" \
- ParameterKey=Subnets,ParameterValue="${SUBNET_IDS//,/\,}"
-```
-
-The output will look like:
-
->```bash
->{
-> "StackId": "arn:aws:cloudformation:eu-west-1:123456789012:stack/aws-service-example-stack 5730d720-d9d9-11e9-8662-029e8e947a9c"
->}
->```
-
-Similar to the VPC stack, creating the workers stack continues in the background
-and could take a few minutes to complete. You can check its status by running:
-
-```bash
-aws cloudformation describe-stacks --output json --stack-name ${WORKERS_STACK_NAME} --region ${REGION} | jq -r '.Stacks[0].StackStatus'
-```
-
-Once the output of the above command is `CREATE_COMPLETE`, all worker nodes are
-created. Now we need to tell the EKS cluster to let worker nodes with a certain
-role join the cluster. First let's retrieve the worker node role from the stack
-we just created: and then add that role to the **aws-auth** config map:
-
-```bash
-NODE_INSTANCE_ROLE=$(aws cloudformation describe-stacks --output json --stack-name ${WORKERS_STACK_NAME} --region ${REGION} | jq -r '.Stacks[0].Outputs[]|select(.OutputKey=="NodeInstanceRole").OutputValue')
-
-cat > aws-auth-cm.yaml <```bash
-> configmap/aws-auth created
-> ```
-
-Now, you can monitor that worker nodes (in this case only a single node) join
-the cluster:
-
-```bash
-kubectl get nodes
-```
-
->```bash
-> NAME STATUS ROLES AGE VERSION
-> ip-192-168-104-194.eu-west-1.compute.internal NotReady 8s v1.14.6-eks-5047ed
->```
-
-After a few minutes, the `NotReady` status above should become `Ready`.
-
-Congratulations! You have successfully setup and configured your EKS cluster!
-
-### Set Up RDS Configurations
-
-In AWS an RDS database instance will be provisioned to satisfy WordPress
-application's `MySQLInstanceClass` claim. In this section we create the required
-configurations in order to make an RDS instance accessible by the EKS cluster.
-
-#### RDS Security Group
-
-A security group should be created and assigned to the RDS, so certain traffic
-from the EKS cluster is allowed.
-
-```bash
-# an arbitrary name for the security group
-RDS_SG_NAME="crossplane-example-rds-sg"
-
-# generate the security group
-aws ec2 create-security-group \
- --vpc-id="${VPC_ID}" \
- --region="${REGION}" \
- --group-name="${RDS_SG_NAME}" \
- --description="open mysql access for crossplane-example cluster"
-
-# retrieve the ID for this security group
-RDS_SECURITY_GROUP_ID=$(aws ec2 describe-security-groups --filter Name=group-name,Values="${RDS_SG_NAME}" --region="${REGION}" --output=text --query="SecurityGroups[0].GroupId")
-```
-
-After creating the security group, we add a rule to allow traffic on `MySQL`
-port
-
-```bash
-aws ec2 authorize-security-group-ingress \
- --group-id="${RDS_SECURITY_GROUP_ID}" \
- --protocol=tcp \
- --port=3306 \
- --region="${REGION}" \
- --cidr=0.0.0.0/0 > /dev/null
-```
-
-#### RDS Subnet Group
-
-A **DB Subnet Group** is needed to associate the RDS instance with different
-subnets and availability zones.
-
-```bash
-# an arbitrary name for the db subnet group
-DB_SUBNET_GROUP_NAME=crossplane-example-dbsubnetgroup
-
-# convert subnets to a white space separated list
-# to satisfy the command input format below
-SUBNETS_LIST="${SUBNET_IDS//,/ }"
-
-aws rds create-db-subnet-group \
- --region="${REGION}" \
- --db-subnet-group-name="${DB_SUBNET_GROUP_NAME}" \
- --db-subnet-group-description="crossplane-example db subnet group" \
- --subnet-ids $SUBNETS_LIST > /dev/null
-```
-
-These resources will later be used to create cloud-specific MySQL resources.
-
-### Set Up Crossplane
-
-Using the newly provisioned cluster:
-
-1. Install Crossplane from alpha channel. (See the [Crossplane Installation
- Guide][crossplane-install] for more information.)
-
-```bash
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-2. Install the AWS stack into Crossplane. (See the [AWS stack
- section][aws-stack-install] of the install guide for more information.)
-
-```yaml
-cat > stack-aws.yaml < aws-infra-dev-namespace.yaml < namespace/aws-infra-dev created
-
-#### AWS Provider
-
-It is essential to make sure that the AWS user credentials are configured in
-Crossplane as a provider. Please follow the steps [provider
-guide][aws-provider-guide] for more information.
-
-#### Cloud-Specific Resource Classes
-
-Cloud-specific resource classes are used to define a reusable configuration for
-a specific managed resource. Wordpress requires a MySQL database, which can be
-satisfied by an [AWS RDS][aws-rds] instance.
-
-* Define an AWS RDS `RDSInstanceClass` in `aws-mysql-standard.yaml` and
- create it:
-
-```yaml
-cat > aws-mysql-standard.yaml < rdsinstanceclass.database.aws.crossplane.io/aws-mysql-standard created
-
-* You can verify creation with the following command and output:
-
-```bash
-$ kubectl get rdsinstanceclass -n aws-infra-dev
-NAME PROVIDER-REF RECLAIM-POLICY AGE
-aws-mysql-standard aws-provider Delete 11s
-```
-
-You are free to create more AWS `RDSInstanceClass` instances to define more
-potential configurations. For instance, you may create `large-aws-rds` with
-field `size: 100`.
-
-#### Application Namespaces
-
-Earlier, we created a namespace to group our AWS infrastructure resources.
-Because our application resources may be satisfied by services from any cloud
-provider, we want to separate them into their own namespace. For this demo, we
-will create a namespace called `app-project1-dev`, which we will use to group
-our Wordpress resources.
-
-* Define a `Namespace` in `app-project1-dev-namespace.yaml` and create it:
-
- ```yaml
- cat > app-project1-dev-namespace.yaml < namespace/app-project1-dev created
-
-#### Portable Resource Classes
-
-Portable resource classes are used to define a class of service in a single
-namespace for an abstract service type. We want to define our AWS
-`RDSInstanceClass` as the standard MySQL class of service in the namespace that
-our Wordpress resources will live in.
-
-* Define a `MySQLInstanceClass` in `mysql-standard.yaml` for namespace
- `app-project1-dev` and create it:
-
- ```yaml
- cat > mysql-standard.yaml < mysqlinstanceclass.database.crossplane.io/mysql-standard created
-
-* You can verify creation with the following command and output:
-
- ```bash
- $ kubectl get mysqlinstanceclasses -n app-project1-dev
- NAME AGE
- mysql-standard 27s
- ```
-
-Once again, you are free to create more `MySQLInstanceClass` instances in this
-namespace to define more classes of service. For instance, if you created
-`mysql-aws-large` above, you may want to create a `MySQLInstanceClass` named
-`mysql-large` that references it. You may also choose to create MySQL resource
-classes for other non-AWS providers, and reference them for a class of service
-in the `app-project1-dev` namespace.
-
-You may specify *one* instance of a portable class kind as *default* in each
-namespace. This means that the portable resource class instance will be applied
-to claims that do not directly reference a portable class. If we wanted to make
-our `mysql-standard` instance the default `MySQLInstanceClass` for namespace
-`app-project1-dev`, we could do so by adding a label:
-
-```yaml
----
-apiVersion: database.crossplane.io/v1alpha1
-kind: MySQLInstanceClass
-metadata:
- name: mysql-standard
- namespace: app-project1-dev
- labels:
- default: "true"
-classRef:
- kind: RDSInstanceClass
- apiVersion: database.aws.crossplane.io/v1alpha2
- name: aws-mysql-standard
- namespace: aws-infra-dev
-```
-
-#### Resource Claims
-
-Resource claims are used to create external resources by referencing a class of
-service in the claim's namespace. When a claim is created, Crossplane uses the
-referenced portable class to find a cloud-specific resource class to use as the
-configuration for the external resource. We need a to create a claim to
-provision the RDS database we will use with AWS.
-
-* Define a `MySQLInstance` claim in `mysql-claim.yaml` and create it:
-
- ```yaml
- cat > mysql-claim.yaml <
-Annotations: kubectl.kubernetes.io/last-applied-configuration:
- {"apiVersion":"database.crossplane.io/v1alpha1","kind":"MySQLInstance","metadata":{"annotations":{},"name":"mysql-claim","namespace":"team..."}}
-API Version: database.crossplane.io/v1alpha1
-Kind: MySQLInstance
-Metadata:
- Creation Timestamp: 2019-09-16T13:46:42Z
- Finalizers:
- finalizer.resourceclaim.crossplane.io
- Generation: 2
- Resource Version: 4256
- Self Link: /apis/database.crossplane.io/v1alpha1/namespaces/app-project1-dev/mysqlinstances/mysql-claim
- UID: 6a7fe064-d888-11e9-ab90-42b6bb22213a
-Spec:
- Class Ref:
- Name: mysql-standard
- Engine Version: 5.6
- Resource Ref:
- API Version: database.aws.crossplane.io/v1alpha2
- Kind: MysqlServer
- Name: mysqlinstance-6a7fe064-d888-11e9-ab90-42b6bb22213a
- Namespace: aws-infra-dev
- Write Connection Secret To Ref:
- Name: wordpressmysql
-Status:
- Conditions:
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Managed claim is waiting for managed resource to become bindable
- Status: False
- Type: Ready
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Successfully reconciled managed resource
- Status: True
- Type: Synced
-Events:
-```
-
-*Note: You must wait until the claim becomes bound before continuing with this
-guide. It could take up to a few minutes.*
-
-We referenced our portable `MySQLInstanceClass` directly in the claim above, but
-if you specified that `mysql-standard` was the default `MySQLInstanceClass` for
-namespace `app-project1-dev`, we could have omitted the claim's `classRef` and
-it would automatically be assigned:
-
-```yaml
-apiVersion: database.crossplane.io/v1alpha1
-kind: MySQLInstance
-metadata:
- name: mysql-claim
- namespace: app-project1-dev
-spec:
- writeConnectionSecretToRef:
- name: wordpressmysql
- engineVersion: "5.6"
-```
-
-## Install Wordpress
-
-Installing Wordpress requires creating a Kubernetes `Deployment` and load
-balancer `Service`. We will point the deployment to the `wordpressmysql` secret
-that we specified in our claim above for the Wordpress container environment
-variables. It should have been populated with our MySQL connection details after
-the claim became `Bound`.
-
-* Check to make sure `wordpressmysql` exists and is populated:
-
- ```bash
- $ kubectl describe secret wordpressmysql -n app-project1-dev
- Name: wordpressmysql
- Namespace: app-project1-dev
- Labels:
- Annotations:
-
- Type: Opaque
-
- Data
- ====
- endpoint: 75 bytes
- password: 27 bytes
- username: 58 bytes
- ```
-
-* Define the `Deployment` and `Service` in `wordpress-app.yaml` and create it:
-
- ```yaml
- cat > wordpress-app.yaml <`, wait until it
-becomes available, then navigate to the address. You should see the following:
-
-
-
-## Uninstall
-
-### Wordpress
-
-All Wordpress components that we installed can be deleted with one command:
-
-```bash
-kubectl delete -f wordpress-app.yaml
-```
-
-### Crossplane Configuration
-
-To delete all created resources, but leave Crossplane and the AWS stack
-running, execute the following commands:
-
-```bash
-kubectl delete -f mysql-claim.yaml
-kubectl delete -f mysql-standard.yaml
-kubectl delete -f aws-mysql-standard.yaml
-kubectl delete -f app-project1-dev-namespace.yaml
-kubectl delete -f aws-infra-dev-namespace.yaml
-```
-
-### AWS Resources
-We will also need to delete the resources that we created for the RDS database
-and EKS cluster:
-
-```bash
-# delete the db subnet group
-aws rds delete-db-subnet-group \
- --region "${REGION}" \
- --db-subnet-group-name="${DB_SUBNET_GROUP_NAME}"
-
-# delete the security group for RDS
-aws ec2 delete-security-group \
- --region "${REGION}" \
- --group-id="${RDS_SECURITY_GROUP_ID}"
-
-# delete the CloudFormation Stack for worker nodes
-aws cloudformation delete-stack \
- --region "${REGION}" \
- --stack-name "${WORKERS_STACK_NAME}"
-
-# delete the key-pair for worker nodes
-aws ec2 delete-key-pair --key-name "${KEY_PAIR}"
-
-# delete the EKS cluster
-aws eks delete-cluster \
- --region "${REGION}" \
- --name "${CLUSTER_NAME}"
-
-# detach role policies
-aws iam detach-role-policy \
- --role-name "${EKS_ROLE_NAME}" \
- --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
-aws iam detach-role-policy \
- --role-name "${EKS_ROLE_NAME}" \
- --policy-arn arn:aws:iam::aws:policy/AmazonEKSServicePolicy
-
-# delete the cluster role
-aws iam delete-role --role-name "${EKS_ROLE_NAME}"
-
-# delete the CloudFormation Stack for vpc
-# this should be executed once all previous stes are completed
-aws cloudformation delete-stack \
- --region "${REGION}" \
- --stack-name "${VPC_STACK_NAME}"
-
-# delete clusters config file
-rm "${KUBECONFIG}"
-```
-
-## Conclusion and Next Steps
-
-In this guide we:
-
-* Setup an EKS Cluster using the AWS CLI
-* Configured RDS to communicate with EKS
-* Installed Crossplane from the alpha channel
-* Installed the AWS stack
-* Created an infrastructure (`aws-infra-dev`) and application
- (`app-project1-dev`) namespace
-* Setup an AWS `Provider` with our account
-* Created a `RDSInstanceClass` in the ` with configuration using RDS configuration earlier
-* Created a `MySQLInstanceClass` that specified the `RDSInstanceClass` as
- `mysql-standard` in the `app-project1-dev` namespace
-* Created a `MySQLInstance` claim in the `app-project1-dev1` namespace that
- referenced `mysql-standard`
-* Created a `Deployment` and `Service` to run Wordpress on our EKS Cluster and
- assign an external IP address to it
-
-If you would like to try out a similar workflow using a different cloud
-provider, take a look at the other [services guides][services]. If you would like
-to learn more about stacks, checkout the [stacks guide][stacks]
-
-
-[aws-create-eks]: https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html
-[sample-cf-stack]: https://docs.aws.amazon.com/eks/latest/userguide/create-public-private-vpc.html
-[sample-workernodes-stack]: https://docs.aws.amazon.com/eks/latest/userguide/launch-workers.html
-[aws-cli-install]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html
-[aws-cli-configure]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html
-[aws-key-pair]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html
-[install-kubectl]: https://kubernetes.io/docs/tasks/tools/install-kubectl/
-[using-helm]: https://docs.helm.sh/using_helm/
-[jq-docs]: https://stedolan.github.io/jq/
-[crossplane-install]: ../install-crossplane.md#alpha
-[cloud-creds]: ../cloud-providers.md
-[aws-provider-guide]: ../cloud-providers/aws/aws-provider.md
-[aws-rds]: https://aws.amazon.com/rds/
-[services]: ../services-guide.md
-[stacks]: ../stacks-guide.md
-[aws-stack-install]: ../install-crossplane.md#aws-stack
diff --git a/docs/v0.3/services/azure-services-guide.md b/docs/v0.3/services/azure-services-guide.md
deleted file mode 100644
index de5bc29d..00000000
--- a/docs/v0.3/services/azure-services-guide.md
+++ /dev/null
@@ -1,680 +0,0 @@
----
-title: Using Azure Services
-toc: true
-weight: 440
-indent: true
----
-# Deploying Wordpress in Azure
-
-This user guide will walk you through Wordpress application deployment using
-Crossplane managed resources and the official Wordpress Docker image.
-
-## Table of Contents
-
-1. [Pre-requisites](#pre-requisites)
-2. [Preparation](#preparation)
-3. [Set Up AKS Cluster](#set-up-aks-cluster)
-4. [Set Up Crossplane](#set-up-crossplane)
-5. [Install Wordpress](#install-wordpress)
-6. [Uninstall](#uninstall)
-7. [Conclusion and Next Steps](#conclusion-and-next-steps)
-
-## Pre-requisites
-
-These tools are required to complete this guide. They must be installed on your
-local machine.
-
-* [Azure CLI][azure-cli]
- * Make sure to [login][azure-login] after installation.
-* [kubectl][install-kubectl]
- * kubectl also be installed using the Azure CLI: `az aks install-cli`
-* [Helm][using-helm], minimum version `v2.10.0+`.
-* [jq][jq-docs] - command line JSON processor `v1.5+`
-
-
-## Preparation
-
-This guide assumes that you have setup the Azure CLI and are logged in to your
-desired account.
-
-*Note: environment variables are used throughout this guide. You may use the
-values below or create your own.*
-
-```bash
-export RESOURCE_GROUP_NAME=myResourceGroup
-export RESOURCE_GROUP_LOCATION=eastus
-export AKS_NAME=myAKSCluster
-export AKS_NODE_COUNT=1
-export AKS_RESOURCE_GROUP=MC_${RESOURCE_GROUP_NAME}_${AKS_NAME}_${RESOURCE_GROUP_LOCATION}
-export SUBSCRIPTION_ID=$(az account list | jq -j '.[0].id')
-```
-
-### Set Up AKS Cluster
-
-Azure maintains a succinct [walkthrough][aks-walkthrough] for setting up an AKS
-cluster using the Azure CLI. The basic steps are as follows:
-
-1. Create a Resource Group
-```bash
-az group create --name $RESOURCE_GROUP_NAME --location $RESOURCE_GROUP_LOCATION
-```
-
-2. Create AKS Cluster (this may take a few minutes)
-```bash
-az aks create \
- --resource-group $RESOURCE_GROUP_NAME \
- --name $AKS_NAME \
- --node-count $AKS_NODE_COUNT \
- --enable-addons monitoring \
- --generate-ssh-keys
-```
-
-3. Enable SQL Service Endpoint
-
-Get name of AKS node Virtual Network:
-```bash
-export AKS_VNET=$(az network vnet list -g $AKS_RESOURCE_GROUP | jq -j '.[0].name')
-```
-
-Add Service Endpoint to AKS subnet:
-```bash
-az network vnet subnet update -g $AKS_RESOURCE_GROUP --vnet-name $AKS_VNET -n aks-subnet --service-endpoints Microsoft.Sql
-```
-
-4. Connect to AKS Cluster
-```bash
-az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $AKS_NAME
-```
-
-5. Make sure `kubectl` is able to communicate with AKS Cluster
-```bash
-kubectl cluster-info
-```
-
-### Set Up Crossplane
-
-Using the newly provisioned cluster:
-
-1. Install Crossplane from alpha channel. (See the [Crossplane Installation
- Guide][crossplane-install] for more information.)
-
-```bash
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-2. Install the Azure stack into Crossplane. (See the [Azure stack
- section][azure-stack-install] of the install guide for more information.)
-
-```yaml
-cat > stack-azure.yaml < azure-infra-dev.yaml < namespace/azure-infra-dev.yaml created
-
-#### Azure Provider
-
-It is essential to make sure that the Azure Service Principal is configured with
-all permissions outlined in the [provider guide][azure-provider-guide].
-
-Using Azure Service Principal `crossplane-azure-provider-key.json`:
-
-* Generate BASE64ENCODED_AZURE_PROVIDER_CREDS encoded value:
-
-```bash
-export BASE64ENCODED_AZURE_PROVIDER_CREDS=$(base64 crossplane-azure-provider-key.json | tr -d "\n")
-```
-
-* Define an Azure `Provider` and `Secret` in `azure-provider.yaml` and create
- them:
-
-```yaml
-cat > azure-provider.yaml < azure-mysql-standard.yaml < sqlserverclass.database.azure.crossplane.io/azure-mysql-standard created
-
-
-* You can verify creation with the following command and output:
-
-```bash
-$ kubectl get sqlserverclasses -n azure-infra-dev
-NAME PROVIDER-REF RECLAIM-POLICY AGE
-azure-mysql-standard demo-azure Delete 11s
-```
-
-You are free to create more Azure `SQLServerClass` instances to define more
-potential configurations. For instance, you may create `large-azure-mysql` with
-field `storageGB: 100`.
-
-#### Application Namespaces
-
-Earlier, we created a namespace to group our Azure infrastructure resources.
-Because our application resources may be satisfied by services from any cloud
-provider, we want to separate them into their own namespace. For this demo, we
-will create a namespace called `app-project1-dev`, which we will use to group
-our Wordpress resources.
-
-* Define a `Namespace` in `app-project1-dev-namespace.yaml` and create it:
-
-```yaml
-cat > app-project1-dev-namespace.yaml < namespace/app-project1-dev created
-
-#### Portable Resource Classes
-
-Portable resource classes are used to define a class of service in a single
-namespace for an abstract service type. We want to define our Azure
-`SQLServerClass` as the standard MySQL class of service in the namespace that
-our Wordpress resources will live in.
-
-* Define a `MySQLInstanceClass` in `mysql-standard.yaml` for namespace
- `app-project1-dev` and create it:
-
-```yaml
-cat > mysql-standard.yaml < mysqlinstanceclass.database.crossplane.io/mysql-standard created
-
-* You can verify creation with the following command and output:
-
-```bash
-$ kubectl get mysqlinstanceclasses -n app-project1-dev
-NAME AGE
-mysql-standard 27s
-```
-
-Once again, you are free to create more `MySQLInstanceClass` instances in this
-namespace to define more classes of service. For instance, if you created
-`mysql-azure-large` above, you may want to create a `MySQLInstanceClass` named
-`mysql-large` that references it. You may also choose to create MySQL resource
-classes for other non-Azure providers, and reference them for a class of service
-in the `app-project1-dev` namespace.
-
-You may specify *one* instance of a portable class kind as *default* in each
-namespace. This means that the portable resource class instance will be applied
-to claims that do not directly reference a portable class. If we wanted to make
-our `mysql-standard` instance the default `MySQLInstanceClass` for namespace
-`app-project1-dev`, we could do so by adding a label:
-
-```yaml
----
-apiVersion: database.crossplane.io/v1alpha1
-kind: MySQLInstanceClass
-metadata:
- name: mysql-standard
- namespace: app-project1-dev
- labels:
- default: "true"
-classRef:
- kind: SQLServerClass
- apiVersion: database.azure.crossplane.io/v1alpha2
- name: azure-mysql-standard
- namespace: azure-infra-dev
-```
-
-#### Resource Claims
-
-Resource claims are used to create external resources by referencing a class of
-service in the claim's namespace. When a claim is created, Crossplane uses the
-referenced portable class to find a cloud-specific resource class to use as the
-configuration for the external resource. We need a to create a claim to
-provision the MySQL database we will use with Azure.
-
-* Define a `MySQLInstance` claim in `mysql-claim.yaml` and create it:
-
-```yaml
-cat > mysql-claim.yaml <
-Annotations: kubectl.kubernetes.io/last-applied-configuration:
- {"apiVersion":"database.crossplane.io/v1alpha1","kind":"MySQLInstance","metadata":{"annotations":{},"name":"mysql-claim","namespace":"team..."}}
-API Version: database.crossplane.io/v1alpha1
-Kind: MySQLInstance
-Metadata:
- Creation Timestamp: 2019-09-16T13:46:42Z
- Finalizers:
- finalizer.resourceclaim.crossplane.io
- Generation: 2
- Resource Version: 4256
- Self Link: /apis/database.crossplane.io/v1alpha1/namespaces/app-project1-dev/mysqlinstances/mysql-claim
- UID: 6a7fe064-d888-11e9-ab90-42b6bb22213a
-Spec:
- Class Ref:
- Name: mysql-standard
- Engine Version: 5.6
- Resource Ref:
- API Version: database.azure.crossplane.io/v1alpha2
- Kind: MysqlServer
- Name: mysqlinstance-6a7fe064-d888-11e9-ab90-42b6bb22213a
- Namespace: azure-infra-dev
- Write Connection Secret To Ref:
- Name: wordpressmysql
-Status:
- Conditions:
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Managed claim is waiting for managed resource to become bindable
- Status: False
- Type: Ready
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Successfully reconciled managed resource
- Status: True
- Type: Synced
-Events:
-```
-
-*Note: You must wait until the claim becomes bound before continuing with this
-guide. It could take a few minutes for Azure to complete MySQL creation.*
-
-We referenced our portable `MySQLInstanceClass` directly in the claim above, but
-if you specified that `mysql-standard` was the default `MySQLInstanceClass` for
-namespace `app-project1-dev`, we could have omitted the claim's `classRef` and
-it would automatically be assigned:
-
-```yaml
-apiVersion: database.crossplane.io/v1alpha1
-kind: MySQLInstance
-metadata:
- name: mysql-claim
- namespace: app-project1-dev
-spec:
- writeConnectionSecretToRef:
- name: wordpressmysql
- engineVersion: "5.6"
-```
-
-#### Virtual Network Rule
-
-Before we install Wordpress, we need establish connectivity between our MySQL
-database and our AKS cluster. We can do this by creating a [Virtual Network
-Rule][azure-vnet-rule].
-
-* Set `MYSQL_NAME` environment variable:
-
-```bash
-export MYSQL_NAME=$(kubectl get -o json mysqlinstance mysql-claim -n app-project1-dev | jq -j '.spec.resourceRef.name')
-```
-
-* Define a `MysqlServerVirtualNetworkRule` in `wordpress-vnet-rule.yaml` and
- create it:
-
-```yaml
-cat > wordpress-vnet-rule.yaml <
-Annotations:
-
-Type: Opaque
-
-Data
-====
-endpoint: 75 bytes
-password: 27 bytes
-username: 58 bytes
-```
-
-* Define the `Deployment` and `Service` in `wordpress-app.yaml` and create it:
-
-```yaml
-cat > wordpress-app.yaml <`, wait until it
-becomes available, then navigate to the address. You should see the following:
-
-
-
-## Uninstall
-
-### Wordpress
-
-All Wordpress components that we installed can be deleted with one command:
-
-```bash
-kubectl delete -f wordpress-app.yaml
-```
-
-### Crossplane Configuration
-
-To delete all created resources, but leave Crossplane and the Azure stack
-running, execute the following commands:
-
-```bash
-kubectl delete -f wordpress-vnet-rule.yaml
-kubectl delete -f mysql-claim.yaml
-kubectl delete -f mysql-standard.yaml
-kubectl delete -f azure-mysql-standard.yaml
-kubectl delete -f app-project1-dev-namespace.yaml
-kubectl delete -f azure-provider.yaml
-kubectl delete -f azure-infra-dev-namespace.yaml
-```
-
-## Conclusion and Next Steps
-
-In this guide we:
-
-* Setup an AKS Cluster using the Azure CLI
-* Installed Crossplane from alpha channel
-* Installed the Azure stack
-* Created an infrastructure (`azure-infra-dev`) and application
- (`app-project1-dev`) namespace
-* Setup an Azure `Provider` with our account
-* Created a `SQLServerClass` in the ` with configuration for a MySQL database on
- Azure
-* Created a `MySQLInstanceClass` that specified the `SQLServerClass` as
- `mysql-standard` in the `app-project1-dev` namespace
-* Created a `MySQLInstance` claim in the `app-project1-dev1` namespace that
- referenced `mysql-standard`
-* Created a `MysqlServerVirtualNetworkRule` to establish secure connectivity
- between our AKS Cluster and MySQL database
-* Created a `Deployment` and `Service` to run Wordpress on our AKS Cluster and
- assign an external IP address to it
-
-If you would like to try out a similar workflow using a different cloud
-provider, take a look at the other [services guides][services]. If you would like
-to learn more about stacks, checkout the [stacks guide][stacks]
-
-
-[azure-cli]: https://docs.microsoft.com/en-us/cli/azure/?view=azure-cli-latest
-[azure-login]: https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli?view=azure-cli-latest
-[install-kubectl]: https://kubernetes.io/docs/tasks/tools/install-kubectl/
-[using-helm]: https://docs.helm.sh/using_helm/
-[jq-docs]: https://stedolan.github.io/jq/
-
-[aks-walkthrough]: https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough
-
-[crossplane-install]: ../install-crossplane.md#alpha
-[azure-stack-install]: ../install-crossplane.md#azure-stack
-[cloud-creds]: ../cloud-providers.md
-
-[azure-provider-guide]: ../cloud-providers/azure/azure-provider.md
-
-[azure-mysql]: https://azure.microsoft.com/en-us/services/mysql/
-[azure-vnet-rule]: https://docs.microsoft.com/en-us/azure/mysql/concepts-data-access-and-security-vnet
-
-[services]: ../services-guide.md
-[stacks]: ../stacks-guide.md
diff --git a/docs/v0.3/services/gcp-services-guide.md b/docs/v0.3/services/gcp-services-guide.md
deleted file mode 100644
index b5fb3c84..00000000
--- a/docs/v0.3/services/gcp-services-guide.md
+++ /dev/null
@@ -1,641 +0,0 @@
----
-title: Using GCP Services
-toc: true
-weight: 420
-indent: true
----
-
-# GCP Services Guide
-
-## Table of Contents
-
-1. [Introduction](#introduction)
-2. [Pre-requisites](#pre-requisites)
-3. [Preparation](#preparation)
- 1. [GKE Cluster Steps](#gke-cluster-steps)
- 2. [Crossplane Steps](#crossplane-steps)
- 1. [Installation](#installation)
- 2. [GCP Provider](#gcp-provider)
- 3. [Cloud Specific Resource Classes](#cloud-specific-resource-classes)
- 4. [Namespaces](#namespaces)
- 5. [Portable Resource Classes](#portable-resource-classes)
- 6. [Connecting MySQL Instance and GKE Cluster](#connecting-mysql-instance-and-gke-cluster)
-4. [Install Wordpress](#install-wordpress)
-5. [Clean Up](#clean-up)
- 1. [Wordpress](#wordpress)
- 2. [Crossplane](#crossplane)
-
-## Introduction
-
-This user guide will walk you through Wordpress application deployment using
-your existing Kubernetes cluster and Crossplane managed resources. We will:
-* Install Crossplane to your cluster.
-* Create necessary resource classes for MySQL database instance.
-* Create network resources to get GKE cluster to connect to MySQL instance.
-* Deploy Wordpress.
-
-## Pre-requisites
-
-* [gcloud CLI](https://cloud.google.com/sdk/docs/quickstarts)
- * Make sure to configure the authentication after installing gcloud cli.
-* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
-* A GKE cluster.
-
-## Preparation
-
-This guide assumes that you have setup the gcloud CLI and are logged in to your
-desired account.
-
-*Note: environment variables are used throughout this guide. You should use
-your own values.*
-
-Run the following:
-```bash
-export PROJECT_ID=crossplane-playground # the project that all resources reside.
-export NETWORK_NAME=default # the network that your GKE cluster lives in.
-export SUBNETWORK_NAME=default # the subnetwork that your GKE cluster lives in.
-```
-
-### GKE Cluster Steps
-
-We are assuming you've got a GKE cluster up and running created either via
-GCP Console or gcloud CLI. If you don't, the basic command to create one is
-the following:
-
-1. Create a GKE cluster:
-```bash
-gcloud beta container --project "${PROJECT_ID}" clusters create "my-existing-cluster" \
- --zone "us-central1-a" \
- --cluster-version "1.13.7-gke.8" \
- --machine-type "n1-standard-1" \
- --image-type "COS" \
- --disk-type "pd-standard" \
- --disk-size "100" \
- --metadata disable-legacy-endpoints=true \
- --scopes "https://www.googleapis.com/auth/devstorage.read_only","https://www.googleapis.com/auth/logging.write","https://www.googleapis.com/auth/monitoring","https://www.googleapis.com/auth/servicecontrol","https://www.googleapis.com/auth/service.management.readonly","https://www.googleapis.com/auth/trace.append" \
- --num-nodes "1" \
- --enable-cloud-logging --enable-cloud-monitoring --enable-ip-alias --enable-autoupgrade --enable-autorepair --no-enable-basic-auth \
- --network "projects/${PROJECT_ID}/global/networks/${NETWORK_NAME}" \
- --subnetwork "projects/${PROJECT_ID}/regions/us-central1/subnetworks/${SUBNETWORK_NAME}" \
- --default-max-pods-per-node "110" \
- --addons HorizontalPodAutoscaling,HttpLoadBalancing
-```
-
-This may take a while to finish.
-
-2. Connect to your GKE cluster
-```bash
-gcloud container clusters get-credentials "my-existing-cluster" --zone us-central1-a --project "${PROJECT_ID}"
-```
-
-3. Make sure `kubectl` is able to communicate with your GKE cluster
-```bash
-kubectl cluster-info
-```
-4. Make sure Helm is installed with permissions to work on `crossplane-system`
-namespace. The easiest way to achieve that is to run the following command
-that makes Helm's server side component `tiller` cluster admin:
-```bash
-kubectl -n kube-system create serviceaccount tiller
-kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller
-helm init --service-account=tiller
-```
-
-### Crossplane Steps
-
-#### Installation
-
-* Install Crossplane from alpha channel using the [Crossplane Installation
- Guide](../install-crossplane.md#alpha)
-* Install the GCP stack into Crossplane using the [GCP stack
- section](../install-crossplane.md#gcp-stack) of the install guide.
-
-We will be using `gcp-infra-dev` namespace to store our cloud-specific resource
-classes, cloud resources and providers. But you can use any namespace name for
-that matter.
-```bash
-kubectl create namespace gcp-infra-dev
-export INFRA_NAMESPACE=gcp-infra-dev
-```
-
-#### GCP Provider
-
-It is essential to make sure that a GCP service account to be used by
-Crossplane is configured with all the necessary permissions outlined in the
-[provider guide](../cloud-providers/gcp/gcp-provider.md).
-
-Using the service account json `crossplane-gcp-provider-key.json` that you
-acquired from GCP:
-
-* Generate Base64 encoded value to store in a `Secret`:
-
- ```bash
- export BASE64ENCODED_GCP_PROVIDER_CREDS=$(base64 crossplane-gcp-provider-key.json | tr -d "\n")
- ```
-
- * Define a GCP `Provider` and `Secret`:
-
- ```bash
- cat > gcp-provider.yaml < gcp-mysql-standard.yaml < mysql-standard.yaml < Portable classes are the resource classes that are not cloud specific and
-their purpose is to refer to cloud specific resource classes that will be
-used for provisioning. For example, MySQLInstanceClass is a portable class
-that can refer to CloudsqlInstanceClass (GCP) or RDSInstanceClass (AWS).
-
-You may specify *one* instance of a portable class kind as *default* in each
-namespace. This means that the portable resource class instance will be applied
-to claims that do not directly reference a portable class. If we wanted to make
-our `mysql-standard` instance the default `MySQLInstanceClass` for namespace
-`app-project1-dev`, we could do so by adding a label:
-
-```bash
-kubectl -n app-project1-dev label mysqlinstanceclass mysql-standard default="true"
-```
-For more details about resource classes in Crossplane, see
-[Default Resource Classes One-Pager](https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-default-resource-class.md).
-
-#### Resource Claims
-
-Resource claims are used to create external resources by referencing a class of
-service in the claim's namespace. When a claim is created, Crossplane uses the
-referenced portable class to find a cloud-specific resource class to use as the
-configuration for the external resource. We need to create a claim to
-provision the MySQL database we will use in GCP.
-
-* Define a `MySQLInstance` claim in `mysql-claim.yaml`.
-You can omit `spec.classRef` if you want to use the default MySQLInstanceClass:
-
- ```bash
- cat > mysql-claim.yaml <
-Annotations: kubectl.kubernetes.io/last-applied-configuration:
- {"apiVersion":"database.crossplane.io/v1alpha1","kind":"MySQLInstance","metadata":{"annotations":{},"name":"mysql-claim","namespace":"team..."}}
-API Version: database.crossplane.io/v1alpha1
-Kind: MySQLInstance
-Metadata:
- Creation Timestamp: 2019-09-16T13:46:42Z
- Finalizers:
- finalizer.resourceclaim.crossplane.io
- Generation: 2
- Resource Version: 4256
- Self Link: /apis/database.crossplane.io/v1alpha1/namespaces/app-project1-dev/mysqlinstances/mysql-claim
- UID: 6a7fe064-d888-11e9-ab90-42b6bb22213a
-Spec:
- Class Ref:
- Name: mysql-standard
- Engine Version: 5.6
- Resource Ref:
- API Version: database.gcp.crossplane.io/v1alpha2
- Kind: CloudsqlInstance
- Name: mysqlinstance-6a7fe064-d888-11e9-ab90-42b6bb22213a
- Namespace: gcp-infra-dev
- Write Connection Secret To Ref:
- Name: wordpressmysql
-Status:
- Conditions:
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Managed claim is waiting for managed resource to become bindable
- Status: False
- Type: Ready
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Successfully reconciled managed resource
- Status: True
- Type: Synced
-Events:
-```
-
-*Note: You must wait until the claim becomes bound before continuing with this
-guide. It could take a few minutes for GCP to complete CloudSQL creation.*
-
-#### Connecting MySQL Instance and GKE Cluster
-
-Before we install Wordpress, we need to establish connectivity between our MySQL
-database and our GKE cluster. We can do this by creating a [Private Service
-Connection](https://cloud.google.com/vpc/docs/configure-private-services-access).
-
-You can create it by following the instructions at the link above, or you could
-use Crossplane to do it:
-
-* Create a `GlobalAddress` and `Connection` resources:
-
- ```bash
- cat > network.yaml < Binding status tells you whether your resource has been provisioned and ready
-to use. Crossplane binds the actual resource to the claim via changing the
-readiness condition to `Bound`. This happens only when the resource is ready
-to be consumed.
-
-* Check to make sure `wordpressmysql` exists and is populated:
-
-*Command*
-```bash
-kubectl -n app-project1-dev describe secret wordpressmysql
-```
-
-*Output*
-```bash
-Name: wordpressmysql
-Namespace: app-project1-dev
-Labels:
-Annotations:
-
-Type: Opaque
-
-Data
-====
-endpoint: 75 bytes
-password: 27 bytes
-username: 58 bytes
-```
-
-* Define the `Deployment` and `Service` in `wordpress.yaml`:
-
- ```bash
- cat > wordpress.yaml <`, wait until it
-becomes available, then navigate to the address. You should see the following:
-
-
-
-## Clean Up
-
-### Wordpress
-
-The `Service` and `Deployment` of Wordpress we installed can be removed with the following command:
-
-```bash
-kubectl -n app-project1-dev delete -f wordpress.yaml
-```
-
-### Crossplane
-
-To delete all created resources, but leave Crossplane and the GCP stack
-running, execute the following commands:
-
-```bash
-kubectl -n app-project1-dev delete -f mysql-claim.yaml
-kubectl -n app-project1-dev delete -f mysql-standard.yaml
-kubectl -n $INFRA_NAMESPACE delete -f network.yaml
-kubectl -n $INFRA_NAMESPACE delete -f gcp-mysql-standard.yaml
-kubectl -n $INFRA_NAMESPACE delete -f gcp-provider.yaml
-
-kubectl delete namespace app-project1-dev
-kubectl delete namespace $INFRA_NAMESPACE
-```
-
-## Conclusion
-
-We're done!
-
-In this guide, we:
-
-* Set up Crossplane on our GKE Cluster.
-* Installed Crossplane GCP Stack.
-* Created resource classes for MySQL database.
-* Provisioned a MySQL database on GCP using Crossplane.
-* Connected our GKE cluster to our MySQL database.
-* Installed Wordpress to our GKE cluster.
-
-## Next Steps
-
-In this guide, we used an existing GKE cluster but actually Crossplane can
-provision a Kubernetes cluster from GCP just like it provisions a MySQL
-database.
-
-We deployed Wordpress using bare `Deployment` and `Service` resources
-but there is actually a Wordpress App stack that creates these resources
-for us!
-
-Check out the [stack guides](link to stack guides page)!
-
-## References
-
-* [gcloud CLI](https://cloud.google.com/sdk/docs/quickstarts)
-* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
-* [Crossplane Installation Guide](../install-crossplane.md#alpha)
-* [GCP Stack Installation](../install-crossplane.md#gcp-stack)
-* [GCP Provider Guide](../cloud-providers/gcp/gcp-provider.md)
-* [Google Cloud SQL Instance](https://cloud.google.com/sql/docs/mysql/)
-* [Default Resource Classes One-Pager](https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-default-resource-class.md)
-* [Google Private Service Connection](https://cloud.google.com/vpc/docs/configure-private-services-access)
diff --git a/docs/v0.3/services/wordpress-start.png b/docs/v0.3/services/wordpress-start.png
deleted file mode 100644
index e21ad0f6..00000000
Binary files a/docs/v0.3/services/wordpress-start.png and /dev/null differ
diff --git a/docs/v0.3/stacks-guide-aws.md b/docs/v0.3/stacks-guide-aws.md
deleted file mode 100644
index 3b897246..00000000
--- a/docs/v0.3/stacks-guide-aws.md
+++ /dev/null
@@ -1,894 +0,0 @@
----
-title: "Stacks Guide: AWS Setup"
-toc: true
-weight: 530
-indent: true
----
-
-# Stacks Guide: AWS Setup
-
-## Table of Contents
-
- 1. [Introduction](#introduction)
- 1. [Install the AWS stack](#install-the-aws-stack)
- 1. [Configure the AWS account](#configure-the-aws-account)
- 1. [Configure Crossplane Provider for
- AWS](#configure-crossplane-provider-for-aws)
- 1. [Set Up Network Configuration](#set-up-network-configuration)
- 1. [Configure Provider Resources](#configure-provider-resources)
- 1. [Recap](#recap)
- 1. [Next Steps](#next-steps)
-
-## Introduction
-
-In this guide, we will set up an AWS provider in Crossplane so that we
-can install and use the [WordPress sample
-stack][sample-wordpress-stack], which depends on MySQL and Kubernetes!
-
-Before we begin, you will need:
-
-* Everything from the [Crossplane Stacks Guide][stacks-guide] before the
- cloud provider setup
- - A `kubectl` pointing to a Crossplane control cluster
- - The [Crossplane CLI][crossplane-cli] installed
-* An account on [AWS][aws]
-* The [aws cli][installed]
-
-At the end, we will have:
-
-* A Crossplane control cluster configured to use AWS
-* The boilerplate of an AWS-based project spun up
-* Support in the control cluster for managing MySQL and Kubernetes
- cluster dependencies
-* A slightly better understanding of:
- - The way cloud providers are configured in Crossplane
- - The way dependencies for cloud-portable workloads are configured in
- Crossplane
-
-## Install the AWS stack
-
-After Crossplane has been installed, it can be extended with more
-functionality by installing a [Crossplane Stack][stack-docs]! Let's
-install the [stack for Amazon Web Services][stack-aws] (AWS) to add
-support for that cloud provider.
-
-The namespace where we install the stack, is also the one that our managed AWS
-resources will reside. Let's call this namespace `infra-aws`, and go ahead and
-create it:
-
-```bash
-# the namespace that the aws infra structure resources will be created
-export INFRA_NAMESPACE=infra-aws
-# create the namespace in Crossplane
-kubectl create namespace ${INFRA_NAMESPACE}
-```
-
-Now we can install the AWS stack using Crossplane CLI. Since this is an
-infrastructure stack, we need to specify that it's cluster-scoped by
-passing the `--cluster` flag.
-
-```bash
-kubectl crossplane stack generate-install --cluster 'crossplane/stack-aws:v0.1.0' stack-aws | kubectl apply --namespace ${INFRA_NAMESPACE} -f -
-```
-
-The rest of the steps assume that you installed the AWS stack into the
-`infra-aws` namespace.
-
-## Configure the AWS account
-
-An [aws user][] with `Administrative` privileges is needed to enable Crossplane to
-create the required resources. Once the user is provisioned, an [Access Key][]
-needs to be created so the user can have API access.
-
-Using the set of access key credentials for the user with the right
-access, we will to have [`aws` command line tool][] [installed][], and
-then we will need to [configure it][aws-cli-configure].
-
-When the aws cli is configured, the credentials and configuration will
-be in `~/.aws/credentials` and `~/.aws/config` respectively. These will
-be consumed in the next step.
-
-When configuring the aws cli, it is recommended that the user credentials are
-configured under a specific [aws named profile][], and not under
-`default`. In this guide, we assume that the credentials are configured
-under the `crossplane-user` profile, but you can use a different profile
-name if you want. Let's store the profile name in a variable so we can
-use it in later steps:
-
-```bash
-export aws_profile=crossplane-user
-```
-
-## Configure Crossplane Provider for AWS
-
-Crossplane uses the aws user credentials that were configured in the previous
-step to create resources in AWS. These credentials will be stored as a
-[secret][] in Kubernetes, and will be used by an [aws
-provider][aws-provider-docs] instance. The AWS region is also pulled
-from the cli configuration, so that the aws provider can target a
-specific region.
-
-To store the credentials as a secret, run:
-
-```bash
-# retrieve profile's credentials, save it under 'default' profile, and base64 encode it
-export AWS_CREDS_BASE64=$(echo -e "[default]\naws_access_key_id = $(aws configure get aws_access_key_id --profile $aws_profile)\naws_secret_access_key = $(aws configure get aws_secret_access_key --profile $aws_profile)" | base64 | tr -d "\n")
-# retrieve the profile's region from config
-export AWS_REGION=$(aws configure get region --profile ${aws_profile})
-```
-
-At this point, the region and the encoded credentials are stored in respective
- variables. Next, we'll need to create an instance of [`aws provider`][]:
-
-```bash
-cat > provider.yaml < vpc.yaml < subnets.yaml < internetgateway.yaml < routetable.yaml < cluster_sg.yaml < rds_sg.yaml < dbsubnetgroup.yaml < iamrole.yaml < policies.yaml < resource_classes.yaml < portable_classes.yaml <
-[stacks-guide]: stacks-guide.md
-
-[aws]: https://aws.amazon.com
-[stack-aws]: https://github.com/crossplaneio/stack-aws
-[sample-wordpress-stack]: https://github.com/crossplaneio/sample-stack-wordpress
-
-[stack-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#crossplane-stacks
-
-[aws user]: https://docs.aws.amazon.com/mediapackage/latest/ug/setting-up-create-iam-user.html
-[Access Key]: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
-
-[`aws provider`]: https://github.com/crossplaneio/stack-aws/blob/master/aws/apis/v1alpha2/types.go#L43
-[aws-provider-docs]: https://github.com/crossplaneio/stack-aws/blob/master/aws/apis/v1alpha2/types.go#L43
-
-[`aws` command line tool]: https://aws.amazon.com/cli/
-[AWS SDK for GO]: https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/setting-up.html
-
-[installed]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html
-[aws-cli-configure]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html
-[AWS security credentials]: https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html
-[secret]: https://kubernetes.io/docs/concepts/configuration/secret/
-[aws named profile]: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html
-
-[crossplane-cli]: https://github.com/crossplaneio/crossplane-cli
-
-[Virtual Private Network]: https://aws.amazon.com/vpc/
-[Subnet]: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-subnet-basics
-[AWS resource connectivity]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-resource-connectivity-mvp.md#amazon-web-services
-[Internet Gateway]: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html
-[Route Table]: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html
-[Security Group]: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
-[Database Subnet Group]: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html
-[IAM Role]: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
-[IAM Role Policy]: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html
-
-[portable-classes-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-default-resource-class.md
-[resource-classes-docs]: concepts.md#resource-claims-and-resource-classes
-
-[stacks-guide-continue]: stacks-guide.md#install-support-for-our-application-into-crossplane
-[resource-claims-docs]: concepts.md#resource-claims-and-resource-classes
-[eks-user-guide]: https://docs.aws.amazon.com/eks/latest/userguide/create-public-private-vpc.html
diff --git a/docs/v0.3/stacks-guide-azure.md b/docs/v0.3/stacks-guide-azure.md
deleted file mode 100644
index 69c1f650..00000000
--- a/docs/v0.3/stacks-guide-azure.md
+++ /dev/null
@@ -1,447 +0,0 @@
----
-title: "Stacks Guide: Azure Setup"
-toc: true
-weight: 540
-indent: true
----
-
-# Stacks Guide: Azure Setup
-
-## Table of Contents
-
-1. [Introduction](#introduction)
-2. [Install the Azure Stack](#install-the-azure-stack)
-3. [Configure Azure Account](#configure-azure-account)
-4. [Configure Crossplane Azure Provider](#configure-crossplane-azure-provider)
-5. [Set Up Network Resources](#set-up-network-resources)
-6. [Configure Provider Resources](#configure-provider-resources)
-7. [Recap](#recap)
-8. [Next Steps](#next-steps)
-
-## Introduction
-
-In this guide, we will set up an Azure provider in Crossplane so that we
-can install and use the [WordPress sample
-stack][sample-wordpress-stack], which depends on MySQL and Kubernetes!
-
-Before you begin, you will need:
-
-* Everything from the [Crossplane Stacks Guide][stacks-guide] before the cloud
- provider setup
- - A `kubectl` pointing to a Crossplane control cluster
- - The [Crossplane CLI][crossplane-cli] installed
-* An account on [Azure][azure]
-* The [jq][jq] tool for interacting with some JSON, or equivalent
-
-At the end, we will have:
-
-* A Crossplane control cluster configured to use Azure
-* The boilerplate of an Azure-based project spun up
-* Support in the control cluster for managing MySQL and Kubernetes cluster
- dependencies
-* A slightly better understanding of:
- - The way cloud providers are configured in Crossplane
- - The way dependencies for cloud-portable workloads are configured in
- Crossplane
-
-We will **not** be teaching first principles in depth. Check out the [concepts
-document][crossplane-concepts] for that.
-
-## Install the Azure Stack
-
-After Crossplane has been installed, it can be extended with more
-functionality by installing a [Crossplane Stack][stack-docs]! Let's
-install the [stack for Microsoft Azure][stack-azure] to add
-support for that cloud provider. We can use the [Crossplane
-CLI][crossplane-cli] for this operation. Since this is an infrastructure
-stack, we need to specify that it's cluster-scoped by passing the
-`--cluster` flag.
-
-To install to a specific namespace, we can use the `generate-install`
-command and pipe it to `kubectl apply` instead, which gives us more
-control over how the stack's installation is handled. Everything is
-a Kubernetes object!
-
-```
-kubectl crossplane stack generate-install --cluster 'crossplane/stack-azure:v0.1.0' stack-azure | kubectl apply --namespace crossplane-system -f -
-```
-
-If we wanted to use whatever the current namespace is, we could have
-used `kubectl crossplane stack install` instead of using
-`generate-install`.
-
-We have installed the Azure stack into the `crossplane-system` namespace, but we
-want to group our Azure-specific resources in their own environment namespaces.
-For the purpose of this guide, we will create all Azure-specific resources in
-the `azure-infra-dev` namespace, and all application-specific resources in the
-`app-project1-dev` namespace. Let's create these namespaces before we get
-started:
-
-```
-kubectl create namespace azure-infra-dev
-kubectl create namespace app-project1-dev
-```
-
-## Configure Azure Account
-
-We will make use of the following services on Azure:
-
-* Resource Group
-* AKS
-* Azure Database for MySQL
-* Virtual Network
-* Subnetwork
-* Virtual Network Rule
-
-In order to utilize each of these services, you will need to follow the [Adding
-Microsoft Azure to Crossplane guide][provider-azure-guide] to obtain
-appropriate credentials in a JSON file referred to as
-`crossplane-azure-provider-key.json`.
-
-## Configure Crossplane Azure Provider
-
-Before creating any resources, we need to create and configure a cloud provider
-in Crossplane. This helps Crossplane know how to connect to the cloud provider.
-All the requests from Crossplane to Azure can use that resource as their
-credentials. The following command assumes that you have a
-`crossplane-azure-provider-key.json` file that belongs to the account you’d like
-Crossplane to use.
-
-```
-export BASE64ENCODED_AZURE_PROVIDER_CREDS=$(base64 crossplane-azure-provider-key.json | tr -d "\n")
-```
-
-Now we’ll create our `Secret` that contains the credential and `Provider`
-resource that refers to that secret:
-
-```
-cat > provider.yaml < network.yaml < environment.yaml < namespace.yaml < vnet-rule.yaml < vnetwatch.sh <<'EOF'
-#!/usr/bin/env bash
-
-set -e
-trap 'exit 1' SIGINT
-
-echo -n "waiting for mysql endpoint..." >&2
-while kubectl -n azure-infra-dev get mysqlservers -o yaml | grep -q 'items: \[\]'; do
- echo -n "." >&2
- sleep 5
-done
-echo "done" >&2
-
-export MYSQL_NAME=$(kubectl -n azure-infra-dev get mysqlservers -o=jsonpath='{.items[0].metadata.name}')
-
-sed "s/MYSQL_NAME/$MYSQL_NAME/g" vnet-rule.yaml | kubectl apply -f -
-
-EOF
-
-chmod +x vnetwatch.sh && ./vnetwatch.sh
-```
-
-The script should be left running in the background while we go through
-the rest of the guide and install the Wordpress stack.
-
-## Recap
-
-To recap what we've set up now in our environment:
-
-* Our provider account, both on the provider side and on the Crossplane side.
-* A Resource Group to provision service within.
-* A Network for our AKS Cluster components.
-* A Subnetwork for the AKS cluster to use in the network.
-* A GlobalAddress resource for Google’s service connection.
-* An AKSClusterClass and a SQLServerClass with the right configuration to use
- the mentioned networking setup.
-* A script that will create our Virtual Network Rule when our MySQL database
- name comes available.
-* A namespace for our app resources to reside with default MySQLInstanceClass
- and KubernetesClusterClass that refer to our AKSClusterClass and
- SQLServerClass.
-
-## Next Steps
-
-Next we'll set up a Crossplane App Stack and use it! Head [back over to the
-Stacks Guide document][stacks-guide-continue] so we can pick up where we left
-off.
-
-
-[sample-wordpress-stack]: https://github.com/crossplaneio/sample-stack-wordpress
-
-[crossplane-cli]: https://github.com/crossplaneio/crossplane-cli/tree/release-0.1
-[crossplane-azure-networking-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-resource-connectivity-mvp.md#microsoft-azure
-[stacks-guide]: stacks-guide.md
-[provider-azure-guide]: cloud-providers/azure/azure-provider.md
-
-[stack-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#crossplane-stacks
-[stack-azure]: https://github.com/crossplaneio/stack-azure
-
-[crossplane-concepts]: concepts.md
-[portable-classes-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-default-resource-class.md
-
-[azure]: https://azure.microsoft.com
-[azure-vnet-rule]: https://docs.microsoft.com/en-us/azure/mysql/concepts-data-access-and-security-vnet
-[azure-resource-group-docs]: https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview
-
-[stacks-guide-continue]: stacks-guide.md#install-support-for-our-application-into-crossplane
-[jq]: https://stedolan.github.io/jq/
diff --git a/docs/v0.3/stacks-guide-gcp.md b/docs/v0.3/stacks-guide-gcp.md
deleted file mode 100644
index 1360c4ff..00000000
--- a/docs/v0.3/stacks-guide-gcp.md
+++ /dev/null
@@ -1,501 +0,0 @@
----
-title: "Stacks Guide: GCP Setup"
-toc: true
-weight: 520
-indent: true
----
-
-# Stacks Guide: GCP Setup
-
-## Table of Contents
-
-1. [Introduction](#introduction)
-2. [Install the GCP Stack](#install-the-gcp-stack)
-3. [Configure GCP Account](#configure-gcp-account)
-4. [Configure Crossplane GCP Provider](#configure-crossplane-gcp-provider)
-5. [Set Up Network Resources](#set-up-network-resources)
-6. [Configure Provider Resources](#configure-provider-resources)
-7. [Recap](#recap)
-8. [Next Steps](#next-steps)
-
-## Introduction
-
-In this guide, we will set up a GCP provider in Crossplane so that we
-can install and use the [WordPress sample
-stack][sample-wordpress-stack], which depends on MySQL and Kubernetes!
-
-Before we begin, you will need:
-
-* Everything from the [Crossplane Stacks Guide][stacks-guide] before the
- cloud provider setup
- - A `kubectl` pointing to a Crossplane control cluster
- - The [Crossplane CLI][crossplane-cli] installed
-* An account on [Google Cloud Platform][gcp]
-
-At the end, we will have:
-
-* A Crossplane control cluster configured to use GCP
-* The boilerplate of a GCP-based project spun up
-* Support in the control cluster for managing MySQL and Kubernetes
- cluster dependencies
-* A slightly better understanding of:
- - The way cloud providers are configured in Crossplane
- - The way dependencies for cloud-portable workloads are configured in
- Crossplane
-
-We will **not** be teaching first principles in depth. Check out the
-[Crossplane concepts document][crossplane-concepts] for that.
-
-## Install the GCP Stack
-
-After Crossplane has been installed, it can be extended with more
-functionality by installing a [Crossplane Stack][stack-docs]! Let's
-install the [stack for Google Cloud Platform][stack-gcp] (GCP) to add
-support for that cloud provider. We can use the [Crossplane
-CLI][crossplane-cli] for this operation. Since this is an infrastructure
-stack, we need to specify that it's cluster-scoped by passing the
-`--cluster` flag.
-
-To install to a specific namespace, we can use the `generate-install`
-command and pipe it to `kubectl apply` instead, which gives us more
-control over how the stack's installation is handled. Everything is
-a Kubernetes object!
-
-```
-kubectl create namespace gcp
-kubectl crossplane stack generate-install --cluster 'crossplane/stack-gcp:v0.1.0' stack-gcp | kubectl apply --namespace gcp -f -
-```
-
-If we wanted to use whatever the current namespace is, we could have
-used `kubectl crossplane stack install` instead of using
-`generate-install`.
-
-The namespace that we install the stack to is where the stack will
-create the resources it manages. When a developer requests a resource by
-creating a [resource claim][resource-claims-docs] in a namespace `mynamespace`, the
-managed cloud provider resource and any secrets will be created in the
-stack's namespace. Secrets will be copied over to `mynamespace`, and the
-claim will be bound to the original resource claim. For more details
-about resource claims and how they work, see the [documentation on
-resource claims][resource-claims-docs].
-
-For convenience, the next steps assume that you installed GCP stack into
-the `gcp` namespace.
-
-### Validate the installation
-
-To check to see whether our stack installed correctly, we can look at
-the status of our stack:
-
-```
-kubectl -n gcp get stack
-```
-
-It should look something like this:
-
-```
-NAME READY VERSION AGE
-stack-gcp True 0.0.1 5m19s
-```
-
-## Configure GCP Account
-
-We will make use of the following services on GCP:
-
-* GKE
-* CloudSQL Instance
-* Network
-* Subnetwork
-* GlobalAddress
-* Private Service Connection
-
-For all these to work, you need to [enable the following
-APIs][gcp-enable-apis] in your GCP project:
-
-* Compute Engine API
-* Service Networking API
-* Kubernetes Engine API
-
-We will also need to tell Crossplane how to use the credentials for the
-GCP account. For this exercise, the GCP account that we will tell
-Crossplane about should have the following [roles
-assigned][gcp-assign-roles]:
-
-* Cloud SQL Admin
-* Compute Network Admin
-* Kubernetes Engine Admin
-* Service Account User
-
-### Set up cloud provider credentials
-
-This guide assumes that you have created a JSON file which contains the
-credentials for the cloud provider. In later sections, this file will be
-referred to as `crossplane-gcp-provider-key.json`. There are quite a few
-steps involved, so the steps are in [a different document which you
-should take a look at][cloud-provider-setup-gcp] before moving to the
-next section. Or, there is also [a script in the Crossplane
-repo][gcp-credentials] which helps with creating the file.
-
-## Configure Crossplane GCP Provider
-
-Before creating any resources, we need to create and configure a cloud
-provider in Crossplane. This helps Crossplane know how to connect to the cloud
-provider. All the requests from Crossplane to GCP will use the
-credentials attached to the provider object. The following command
-assumes that you have a `crossplane-gcp-provider-key.json` file that
-belongs to the account you’d like Crossplane to use. Run the command
-after changing `[your-demo-project-id]` to your actual GCP project id.
-You should be able to get the project id from the JSON credentials file
-or from the GCP Console.
-
-```
-export PROJECT_ID=[your-demo-project-id]
-export BASE64ENCODED_GCP_PROVIDER_CREDS=$(base64 crossplane-gcp-provider-key.json | tr -d "\n")
-```
-
-The environment variable `PROJECT_ID` is going to be used in multiple
-YAML files in the next steps, while `BASE64ENCODED_GCP_PROVIDER_CREDS`
-is only needed for this step.
-
-Now we’ll create our `Secret` that contains the credential and
-`Provider` resource that refers to that secret:
-
-```
-cat > provider.yaml < network.yaml < environment.yaml < namespace.yaml <
-[crossplane-cli]: https://github.com/crossplaneio/crossplane-cli/tree/release-0.1
-[crossplane-gcp-networking-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-resource-connectivity-mvp.md#google-cloud-platform
-[stacks-guide]: stacks-guide.md
-
-[crossplane-concepts]: concepts.md
-
-[gcp-credentials]: https://github.com/crossplaneio/crossplane/blob/master/cluster/examples/gcp-credentials.sh
-[gcp-enable-apis]: https://cloud.google.com/endpoints/docs/openapi/enable-api
-[gcp-assign-roles]: https://cloud.google.com/iam/docs/granting-roles-to-service-accounts
-[gcp-create-keys]: https://cloud.google.com/sdk/gcloud/reference/iam/service-accounts/keys/create
-
-[gcp]: https://cloud.google.com/
-
-[stacks-guide-continue]: stacks-guide.html#install-support-for-our-application-into-crossplane
-[sample-wordpress-stack]: https://github.com/crossplaneio/sample-stack-wordpress
-[stack-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#crossplane-stacks
-
-[stack-gcp]: https://github.com/crossplaneio/stack-gcp
-
-[resource-claims-docs]: concepts.md#resource-claims-and-resource-classes
-[resource-classes-docs]: concepts.md#resource-claims-and-resource-classes
-[portable-classes-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-default-resource-class.md
-
-[crossplane-sample-gcp-provider]: https://github.com/crossplaneio/crossplane/blob/master/cluster/examples/workloads/kubernetes/wordpress/gcp/provider.yaml
-[crossplane-sample-gcp-network]: https://github.com/crossplaneio/crossplane/blob/master/cluster/examples/workloads/kubernetes/wordpress/gcp/network.yaml
-[crossplane-sample-gcp-environment]: https://github.com/crossplaneio/crossplane/blob/master/cluster/examples/workloads/kubernetes/wordpress/gcp/environment.yaml
-[crossplane-sample-gcp-namespace]: https://github.com/crossplaneio/crossplane/blob/master/cluster/examples/workloads/kubernetes/wordpress/gcp/namespace.yaml
-
-[cloud-provider-setup-gcp]: cloud-providers/gcp/gcp-provider.md
diff --git a/docs/v0.3/stacks-guide.md b/docs/v0.3/stacks-guide.md
deleted file mode 100644
index 6b41cb52..00000000
--- a/docs/v0.3/stacks-guide.md
+++ /dev/null
@@ -1,352 +0,0 @@
----
-title: "Stacks Guide"
-toc: true
-weight: 510
-indent: false
----
-
-# Stacks Guide
-
-
-## Table of Contents
-
-1. [Introduction](#introduction)
-2. [Concepts](#concepts)
-3. [Before you get started](#before-you-get-started)
-4. [Install the Crossplane CLI](#install-the-crossplane-cli)
-5. [Install and configure Crossplane](#install-and-configure-crossplane)
-6. [Install support for our application into
- Crossplane](#install-support-for-our-application-into-crossplane)
-7. [Create a Wordpress](#create-a-wordpress)
-8. [Clean up](#clean-up)
-9. [Conclusion](#conclusion)
-10. [Next steps](#next-steps)
-11. [References](#references)
-
-## Introduction
-
-Welcome to the Crossplane Stack guide! In this document, we will:
-
-* Learn how to install an existing stack
-* Interact with a stack to see how to use it
-* Glimpse what is possible with a stack
-* Touch a little bit on how stacks work
-
-We will **not**:
-
-* Learn first principles (see the [concepts
- document][crossplane-concepts] for that level of detail)
-* Develop our own stack from scratch (go to [this development
- guide][stack-developer-guide] to learn how to do that)
-
-Let's go!
-
-## Concepts
-
-There are a bunch of things you might want to know to fully understand
-what's happening in this document. This guide won't cover them, but
-there are other ones that do. Here are some links!
-
-* [Crossplane concepts][crossplane-concepts]
-* [Kubernetes concepts][kubernetes-concepts]
-
-## Before you get started
-
-This guide assumes you are using a *nix-like environment. It also
-assumes you have a basic working familiarity with the following:
-
-* The terminal environment
-* Setting up cloud provider accounts for the cloud provider you want to
- use
-* [Kubernetes][kubernetes-docs] and [kubectl][kubectl-docs]
-
-You will need:
-
-* A *nix-like environment
-* A cloud provider account, for the cloud provider of your choice (out
- of the supported providers)
-* A locally-configured kubectl which points to a configured Kubernetes
- cluster. We will put Crossplane in this cluster, and we'll refer to it
- as the control cluster.
-
-## Install the Crossplane CLI
-
-To interact with stacks, we're going to use the [Crossplane
-CLI][crossplane-cli], because it's more convenient. To install it, we
-can use the one-line curl bash:
-
-```
-RELEASE=release-0.1 && curl -sL https://raw.githubusercontent.com/crossplaneio/crossplane-cli/"${RELEASE}"/bootstrap.sh | RELEASE=${RELEASE} bash
-```
-
-To use the latest release, you can use `master` as the `RELEASE` instead
-of using a specific version.
-
-## Install and configure Crossplane
-
-To use Crossplane, we'll need to install and configure it. In this case,
-we want to use Crossplane with a cloud provider, so we'll need to
-configure the provider.
-
-### Install Crossplane
-
-The recommended way of installing Crossplane is by using
-[helm][helm-install]. We can grab the most stable version currently
-available by using:
-
-```
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-For more options for installing, including how to install a more
-bleeding-edge version, or how to uninstall, see the [full install
-documentation][crossplane-install-docs].
-
-### Create the application namespace
-
-[Kubernetes namespaces][kubernetes-namespaces-docs] are used to isolate
-resources in the same cluster, and we'll use them in our Crossplane
-control cluster too. Let's create a namespace for our application's
-resources. We'll call it `app-project1-dev` for the purposes of this
-guide, but any name can be used.
-
-```
-kubectl create namespace app-project1-dev
-```
-
-The reason we need to create the namespace before we configure the cloud
-provider is because we will be setting up some cloud provider
-configuration in that namespace. The configuration will help our
-application not care about which specific provider it uses. For more
-details on how this works, see the Crossplane documentation on [portable
-classes][portable-classes-docs].
-
-### Configure support for your cloud provider
-
-Next we'll set up support for our cloud provider of choice! See the
-provider-specific guides:
-
-* [AWS][aws-setup]
-* [GCP][gcp-setup]
-* [Azure][azure-setup]
-
-Then come back here! Don't worry; we'll still be here when you're ready.
-
-Don't see your favorite cloud provider? [Help us add
-support][provider-stack-developer-guide] for it!
-
-## Install support for our application into Crossplane
-
-Now that we've got Crossplane set up and configured to use a cloud
-provider, we're ready to add support for creating WordPresses! We'll do
-this using a Crossplane Stack. For more information about stacks, see
-the [full Stack documentation][stack-docs].
-
-We can use the [Crossplane CLI][crossplane-cli] to install our stack which adds support for
-Wordpress. Let's install it into a namespace for our project, which
-we'll call `app-project1-dev` for the purposes of this guide. To install
-to the current namespace, `install` can be used, but since we want to
-install to a specific namespace, we will use `generate-install`:
-
-```
-kubectl crossplane stack generate-install 'crossplane/sample-stack-wordpress:latest' 'sample-stack-wordpress' | kubectl apply --namespace app-project1-dev -f -
-```
-
-Using the `generate-install` command and piping the output to `kubectl
-apply` instead of using the `install` command gives us more control over
-how the stack's installation is handled. Everything is a Kubernetes
-object!
-
-This pulls the stack package from a registry to install it into
-Crossplane. For more details about how to use the CLI, see the
-[documentation for the CLI][crossplane-cli-docs]. For more details about how stacks work behind
-the scenes, see the documentation about the [stack
-manager][stack-manager-docs] and the [stack
-format][stack-format-docs].
-
-## Create a Wordpress
-
-Now that Crossplane supports Wordpress creation, we can ask Crossplane
-to spin up a Wordpress for us. We can do this by creating a Kubernetes
-resource that our Wordpress stack will recognize:
-
-```
-cat > my-wordpress.yaml <
-[crossplane-cli]: https://github.com/crossplaneio/crossplane-cli/tree/release-0.1
-[crossplane-cli-docs]: https://github.com/crossplaneio/crossplane-cli/blob/release-0.1/README.md
-[crossplane-concepts]: concepts.md
-[crossplane-install-docs]: install-crossplane.md
-[crossplane-api-reference]: api.md
-
-[kubernetesapplicationresource-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-complex-workloads.md
-[claims-docs]: concepts.md#resource-claims-and-resource-classes
-[resource-classes-docs]: concepts.md#resource-claims-and-resource-classes
-[portable-classes-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-default-resource-class.md
-[workloads-docs]: concepts.md#resources-and-workloads
-
-[kubernetes-concepts]: https://kubernetes.io/docs/concepts/
-[kubernetes-docs]: https://kubernetes.io/docs/home/
-[kubernetes-namespaces-docs]: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
-[kubectl-docs]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
-
-[helm-install]: https://github.com/helm/helm#install
-
-[aws-docs]: https://docs.aws.amazon.com/
-[gcp-docs]: https://cloud.google.com/docs/
-[azure-docs]: https://docs.microsoft.com/azure/
-
-[aws-setup]: stacks-guide-aws.md
-[gcp-setup]: stacks-guide-gcp.md
-[azure-setup]: stacks-guide-azure.md
-
-[stack-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#crossplane-stacks
-[stack-quick-start]: https://github.com/crossplaneio/crossplane-cli/tree/release-0.1#quick-start-stacks
-[stack-concepts]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#crossplane-stacks
-[stack-registry]: https://hub.docker.com/search?q=crossplane&type=image
-[stack-manager-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#installation-flow
-[stack-format-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#stack-package-format
-[stack-developer-guide]: developer-guide.md
-[provider-stack-developer-guide]: developer-guide.md
diff --git a/docs/v0.3/troubleshoot.md b/docs/v0.3/troubleshoot.md
deleted file mode 100644
index b2e0e3cb..00000000
--- a/docs/v0.3/troubleshoot.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: Troubleshooting
-toc: true
-weight: 820
-indent: true
----
-# Troubleshooting
-
-* [Crossplane Logs](#crossplane-logs)
-* [Resource Status and Conditions](#resource-status-and-conditions)
-* [Pausing Crossplane](#pausing-crossplane)
-* [Deleting a Resource Hangs](#deleting-a-resource-hangs)
-
-## Crossplane Logs
-
-The first place to look to get more information or investigate a failure would be in the Crossplane pod logs, which should be running in the `crossplane-system` namespace.
-To get the current Crossplane logs, run the following:
-
-```console
-kubectl -n crossplane-system logs -lapp=crossplane
-```
-
-## Resource Status and Conditions
-
-All of the objects that represent managed resources such as databases, clusters, etc. have a `status` section that can give good insight into the current state of that particular object.
-In general, simply getting the `yaml` output of a Crossplane object will give insightful information about its condition:
-
-```console
-kubectl get -o yaml
-```
-
-For example, to get complete information about an Azure AKS cluster object, the following command will generate the below sample (truncated) output:
-
-```console
-> kubectl -n crossplane-system get akscluster -o yaml
-...
- status:
- Conditions:
- - LastTransitionTime: 2018-12-04T08:03:01Z
- Message: 'failed to start create operation for AKS cluster aks-demo-cluster:
- containerservice.ManagedClustersClient#CreateOrUpdate: Failure sending request:
- StatusCode=400 -- Please see https://aka.ms/acs-sp-help for more details."'
- Reason: failed to create cluster
- Status: "False"
- Type: Failed
- - LastTransitionTime: 2018-12-04T08:03:14Z
- Message: ""
- Reason: ""
- Status: "False"
- Type: Creating
- - LastTransitionTime: 2018-12-04T09:59:43Z
- Message: ""
- Reason: ""
- Status: "True"
- Type: Ready
- bindingPhase: Bound
- endpoint: crossplane-aks-14af6e93.hcp.centralus.azmk8s.io
- state: Succeeded
-```
-
-We can see a few conditions in that AKS cluster's history.
-It first encountered a failure, then it moved into the `Creating` state, then it finally became `Ready` later on.
-Conditions that have `Status: "True"` are currently active, while conditions with `Status: "False"` happened in the past, but are no longer happening currently.
-
-## Pausing Crossplane
-
-Sometimes, it can be useful to pause Crossplane if you want to stop it from actively attempting to manage your resources, for instance if you have encountered a bug.
-To pause Crossplane without deleting all of its resources, run the following command to simply scale down its deployment:
-
-```console
-kubectl -n crossplane-system scale --replicas=0 deployment/crossplane
-```
-
-Once you have been able to rectify the problem or smooth things out, you can unpause Crossplane simply by scaling its deployment back up:
-
-```console
-kubectl -n crossplane-system scale --replicas=1 deployment/crossplane
-```
-
-## Deleting a Resource Hangs
-
-The resources that Crossplane manages will automatically be cleaned up so as not to leave anything running behind.
-This is accomplished by using finalizers, but in certain scenarios, the finalizer can prevent the Kubernetes object from getting deleted.
-
-To deal with this, we essentially want to patch the object to remove its finalizer, which will then allow it to be deleted completely.
-Note that this won't necessarily delete the external resource that Crossplane was managing, so you will want to go to your cloud provider's console and look there for any lingering resources to clean up.
-
-In general, a finalizer can be removed from an object with this command:
-
-```console
-kubectl patch -p '{"metadata":{"finalizers": []}}' --type=merge
-```
-
-For example, for a Workload object (`workloads.compute.crossplane.io`) named `test-workload`, you can remove its finalizer with:
-
-```console
-kubectl patch workloads.compute.crossplane.io test-workload -p '{"metadata":{"finalizers": []}}' --type=merge
-```
diff --git a/docs/v0.3/workloads/aws/wordpress-aws.md b/docs/v0.3/workloads/aws/wordpress-aws.md
deleted file mode 100644
index c3bf5ad4..00000000
--- a/docs/v0.3/workloads/aws/wordpress-aws.md
+++ /dev/null
@@ -1,293 +0,0 @@
-# Deploying a WordPress Workload on AWS
-
-This guide walks you through how to use Crossplane to deploy a stateful workload in a portable way on AWS.
-The following components are dynamically provisioned and configured during this guide:
-
-* An EKS Kubernetes cluster
-* An RDS MySQL database
-* A sample WordPress application
-
-## Pre-requisites
-
-Before starting this guide, you should have already [configured your AWS account](../../cloud-providers/aws/aws-provider.md) for use with Crossplane.
-
-You should also have an AWS credentials file at `~/.aws/credentials` already on your local filesystem.
-
-## Administrator Tasks
-
-This section covers tasks performed by the cluster or cloud administrator. These include:
-
-* Importing AWS provider credentials
-* Defining resource classes for cluster and database resources
-* Creating all EKS pre-requisite artifacts
-* Creating a target EKS cluster (using dynamic provisioning with the cluster resource class)
-
-> Note: All artifacts created by the administrator are stored/hosted in the `crossplane-system` namespace, which has
-restricted access, i.e. `Application Owner(s)` should not have access to them.
-
-To successfully follow this guide, make sure your `kubectl` context points to the cluster where `Crossplane` was deployed.
-
-### Configuring EKS Cluster Pre-requisites
-
-EKS cluster deployment is somewhat of an arduous process right now.
-A number of artifacts and configurations need to be set up within the AWS console prior to provisioning an EKS cluster using Crossplane.
-We anticipate that AWS will make improvements on this user experience in the near future.
-
-#### Create a named keypair
-
-1. Use an existing ec2 key pair or create a new key pair by following [these steps](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)
-1. Export the key pair name as the EKS_WORKER_KEY_NAME environment variable
-
- ```console
- export EKS_WORKER_KEY_NAME=replace-with-key-name
- ```
-
-#### Create your Amazon EKS Service Role
-[Original Source Guide](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)
-
-1. Open the [IAM console](https://console.aws.amazon.com/iam/).
-1. Choose Roles, then Create role.
-1. Choose EKS from the list of services, then "Allows EKS to manage clusters on your behalf", then Next: Permissions.
-1. Choose Next: Tags.
-1. Choose Next: Review.
-1. For the Role name, enter a unique name for your role, such as eksServiceRole, then choose Create role.
-1. Set the EKS_ROLE_ARN environment variable to the name of your role ARN
-
- ```console
- export EKS_ROLE_ARN=replace-with-full-role-arn
- ```
-
-#### Create your Amazon EKS Cluster VPC
-[Original Source Guide](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)
-
-1. Open the [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation).
-1. From the navigation bar, select a Region that supports Amazon EKS.
- > Note: Amazon EKS is available in the following Regions at this time:
- > * US West (Oregon) (us-west-2)
- > * US East (N. Virginia) (us-east-1)
- > * EU (Ireland) (eu-west-1)
-
-1. Set the REGION environment variable to your region
-
- ```console
- export REGION=replace-with-region
- ```
-
-1. Choose Create stack.
-1. For Choose a template, select Specify an Amazon S3 template URL.
-1. Paste the following URL into the text area and choose Next.
-
- ```text
- https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2018-11-07/amazon-eks-vpc-sample.yaml
- ```
-
-1. On the Specify Details page, fill out the parameters accordingly, and choose Next.
-
- ```console
- * Stack name: Choose a stack name for your AWS CloudFormation stack. For example, you can call it eks-vpc.
- * VpcBlock: Choose a CIDR range for your VPC. You may leave the default value.
- * Subnet01Block: Choose a CIDR range for subnet 1. You may leave the default value.
- * Subnet02Block: Choose a CIDR range for subnet 2. You may leave the default value.
- * Subnet03Block: Choose a CIDR range for subnet 3. You may leave the default value.
- ```
-
-1. (Optional) On the Options page, tag your stack resources and choose Next.
-1. On the Review page, choose Create.
-1. When your stack is created, select it in the console and choose Outputs.
-1. Using values from outputs, export the following environment variables.
-
- ```console
- export EKS_VPC=replace-with-eks-vpcId
- export EKS_SUBNETS=replace-with-eks-subnetIds01,replace-with-eks-subnetIds02,replace-with-eks-subnetIds03
- export EKS_SECURITY_GROUP=replace-with-eks-securityGroupId
- ```
-
-#### Create an RDS subnet group
-
-1. Navigate to the aws console in same region as the EKS clsuter
-1. Navigate to `RDS` service
-1. Navigate to `Subnet groups` in left hand pane
-1. Click `Create DB Subnet Group`
-1. Name your subnet i.e. `eks-db-subnets`
-1. Select the VPC created in the EKS VPC step
-1. Click `Add all subnets related to this VPC`
-1. Click Create
-1. Export the db subnet group name
-
- ```console
- export RDS_SUBNET_GROUP_NAME=replace-with-DBSubnetgroup-name
- ```
-
-#### Create an RDS Security Group (example only)
-
-> Note: This will make your RDS instance visible from anywhere on the internet.
-This is for **EXAMPLE PURPOSES ONLY** and is **NOT RECOMMENDED** for production system.
-
-1. Navigate to ec2 in the same region as the EKS cluster
-1. Click: security groups
-1. Click `Create Security Group`
-1. Name it, ex. `demo-rds-public-visibility`
-1. Give it a description
-1. Select the same VPC as the EKS cluster.
-1. On the Inbound Rules tab, choose Edit.
- * For Type, choose `MYSQL/Aurora`
- * For Port Range, type `3306`
- * For Source, choose `Anywhere` from drop down or type: `0.0.0.0/0`
-1. Choose Add another rule if you need to add more IP addresses or different port ranges.
-1. Click: Create
-1. Export the security group id
-
- ```console
- export RDS_SECURITY_GROUP=replace-with-security-group-id
- ```
-
-### Deploy all Workload Resources
-
-Now deploy all the workload resources, including the RDS database and EKS cluster with the following commands:
-
-Create provider:
-
-```console
-sed -e "s|BASE64ENCODED_AWS_PROVIDER_CREDS|`base64 ~/.aws/credentials|tr -d '\n'`|g;s|EKS_WORKER_KEY_NAME|$EKS_WORKER_KEY_NAME|g;s|EKS_ROLE_ARN|$EKS_ROLE_ARN|g;s|REGION|$REGION|g;s|EKS_VPC|$EKS_VPC|g;s|EKS_SUBNETS|$EKS_SUBNETS|g;s|EKS_SECURITY_GROUP|$EKS_SECURITY_GROUP|g;s|RDS_SUBNET_GROUP_NAME|$RDS_SUBNET_GROUP_NAME|g;s|RDS_SECURITY_GROUP|$RDS_SECURITY_GROUP|g" cluster/examples/workloads/kubernetes/wordpress/aws/provider.yaml | kubectl create -f -
-```
-
-Create cluster:
-
-```console
-kubectl create -f cluster/examples/workloads/kubernetes/wordpress/aws/cluster.yaml
-```
-
-It will take a while (~15 minutes) for the EKS cluster to be deployed and become available.
-You can keep an eye on its status with the following command:
-
-```console
-kubectl -n crossplane-system get ekscluster
-```
-
-Once the cluster is done provisioning, you should see output similar to the following
-> Note: the `STATE` field is `ACTIVE` and the `ENDPOINT` field has a value):
-
-```console
-NAME STATUS STATE CLUSTER-NAME ENDPOINT CLUSTER-CLASS LOCATION RECLAIM-POLICY AGE
-eks-825c1234-9697-11e9-8b05-080027550c17 Bound ACTIVE https://6A7981620931E720CE162F751C158A78.yl4.eu-west-1.eks.amazonaws.com standard-cluster Delete 51m
-```
-
-## Application Developer Tasks
-
-This section covers tasks performed by an application developer. These include:
-
-* Defining a Workload in terms of Resources and Payload (Deployment/Service) which will be deployed into the target Kubernetes Cluster
-* Defining the resource's dependency requirements, in this case a `MySQL` database
-
-Now that the EKS cluster is ready, let's begin deploying the workload as the application developer:
-
-```console
-kubectl create -f cluster/examples/workloads/kubernetes/wordpress/aws/app.yaml
-```
-
-This will also take awhile to complete, since the MySQL database needs to be deployed before the WordPress pod can consume it.
-You can follow along with the MySQL database deployment with the following:
-
-```console
-kubectl -n crossplane-system get rdsinstance
-```
-
-Once the `STATUS` column is `available` as seen below, the WordPress pod should be able to connect to it:
-
-```console
-NAME STATUS STATE CLASS VERSION AGE
-mysql-3f902b48-974f-11e9-8b05-080027550c17 Bound available standard-mysql 5.7 15m
-```
-
-As an administrator, we can examine the cluster directly.
-
-```console
-$ CLUSTER=eks-$(kubectl get kubernetesclusters.compute.crossplane.io -n complex -o=jsonpath='{.items[0].spec.resourceName.uid}')
-$ KUBECONFIG=/tmp/$CLUSTER aws eks update-kubeconfig --name=$CLUSTER --region=$REGION
-$ KUBECONFIG=/tmp/$CLUSTER kubectl get all -lapp=wordpress -A
-NAMESPACE NAME READY STATUS RESTARTS AGE
-wordpress pod/wordpress-8545774bcf-8xj8j 1/1 Running 0 13m
-
-NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-wordpress service/wordpress LoadBalancer 10.100.201.94 a4631fbfa974f11e9932a060b5ad3abc-1542130681.eu-west-1.elb.amazonaws.com 80:31832/TCP 13m
-
-NAMESPACE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
-wordpress deployment.apps/wordpress 1 1 1 1 13m
-
-NAMESPACE NAME DESIRED CURRENT READY AGE
-wordpress replicaset.apps/wordpress-8545774bcf 1 1 1 13m
-$ rm /tmp/$CLUSTER
-```
-
-Continuing as the application developer, we can watch the WordPress pod come online and a public IP address will get assigned to it:
-
-```console
-kubectl -n complex get kubernetesapplication,kubernetesapplicationresources
-```
-
-When a public IP address has been assigned, you'll see output similar to the following:
-
-```console
-NAME CLUSTER STATUS DESIRED SUBMITTED
-kubernetesapplication.workload.crossplane.io/wordpress-demo wordpress-demo-cluster PartiallySubmitted 3 2
-
-NAME TEMPLATE-KIND TEMPLATE-NAME CLUSTER STATUS
-kubernetesapplicationresource.workload.crossplane.io/wordpress-demo-deployment Deployment wordpress wordpress-demo-cluster Submitted
-kubernetesapplicationresource.workload.crossplane.io/wordpress-demo-namespace Namespace wordpress wordpress-demo-cluster Submitted
-kubernetesapplicationresource.workload.crossplane.io/wordpress-demo-service Service wordpress wordpress-demo-cluster Failed
-```
-
-*Note* A Failed status on the Service may be attributable to issues [#428](https://github.com/crossplaneio/crossplane/issues/428) and [504](https://github.com/crossplaneio/crossplane/issues/504). The service should be running despite this status.
-
-Once WordPress is running and has a public IP address through its service, we can get the URL with the following command:
-
-```console
-echo "http://$(kubectl get kubernetesapplicationresource.workload.crossplane.io/wordpress-demo-service -n complex -o yaml -o jsonpath='{.status.remote.loadBalancer.ingress[0].hostname}')"
-```
-
-Paste that URL into your browser and you should see WordPress running and ready for you to walk through its setup experience. You may need to wait a few minutes for this to become accessible via the AWS load balancer.
-
-## Connecting to your EKSCluster (optional)
-
-Requires:
-
-* awscli
-* aws-iam-authenticator
-
-Please see [Install instructions](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) section: `Install and Configure kubectl for Amazon EKS`
-
-When the EKSCluster is up and running, you can update your kubeconfig with:
-
-```console
-aws eks update-kubeconfig --name
-```
-
-Node pool is created after the master is up, so expect a few more minutes to wait, but eventually you can see that nodes joined with:
-
-```console
-kubectl config use-context
-kubectl get nodes
-```
-
-## Clean-up
-
-First delete the workload, which will delete WordPress and the MySQL database:
-
-```console
-kubectl delete -f cluster/examples/workloads/kubernetes/wordpress/aws/app.yaml
-```
-
-Then delete the EKS cluster:
-
-```console
-kubectl delete -f cluster/examples/workloads/kubernetes/wordpress/aws/cluster.yaml
-```
-
-Finally, delete the provider credentials:
-
-```console
-kubectl delete -f cluster/examples/workloads/kubernetes/wordpress/aws/provider.yaml
-```
-
-> Note: There may still be an ELB that was not properly cleaned up, and you will need
-to go to EC2 > ELBs and delete it manually.
diff --git a/docs/v0.3/workloads/azure/wordpress-azure.md b/docs/v0.3/workloads/azure/wordpress-azure.md
deleted file mode 100644
index 356954d6..00000000
--- a/docs/v0.3/workloads/azure/wordpress-azure.md
+++ /dev/null
@@ -1,131 +0,0 @@
-# Deploying a WordPress Workload on Microsoft Azure
-
-This guide will walk you through how to use Crossplane to deploy a stateful workload in a portable way to Azure.
-In this environment, the following components will be dynamically provisioned and configured during this guide:
-
-* AKS Kubernetes cluster
-* Azure MySQL database
-* WordPress application
-
-## Pre-requisites
-
-Before starting this guide, you should have already [configured your Azure account](../../cloud-providers/azure/azure-provider.md) for usage by Crossplane.
-
-- You should have a `crossplane-azure-provider-key.json` file on your local filesystem, preferably at the root of where you cloned the [Crossplane repo](https://github.com/crossplaneio/crossplane).
-- You should have a azure resource group with name `group-westus-1`. If not, change the value of `resourceGroupName` to an existing resource group in `cluster/examples/workloads/wordpress/azure/provider.yaml`
-
-
-
-## Administrator Tasks
-
-This section covers the tasks performed by the cluster or cloud administrator, which includes:
-
-- Import Azure provider credentials
-- Define Resource classes for cluster and database resources
-- Create a target Kubernetes cluster (using dynamic provisioning with the cluster resource class)
-
-**Note**: all artifacts created by the administrator are stored/hosted in the `crossplane-system` namespace, which has
-restricted access, i.e. `Application Owner(s)` should not have access to them.
-
-For the next steps, make sure your `kubectl` context points to the cluster where `Crossplane` was deployed.
-
-- Create the Azure provider object in your cluster:
-
- ```console
- sed "s/BASE64ENCODED_AZURE_PROVIDER_CREDS/`base64 crossplane-azure-provider-key.json | tr -d '\n'`/g;" cluster/examples/workloads/wordpress/azure/provider.yaml | kubectl create -f -
- ```
-
-- Next, create the AKS cluster that will eventually be the target cluster for your Workload deployment:
-
- ```console
- kubectl create -f cluster/examples/workloads/wordpress/azure/cluster.yaml
- ```
-
- It will take a while (~15 minutes) for the AKS cluster to be deployed and becoming ready. You can keep an eye on its status with the following command:
-
- ```console
- kubectl -n crossplane-system get akscluster -o custom-columns=NAME:.metadata.name,STATE:.status.state,CLUSTERNAME:.status.clusterName,ENDPOINT:.status.endpoint,LOCATION:.spec.location,CLUSTERCLASS:.spec.classRef.name,RECLAIMPOLICY:.spec.reclaimPolicy
- ```
-
- Once the cluster is done provisioning, you should see output similar to the following (note the `STATE` field is `Succeeded` and the `ENDPOINT` field has a value):
-
- ```console
- NAME STATE CLUSTERNAME ENDPOINT LOCATION CLUSTERCLASS RECLAIMPOLICY
- aks-587762b3-f72b-11e8-bcbe-0800278fedb1 Succeeded aks-587762b3-f72b-11e8-bcbe-080 crossplane-aks-653c32ef.hcp.centralus.azmk8s.io Central US standard-cluster Delete
- ```
-
-To recap the operations that we just performed as the administrator:
-
-- Defined a `Provider` with Microsoft Azure service principal credentials
-- Defined `ResourceClasses` for `KubernetesCluster` and `MySQLInstance`
-- Provisioned (dynamically) an AKS Cluster using the `ResourceClass`
-
-## Application Developer Tasks
-
-This section covers the tasks performed by the application developer, which includes:
-
-- Define Workload in terms of Resources and Payload (Deployment/Service) which will be deployed into the target Kubernetes Cluster
-- Define the dependency resource requirements, in this case a `MySQL` database
-
-Let's begin deploying the workload as the application developer:
-
-- Now that the target AKS cluster is ready, we can deploy the Workload that contains all the Wordpress resources, including the SQL database, with the following single command:
-
- ```console
- kubectl create -f cluster/examples/workloads/wordpress-azure/workload.yaml
- ```
-
- This will also take awhile to complete, since the MySQL database needs to be deployed before the Wordpress pod can consume it.
- You can follow along with the MySQL database deployment with the following:
-
- ```console
- kubectl -n crossplane-system get mysqlserver -o custom-columns=NAME:.metadata.name,STATUS:.status.state,CLASS:.spec.classRef.name,VERSION:.spec.version
- ```
-
- Once the `STATUS` column is `Ready` like below, then the Wordpress pod should be able to connect to it:
-
- ```console
- NAME STATUS CLASS VERSION
- mysql-58425bda-f72d-11e8-bcbe-0800278fedb1 Ready standard-mysql 5.7
- ```
-
-- Now we can watch the Wordpress pod come online and a public IP address will get assigned to it:
-
- ```console
- kubectl get workload -o custom-columns=NAME:.metadata.name,CLUSTER:.spec.targetCluster.name,NAMESPACE:.spec.targetNamespace,DEPLOYMENT:.spec.targetDeployment.metadata.name,SERVICE-EXTERNAL-IP:.status.service.loadBalancer.ingress[0].ip
- ```
-
- When a public IP address has been assigned, you'll see output similar to the following:
-
- ```console
- NAME CLUSTER NAMESPACE DEPLOYMENT SERVICE-EXTERNAL-IP
- test-workload demo-cluster demo wordpress 104.43.240.15
- ```
-
-- Once Wordpress is running and has a public IP address through its service, we can get the URL with the following command:
-
- ```console
- echo "http://$(kubectl get workload test-workload -o jsonpath='{.status.service.loadBalancer.ingress[0].ip}')"
- ```
-
-- Paste that URL into your browser and you should see Wordpress running and ready for you to walk through the setup experience.
-
-## Clean-up
-
-First delete the workload, which will delete Wordpress and the MySQL database:
-
-```console
-kubectl delete -f cluster/examples/workloads/wordpress-azure/workload.yaml
-```
-
-Then delete the AKS cluster:
-
-```console
-kubectl delete -f cluster/examples/workloads/wordpress/azure/cluster.yaml
-```
-
-Finally, delete the provider credentials:
-
-```console
-kubectl delete -f cluster/examples/workloads/wordpress/azure/provider.yaml
-```
diff --git a/docs/v0.3/workloads/gcp/wordpress-gcp.md b/docs/v0.3/workloads/gcp/wordpress-gcp.md
deleted file mode 100644
index 6291bb1e..00000000
--- a/docs/v0.3/workloads/gcp/wordpress-gcp.md
+++ /dev/null
@@ -1,208 +0,0 @@
-# Deploying a WordPress Workload on GCP
-
-This guide will walk you through how to use Crossplane to deploy a stateful workload in a portable way to GCP.
-In this environment, the following components will be dynamically provisioned and configured during this guide:
-
-* GKE Kubernetes cluster
-* CloudSQL database
-* WordPress application
-
-## Pre-requisites
-
-Before starting this guide, you should have already [configured your GCP account](../../cloud-providers/gcp/gcp-provider.md) for usage by Crossplane.
-
-You should have a `crossplane-gcp-provider-key.json` file on your local filesystem, preferably at the root of where you cloned the [Crossplane repo](https://github.com/crossplaneio/crossplane).
-
-## Administrator Tasks
-
-This section covers the tasks performed by the cluster or cloud administrator, which includes:
-
-* Import GCP provider credentials
-* Define Resource classes for cluster and database resources
-* Create a target Kubernetes cluster (using dynamic provisioning with the cluster resource class)
-
-**Note**: all artifacts created by the administrator are stored/hosted in the `crossplane-system` namespace, which has
-restricted access, i.e. `Application Owner(s)` should not have access to them.
-
-For the next steps, make sure your `kubectl` context points to the cluster where `Crossplane` was deployed.
-
-* Export Project ID and GCP Provider Credentials:
-
- ```bash
- export PROJECT_ID=[your-demo-project-id]
- export BASE64ENCODED_GCP_PROVIDER_CREDS=$(base64 crossplane-gcp-provider-key.json | tr -d "\n")
- ```
-
-* Patch and Apply `provider.yaml`:
-
- ```bash
- sed "s/BASE64ENCODED_GCP_PROVIDER_CREDS/$BASE64ENCODED_GCP_PROVIDER_CREDS/g;s/PROJECT_ID/$PROJECT_ID/g" cluster/examples/workloads/kubernetes/wordpress/gcp/provider.yaml | kubectl create -f -
- ```
-
-* Verify that GCP Provider exists
-
- ```bash
- kubectl -n crossplane-system get providers.gcp.crossplane.io -o custom-columns=NAME:.metadata.name,PROJECT-ID:.spec.projectID
- ```
-
- Your output should look similar to:
-
- ```bash
- NAME PROJECT-ID
- gcp-provider [your-project-id]
- ```
-
-* Verify that Resource Classes have been created
-
- ```bash
- kubectl -n crossplane-system get resourceclass -o custom-columns=NAME:metadata.name,PROVISIONER:.provisioner,PROVIDER:.providerRef.name,RECLAIM-POLICY:.reclaimPolicy
- ```
-
- Your output should be:
-
- ```bash
- NAME PROVISIONER PROVIDER RECLAIM-POLICY
- standard-cluster gkecluster.compute.gcp.crossplane.io/v1alpha1 gcp-provider Delete
- standard-mysql cloudsqlinstance.database.gcp.crossplane.io/v1alpha1 gcp-provider Delete
- ```
-
-* Create a target Kubernetes cluster and namespace where `Application Owner(s)` will deploy their `WorkLoad(s)`
-
- As administrator, you will create a Kubernetes cluster leveraging the Kubernetes cluster `ResourceClass` that was created earlier and
- `Crossplane` Kubernetes cluster dynamic provisioning.
-
- The `Application Developer(s)` will use the `complex` namespace.
-
- ```bash
- kubectl apply -f cluster/examples/workloads/kubernetes/wordpress/gcp/cluster.yaml
- ```
-
- * Verify that the Kubernetes Cluster resource was created
-
- ```bash
- kubectl -n complex get kubernetescluster -o custom-columns=NAME:.metadata.name,CLUSTERCLASS:.spec.classRef.name,CLUSTERREF:.spec.resourceRef.name
- ```
-
- Your output should look similar to:
-
- ```bash
- NAME CLUSTERCLASS CLUSTERREF
- wordpress-demo-cluster standard-cluster gke-67419e79-f5b3-11e8-9cec-9cb6d08bde99
- ```
-
- * Verify that the target GKE cluster was successfully created
-
- ```bash
- kubectl -n crossplane-system get gkecluster -o custom-columns=NAME:.metadata.name,STATE:.status.state,CLUSTERNAME:.status.clusterName,ENDPOINT:.status.endpoint,LOCATION:.spec.zone,CLUSTERCLASS:.spec.classRef.name,RECLAIMPOLICY:.spec.reclaimPolicy
- ```
-
- Your output should look similar to:
-
- ```bash
- NAME STATE CLUSTERNAME ENDPOINT LOCATION CLUSTERCLASS RECLAIMPOLICY
- gke-67419e79-f5b3-11e8-9cec-9cb6d08bde99 RUNNING gke-6742fe8d-f5b3-11e8-9cec-9cb6d08bde99 146.148.93.40 us-central1-a standard-cluster Delete
- ```
-
-To recap the operations that we just performed as the administrator:
-
-* Defined a `Provider` with Google Service Account credentials
-* Defined `ResourceClasses` for `KubernetesCluster` and `MySQLInstance`
-* Provisioned (dynamically) a GKE Cluster using the `ResourceClass` in a new namespace named `complex`
-
-## Application Developer Tasks
-
-This section covers the tasks performed by the application developer, which includes:
-
-* Define Workload in terms of Resources and Payload (Deployment/Service) which will be deployed into the target Kubernetes Cluster
-* Define the dependency resource requirements, in this case a `MySQL` database
-
-Let's begin deploying the workload as the application developer:
-
-* Deploy workload
-
- ```bash
- kubectl apply -f cluster/examples/workloads/kubernetes/wordpress/gcp/app.yaml
- ```
-
-* Wait for `MySQLInstance` to be in `Bound` State
-
- You can check the status via:
-
- ```bash
- kubectl get mysqlinstance -n complex
- ```
-
- Your output should look similar to:
-
- ```bash
- NAME STATUS CLASS VERSION AGE
- sql Bound standard-mysql 5.7 9m
- ```
-
- **Note**: to check on the concrete resource type status as `Administrator` you can run:
-
- ```bash
- kubectl -n crossplane-system get cloudsqlinstance
- ```
-
- Your output should be similar to:
-
- ```bash
- NAME STATUS STATE CLASS VERSION AGE
- mysqlinstance-acaa2117-a830-11e9-8c7f-025000000001 Bound RUNNABLE standard-mysql MYSQL_5_7 10m
- ```
-
-* Wait for the Wordpress service, a `KubernetesApplicationResource`, to report its External IP Address
-
- ```bash
- kubectl get kubernetesapplicationresource.workload.crossplane.io -n complex -o custom-columns=NAME:.metadata.name,NAMESPACE:.spec.template.metadata.namespace,KIND:.spec.template.kind,SERVICE-EXTERNAL-IP:.status.remote.loadBalancer.ingress[0].ip
- ```
-
- **Note** the `Workload` is defined in Application Owner's (`complex`) namespace
-
- Your output should look similar to:
-
- ```bash
- NAME NAMESPACE KIND SERVICE-EXTERNAL-IP
- wordpress-demo-deployment wordpress Deployment
- wordpress-demo-namespace Namespace
- wordpress-demo-service wordpress Service 35.232.9.69
- ```
-
-* Verify that `WordPress` service is accessible via `SERVICE-EXTERNAL-IP`:
-
- * Navigate in your browser to `SERVICE-EXTERNAL-IP`
-
-At this point, you should see the setup page for WordPress in your web browser.
-
-## Clean Up
-
-Once you are done with this example, you can clean up all its artifacts with the following commands:
-
-* Remove the `App`
-
- ```bash
- kubectl delete -f cluster/examples/workloads/kubernetes/wordpress/gcp/app.yaml
- ```
-
-* Remove the `KubernetesCluster`
-
- ```bash
- kubectl delete -f cluster/examples/workloads/kubernetes/wordpress/gcp/cluster.yaml
- ```
-
-* Remove the GCP `Provider` and Crossplane `ResourceClasses`
-
- ```bash
- kubectl delete -f cluster/examples/workloads/kubernetes/wordpress/gcp/provider.yaml
- ```
-
-* Delete Google Project
-
- ```bash
- # list all your projects
- gcloud projects list
-
- # delete demo project
- gcloud projects delete [demo-project-id]
- ```
diff --git a/docs/v0.4/README.md b/docs/v0.4/README.md
deleted file mode 100644
index f90a520d..00000000
--- a/docs/v0.4/README.md
+++ /dev/null
@@ -1,177 +0,0 @@
-# Welcome to Crossplane!
-
-Crossplane is an open source multicloud control plane to manage your
-cloud-native applications and infrastructure across environments, clusters,
-regions and clouds. It enables provisioning and full-lifecycle management of
-applications and managed services from your choice of cloud using `kubectl`.
-
-Crossplane can be installed into an existing Kubernetes cluster to add managed
-service provisioning or deployed as a dedicated control plane for multi-cluster
-management and workload scheduling.
-
-Crossplane enables the community to build and publish Stacks to add more clouds
-and cloud services to Crossplane with support for out-of-tree extensibility and
-independent release schedules. Crossplane includes Stacks for [GCP][stack-gcp],
-[AWS][stack-aws], and [Azure][stack-azure] today.
-
-
-
-Crossplane has four main feature areas that can be used independently:
-
-1. Crossplane Services - provision managed services from kubectl.
-1. Crossplane Stacks - extend Crossplane with new functionality.
-1. Crossplane Workloads - define complete applications and schedule across
- clusters, regions, and clouds.
-1. Crossplane Clusters - manage multiple Kubernetes clusters from a single
- control plane.
-
-## Crossplane Services
-
-Crossplane Services supports managed service provisioning using `kubectl`. It
-applies the Kubernetes pattern for Persistent Volume (PV) claims and classes to
-managed service provisioning with support for a strong separation of concern
-between app teams and cluster administrators.
-
-App teams can choose between cloud-specific and portable services including
-managed databases, message queues, buckets, data pipelines, and more to define
-complete applications, build once, and deploy into multiple clouds using
-continuous delivery pipelines or GitOps flows.
-
-Cluster administrators can define self-service policies and best-practice
-configurations to accelerate app delivery and improve security, so app teams can
-focus on delivering their app instead of cloud-specific infrastructure details.
-
-Take a look at the [getting started guide][getting-started] for an introduction
-to Crossplane Services. The [Crossplane Services Guide][services-user-guide]
-also explores related concepts and shows how to use Crossplane Services to
-deploy a Wordpress instance that securely consumes a managed `MySQLInstance`
-from GCP, AWS, or Azure using `kubectl`.
-
-## Crossplane Stacks
-
-Stacks extend Crossplane with new functionality and can be installed using the
-[Stack Manager][stacks-manager] via the [Kubernetes API][stack-install-docs] or
-with the [crossplane kubectl plugin][crossplane-cli] [`stack
-install`][crossplane-cli-usage] command.
-
-Crossplane is built on the Kubernetes API machinery as a platform, and Stacks
-simplify extending the Kubernetes API to provision and lifecycle manage apps and
-the managed service infrastructure they depend on, including [Stack security and
-isolation][stack-security-design].
-
-The [Crossplane Stacks Guide][stack-user-guide] shows how to deploy a portable
-[Wordpress Stack][stack-wordpress-registry] into multiple clouds using Infra
-Stacks including [stack-gcp][stack-gcp], [stack-aws][stack-aws], and
-[stack-azure][stack-azure].
-
-### Infrastructure Stacks
-
-Infra Stacks like [stack-gcp][stack-gcp], [stack-aws][stack-aws], and
-[stack-azure][stack-azure] extend the Kubernetes API to support managed service
-provisioning (DBaaS, cache, buckets), secure connectivity (VPCs, subnets,
-peering, ACLs, secrets), and provisioning managed Kubernetes clusters on demand
-to further isolate the blast radius of applications.
-
-Infra Stacks are pre-built and published to the [Stacks
-registry][stack-registry] where they can be installed by a Cluster Admin using a
-[`ClusterStackInstall`][stack-install-docs] Kubernetes API kind or with the
-[`stack install`][crossplane-cli-usage] command that installs a Stack with
-permissions to watch resources at a cluster level, across all namespaces.
-
-Infra Stacks are covered in both the [Crossplane Services
-Guide][services-user-guide] and the [Crossplane Stacks Guide][stack-user-guide].
-
-### Application Stacks
-
-App Stacks depend on Infra Stacks like [stack-gcp][stack-gcp],
-[stack-aws][stack-aws], and [stack-azure][stack-azure] to provide managed
-services via the Kubernetes API.
-
-App Stacks are pre-built and published to the [Stacks registry][stack-registry]
-where they can be installed by an app team using a
-[`StackInstall`][stack-install-docs] Kubernetes API kind or with the [`stack
-install`][crossplane-cli-usage] command that installs Stacks with permissions
-only within a single namespace.
-
-The [Crossplane Stacks Guide][stack-user-guide] covers how to deploy a portable
-[Wordpress Stack][stack-wordpress] into multiple clouds using Infra Stacks such
-as [stack-gcp][stack-gcp], [stack-aws][stack-aws], and
-[stack-azure][stack-azure].
-
-### Build your own Stack
-
-The [Crossplane Developer Guide][stack-developer-guide] shows how to build and
-extend Infra Stacks and App Stacks.
-
-## Crossplane Workloads
-
-Crossplane includes an extensible workload scheduler that observes application
-policies to select a suitable target cluster from a pool of available clusters.
-The workload scheduler can be customized to consider a number of criteria
-including capabilities, availability, reliability, cost, regions, and
-performance while deploying workloads and their resources.
-
-Complex workloads can be modelled as a [`KubernetesApplication`][k8s-app-design]
-resource as done by the portable [Wordpress Stack][stack-wordpress] which
-automates the lifecycle of a [`KubernetesApplication`][k8s-app-design] including
-provisioning and secure connectivity to a managed `MySQLInstance`.
-
-## Crossplane Clusters
-
-Crossplane supports dynamic provisioning of managed Kubernetes clusters from a
-single control plane with consistent multi-cluster best-practice configuration
-and secure connectivity between target Kubernetes clusters and the managed
-services provisioned for applications. Managed Kubernetes clusters can be
-dynamically provisioned with a `KubernetesCluster` resource as done by the
-portable [Wordpress Stack][stack-wordpress] which automates the lifecycle of a
-`KubernetesCluster`.
-
-## Architecture and Vision
-
-The full architecture and vision of the Crossplane project is described in depth
-in the [architecture document][arch-doc]. It is the best place to learn more
-about how Crossplane fits into the Kubernetes ecosystem, the intended use cases,
-and comparisons to existing projects.
-
-## Learn More
-
-If you have any questions, please drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us]!
-
-* [Quick Start Guide](quick-start.md)
-* [Concepts](concepts.md)
-* [Services Guide][services-user-guide] - upgrade an existing Kubernetes cluster
- to support managed service provisioning from kubectl.
-* [Stacks Guide][stack-user-guide] - deploy a portable Wordpress Stack into
- multiple clouds.
-* [API Reference](api.md)
-* [Developer Guide](developer-guide.md)
-* [Contributing](../CONTRIBUTING.md)
-* [FAQs](faqs.md)
-* [Learn More][learn-more]
-
-
-[getting-started]: quick-start.md
-[services-user-guide]: services-guide.md
-[stack-user-guide]: stacks-guide.md
-[stack-developer-guide]: developer-guide.md
-[stacks-manager]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#terminology
-[crossplane-cli]: https://github.com/crossplaneio/crossplane-cli
-[crossplane-cli-usage]: https://github.com/crossplaneio/crossplane-cli#usage
-[stack-security-design]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-stacks-security-isolation.md
-
-[stack-wordpress-registry]: https://hub.docker.com/r/crossplane/sample-stack-wordpress
-[stack-wordpress]: https://github.com/crossplaneio/sample-stack-wordpress
-
-[stack-gcp]: https://github.com/crossplaneio/stack-gcp
-[stack-aws]: https://github.com/crossplaneio/stack-aws
-[stack-azure]: https://github.com/crossplaneio/stack-azure
-[stack-registry]: https://hub.docker.com/search?q=crossplane&type=image
-[stack-install-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#installation-flow
-
-[k8s-app-design]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-complex-workloads.md#design
-
-[arch-doc]: https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit?usp=sharing
-
-[contact-us]: https://github.com/crossplaneio/crossplane#contact
-[join-crossplane-slack]: https://slack.crossplane.io
-[learn-more]: learn-more.md
diff --git a/docs/v0.4/api.md b/docs/v0.4/api.md
deleted file mode 100644
index e276473b..00000000
--- a/docs/v0.4/api.md
+++ /dev/null
@@ -1,137 +0,0 @@
----
-title: API Reference
-toc: true
-weight: 610
----
-# API Reference
-
-Crossplane is configured using a variety of Kubernetes resources. These
-resources are separated into API groups. Core API groups are provided by
-Crossplane, while cloud provider specific API groups are provided by each cloud
-provider's stack.
-
-Each API Group supported by Crossplane is assigned its own individual status to
-reflect the varying maturity and stability. More details about API versioning
-and status in Kubernetes can be found on the Kubernetes [API versioning] page,
-but the key difference between the statuses are summarized below:
-
-* **Alpha:** The API may change in incompatible ways in a later software release
- without notice, recommended for use only in short-lived testing clusters, due
- to increased risk of bugs and lack of long-term support.
-* **Beta:** Support for the overall features will not be dropped, though details
- may change. Support for upgrading or migrating between versions will be
- provided, either through automation or manual steps.
-* **Stable:** Features will appear in released software for many subsequent
- versions and support for upgrading between versions will be provided with
- software automation in the vast majority of scenarios.
-
-## Crossplane
-
-Crossplane is responsible for all portable resources, including resource claims
-(for example `MySQLInstance`) and portable resource classes (for example
-`MySQLInstanceClass). Crossplane currently supports the following API groups:
-
-API Group | Status | Details
--------- | ------ | -------
-[`cache.crossplane.io/v1alpha1`] | Alpha | Cache service claims and classes.
-[`compute.crossplane.io/v1alpha1`] | Alpha | Compute service resource claims and classes.
-[`database.crossplane.io/v1alpha1`] | Alpha | Database service resource claims and classes.
-[`kubernetes.crossplane.io/v1alpha1`] | Alpha | Resources for connecting to Kubernetes clusters.
-[`storage.crossplane.io/v1alpha1`] | Alpha | Blob storage service resource claims and classes.
-[`stacks.crossplane.io/v1alpha1`] | Alpha | Resources for managing Crossplane Stacks.
-[`workload.crossplane.io/v1alpha1`] | Alpha | Resources for managing Crossplane Workloads.
-
-[`cache.crossplane.io/v1alpha1`]: api/crossplaneio/crossplane/cache-crossplane-io-v1alpha1.md
-[`compute.crossplane.io/v1alpha1`]: api/crossplaneio/crossplane/compute-crossplane-io-v1alpha1.md
-[`database.crossplane.io/v1alpha1`]: api/crossplaneio/crossplane/database-crossplane-io-v1alpha1.md
-[`kubernetes.crossplane.io/v1alpha1`]: api/crossplaneio/crossplane/kubernetes-crossplane-io-v1alpha1.md
-[`storage.crossplane.io/v1alpha1`]: api/crossplaneio/crossplane/storage-crossplane-io-v1alpha1.md
-[`stacks.crossplane.io/v1alpha1`]: api/crossplaneio/crossplane/stacks-crossplane-io-v1alpha1.md
-[`workload.crossplane.io/v1alpha1`]: api/crossplaneio/crossplane/workload-crossplane-io-v1alpha1.md
-
-## AWS Stack
-
-The AWS Stack is responsible for all AWS specific resources, including managed
-resources (for example `EKSCluster`), and cloud specific resource classes (for
-example `EKSClusterClass`) The AWS Stack currently supports the following API
-groups:
-
-API Group | Status | Details
--------- | ------ | -------
-[`aws.crossplane.io/v1alpha3`] | Alpha | Core AWS resources.
-[`cache.aws.crossplane.io/v1beta1`] | Beta | ElastiCache managed resources and classes.
-[`compute.aws.crossplane.io/v1alpha3`] | Alpha | EKS managed resources and classes.
-[`database.aws.crossplane.io/v1beta1`] | Beta | RDS managed resources and classes.
-[`identity.aws.crossplane.io/v1alpha3`] | Alpha | IAM managed resources and classes.
-[`network.aws.crossplane.io/v1alpha3`] | Alpha | VPC managed resources and classes.
-[`storage.aws.crossplane.io/v1alpha3`] | Alpha | S3 managed resources and classes.
-
-[`aws.crossplane.io/v1alpha3`]: api/crossplaneio/stack-aws/aws-crossplane-io-v1alpha3.md
-[`cache.aws.crossplane.io/v1beta1`]: api/crossplaneio/stack-aws/cache-aws-crossplane-io-v1beta1.md
-[`compute.aws.crossplane.io/v1alpha3`]: api/crossplaneio/stack-aws/compute-aws-crossplane-io-v1alpha3.md
-[`database.aws.crossplane.io/v1beta1`]: api/crossplaneio/stack-aws/database-aws-crossplane-io-v1beta1.md
-[`identity.aws.crossplane.io/v1alpha3`]: api/crossplaneio/stack-aws/identity-aws-crossplane-io-v1alpha3.md
-[`network.aws.crossplane.io/v1alpha3`]: api/crossplaneio/stack-aws/network-aws-crossplane-io-v1alpha3.md
-[`storage.aws.crossplane.io/v1alpha3`]: api/crossplaneio/stack-aws/storage-aws-crossplane-io-v1alpha3.md
-
-## Azure Stack
-
-The Azure Stack is responsible for all Azure specific resources, including
-managed resources (for example `AKSCluster`), and cloud specific resource
-classes (for example `AKSClusterClass`) The Azure Stack currently supports the
-following API groups:
-
-API Group | Status | Details
--------- | ------ | -------
-[`azure.crossplane.io/v1alpha3`] | Alpha | Core Azure resources.
-[`cache.azure.crossplane.io/v1alpha3`] | Alpha | Azure Redis managed resources and classes.
-[`compute.azure.crossplane.io/v1alpha3`] | Alpha | AKS managed resources and classes.
-[`database.azure.crossplane.io/v1alpha3`] | Alpha | Azure Database managed resources and classes.
-[`network.azure.crossplane.io/v1alpha3`] | Alpha | Virtual network managed resources and classes.
-[`storage.azure.crossplane.io/v1alpha3`] | Alpha | Azure Blob Storage managed resources and classes.
-
-[`azure.crossplane.io/v1alpha3`]: api/crossplaneio/stack-azure/azure-crossplane-io-v1alpha3.md
-[`cache.azure.crossplane.io/v1alpha3`]: api/crossplaneio/stack-azure/cache-azure-crossplane-io-v1alpha3.md
-[`compute.azure.crossplane.io/v1alpha3`]: api/crossplaneio/stack-azure/compute-azure-crossplane-io-v1alpha3.md
-[`database.azure.crossplane.io/v1alpha3`]: api/crossplaneio/stack-azure/database-azure-crossplane-io-v1alpha3.md
-[`network.azure.crossplane.io/v1alpha3`]: api/crossplaneio/stack-azure/network-azure-crossplane-io-v1alpha3.md
-[`storage.azure.crossplane.io/v1alpha3`]: api/crossplaneio/stack-azure/storage-azure-crossplane-io-v1alpha3.md
-
-## GCP Stack
-
-The GCP Stack is responsible for all GCP specific resources, including managed
-resources (for example `GKECluster`), and cloud specific resource classes (for
-example `GKEClusterClass`) The GCP Stack currently supports the following API
-groups:
-
-API Group | Status | Details
--------- | ------ | -------
-[`gcp.crossplane.io/v1alpha3`] | Alpha | Core GCP resources.
-[`cache.gcp.crossplane.io/v1beta1`] | Beta | CloudMemorystore managed resources and classes.
-[`compute.gcp.crossplane.io/v1alpha3`] | Alpha | Compute and Kubernetes Engine managed resources and classes.
-[`database.gcp.crossplane.io/v1beta1`] | Beta | CloudSQL managed resources and classes.
-[`servicenetworking.gcp.crossplane.io/v1alpha3`] | Alpha | Service Networking managed resources and classes.
-[`storage.gcp.crossplane.io/v1alpha3`] | Alpha | Cloud Storage managed resources and classes.
-
-[`gcp.crossplane.io/v1alpha3`]: api/crossplaneio/stack-gcp/gcp-crossplane-io-v1alpha3.md
-[`cache.gcp.crossplane.io/v1beta1`]: api/crossplaneio/stack-gcp/cache-gcp-crossplane-io-v1beta1.md
-[`compute.gcp.crossplane.io/v1alpha3`]: api/crossplaneio/stack-gcp/compute-gcp-crossplane-io-v1alpha3.md
-[`database.gcp.crossplane.io/v1beta1`]: api/crossplaneio/stack-gcp/database-gcp-crossplane-io-v1beta1.md
-[`servicenetworking.gcp.crossplane.io/v1alpha3`]: api/crossplaneio/stack-gcp/servicenetworking-gcp-crossplane-io-v1alpha3.md
-[`storage.gcp.crossplane.io/v1alpha3`]: api/crossplaneio/stack-gcp/storage-gcp-crossplane-io-v1alpha3.md
-
-## Rook Stack
-
-The Rook Stack is responsible for all Rook specific resources, including managed resources (for
-example `YugabyteCluster`), and stroage provider specific resource classes (for example
-`YugabyteClusterClass`) The Rook Stack currently supports the following API groups:
-
-API Group | Status | Details
--------- | ------ | -------
-[`rook.crossplane.io/v1alpha1`] | Alpha | Core Rook resources.
-[`database.rook.crossplane.io/v1alpha1`] | Alpha | Database managed resources and classes, such as YugabyteDB and CockroachDB.
-
-[`rook.crossplane.io/v1alpha1`]: api/crossplaneio/stack-rook/rook-crossplane-io-v1alpha1.md
-[`database.rook.crossplane.io/v1alpha1`]: api/crossplaneio/stack-rook/database-rook-crossplane-io-v1alpha1.md
-
-[API Versioning]: https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-versioning
diff --git a/docs/v0.4/api/crossplaneio/crossplane-runtime/core-crossplane-io-v1alpha1.md b/docs/v0.4/api/crossplaneio/crossplane-runtime/core-crossplane-io-v1alpha1.md
deleted file mode 100644
index 068d3803..00000000
--- a/docs/v0.4/api/crossplaneio/crossplane-runtime/core-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,211 +0,0 @@
-# core.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains core API types used by most Crossplane resources.
-
-This API group contains the following Crossplane resources:
-
-
-## BindingPhase
-
-BindingPhase represents the current binding phase of a resource or claim. Alias of string.
-
-Appears in:
-
-* [BindingStatus](#BindingStatus)
-
-
-## BindingStatus
-
-A BindingStatus represents the bindability and binding status of a resource.
-
-Appears in:
-
-* [ResourceClaimStatus](#ResourceClaimStatus)
-* [ResourceStatus](#ResourceStatus)
-
-
-Name | Type | Description
------|------|------------
-`bindingPhase` | Optional [BindingPhase](#BindingPhase) | Phase represents the binding phase of a managed resource or claim. Unbindable resources cannot be bound, typically because they are currently unavailable, or still being created. Unbound resource are available for binding, and Bound resources have successfully bound to another resource.
-
-
-
-## ClassSpecTemplate
-
-A ClassSpecTemplate defines a template that will be used to create the specifications of managed resources dynamically provisioned using a resource class.
-
-
-Name | Type | Description
------|------|------------
-`writeConnectionSecretsToNamespace` | string | WriteConnectionSecretsToNamespace specifies the namespace in which the connection secrets of managed resources dynamically provisioned using this claim will be created.
-`providerRef` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | ProviderReference specifies the provider that will be used to create, observe, update, and delete managed resources that are dynamically provisioned using this resource class.
-`reclaimPolicy` | Optional [ReclaimPolicy](#ReclaimPolicy) | ReclaimPolicy specifies what will happen to external resources when managed resources dynamically provisioned using this resource class are deleted. "Delete" deletes the external resource, while "Retain" (the default) does not. Note this behaviour is subtly different from other uses of the ReclaimPolicy concept within the Kubernetes ecosystem per https://github.com/crossplaneio/crossplane-runtime/issues/21
-
-
-
-## Condition
-
-A Condition that may apply to a managed resource.
-
-Appears in:
-
-* [ConditionedStatus](#ConditionedStatus)
-
-
-Name | Type | Description
------|------|------------
-`type` | [ConditionType](#ConditionType) | Type of this condition. At most one of each condition type may apply to a resource at any point in time.
-`status` | [core/v1.ConditionStatus](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#conditionstatus-v1-core) | Status of this condition; is it currently True, False, or Unknown?
-`lastTransitionTime` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | LastTransitionTime is the last time this condition transitioned from one status to another.
-`reason` | [ConditionReason](#ConditionReason) | A Reason for this condition's last transition from one status to another.
-`message` | Optional string | A Message containing details about this condition's last transition from one status to another, if any.
-
-
-
-## ConditionReason
-
-A ConditionReason represents the reason a resource is in a condition. Alias of string.
-
-Appears in:
-
-* [Condition](#Condition)
-
-
-## ConditionType
-
-A ConditionType represents a condition a resource could be in. Alias of string.
-
-Appears in:
-
-* [Condition](#Condition)
-
-
-## ConditionedStatus
-
-A ConditionedStatus reflects the observed status of a managed resource. Only one condition of each type may exist.
-
-Appears in:
-
-* [ResourceClaimStatus](#ResourceClaimStatus)
-* [ResourceStatus](#ResourceStatus)
-
-
-Name | Type | Description
------|------|------------
-`conditions` | Optional [[]Condition](#Condition) | Conditions of the resource.
-
-
-
-## LocalSecretReference
-
-A LocalSecretReference is a reference to a secret in the same namespace as the referencer.
-
-Appears in:
-
-* [ResourceClaimSpec](#ResourceClaimSpec)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name of the secret.
-
-
-
-## ReclaimPolicy
-
-A ReclaimPolicy determines what should happen to managed resources when their bound resource claims are deleted. Alias of string.
-
-Appears in:
-
-* [ClassSpecTemplate](#ClassSpecTemplate)
-* [ResourceSpec](#ResourceSpec)
-
-
-## ResourceClaimSpec
-
-A ResourceClaimSpec defines the desired state of a resource claim.
-
-
-Name | Type | Description
------|------|------------
-`writeConnectionSecretToRef` | Optional [LocalSecretReference](#LocalSecretReference) | WriteConnectionSecretToReference specifies the name of a Secret, in the same namespace as this resource claim, to which any connection details for this resource claim should be written. Connection details frequently include the endpoint, username, and password required to connect to the managed resource bound to this resource claim.
-`classSelector` | Optional [meta/v1.LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#labelselector-v1-meta) | A ClassSelector specifies labels that will be used to select a resource class for this claim. If multiple classes match the labels one will be chosen at random.
-`classRef` | Optional [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | A ClassReference specifies a resource class that will be used to dynamically provision a managed resource when the resource claim is created.
-`resourceRef` | Optional [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | A ResourceReference specifies an existing managed resource, in any namespace, to which this resource claim should attempt to bind. Omit the resource reference to enable dynamic provisioning using a resource class; the resource reference will be automatically populated by Crossplane.
-
-
-
-## ResourceClaimStatus
-
-A ResourceClaimStatus represents the observed status of a resource claim.
-
-
-
-
-ResourceClaimStatus supports all fields of:
-
-* [ConditionedStatus](#ConditionedStatus)
-* [BindingStatus](#BindingStatus)
-
-
-## ResourceSpec
-
-A ResourceSpec defines the desired state of a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`writeConnectionSecretToRef` | Optional [SecretReference](#SecretReference) | WriteConnectionSecretToReference specifies the namespace and name of a Secret to which any connection details for this managed resource should be written. Connection details frequently include the endpoint, username, and password required to connect to the managed resource.
-`claimRef` | Optional [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | ClaimReference specifies the resource claim to which this managed resource will be bound. ClaimReference is set automatically during dynamic provisioning. Crossplane does not currently support setting this field manually, per https://github.com/crossplaneio/crossplane-runtime/issues/19
-`classRef` | Optional [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | ClassReference specifies the resource class that was used to dynamically provision this managed resource, if any. Crossplane does not currently support setting this field manually, per https://github.com/crossplaneio/crossplane-runtime/issues/20
-`providerRef` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | ProviderReference specifies the provider that will be used to create, observe, update, and delete this managed resource.
-`reclaimPolicy` | Optional [ReclaimPolicy](#ReclaimPolicy) | ReclaimPolicy specifies what will happen to the external resource this managed resource manages when the managed resource is deleted. "Delete" deletes the external resource, while "Retain" (the default) does not. Note this behaviour is subtly different from other uses of the ReclaimPolicy concept within the Kubernetes ecosystem per https://github.com/crossplaneio/crossplane-runtime/issues/21
-
-
-
-## ResourceStatus
-
-ResourceStatus represents the observed state of a managed resource.
-
-
-
-
-ResourceStatus supports all fields of:
-
-* [ConditionedStatus](#ConditionedStatus)
-* [BindingStatus](#BindingStatus)
-
-
-## SecretKeySelector
-
-A SecretKeySelector is a reference to a secret key in an arbitrary namespace.
-
-
-Name | Type | Description
------|------|------------
-`key` | string | The key to select.
-
-
-SecretKeySelector supports all fields of:
-
-* [SecretReference](#SecretReference)
-
-
-## SecretReference
-
-A SecretReference is a reference to a secret in an arbitrary namespace.
-
-Appears in:
-
-* [ResourceSpec](#ResourceSpec)
-* [SecretKeySelector](#SecretKeySelector)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name of the secret.
-`namespace` | string | Namespace of the secret.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/crossplane/cache-crossplane-io-v1alpha1.md b/docs/v0.4/api/crossplaneio/crossplane/cache-crossplane-io-v1alpha1.md
deleted file mode 100644
index 67d234c0..00000000
--- a/docs/v0.4/api/crossplaneio/crossplane/cache-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# cache.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains portable resource claims for caching services such as Redis clusters.
-
-This API group contains the following Crossplane resources:
-
-* [RedisCluster](#RedisCluster)
-
-## RedisCluster
-
-A RedisCluster is a portable resource claim that may be satisfied by binding to a Redis managed resource such as a GCP CloudMemorystore instance or an AWS ReplicationGroup. Despite the name RedisCluster claims may bind to Redis managed resources that are a single node, or not in cluster mode.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.crossplane.io/v1alpha1`
-`kind` | string | `RedisCluster`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [RedisClusterSpec](#RedisClusterSpec) | RedisClusterSpec specifies the desired state of a RedisCluster.
-`status` | [v1alpha1.ResourceClaimStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimstatus) |
-
-
-
-## RedisClusterSpec
-
-RedisClusterSpec specifies the desired state of a RedisCluster.
-
-Appears in:
-
-* [RedisCluster](#RedisCluster)
-
-
-Name | Type | Description
------|------|------------
-`engineVersion` | string | EngineVersion specifies the desired Redis version.
-
-
-RedisClusterSpec supports all fields of:
-
-* [v1alpha1.ResourceClaimSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimspec)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/crossplane/compute-crossplane-io-v1alpha1.md b/docs/v0.4/api/crossplaneio/crossplane/compute-crossplane-io-v1alpha1.md
deleted file mode 100644
index af8eb2f4..00000000
--- a/docs/v0.4/api/crossplaneio/crossplane/compute-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,75 +0,0 @@
-# compute.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains portable resource claims for compute services such as Kubernetes clusters.
-
-This API group contains the following Crossplane resources:
-
-* [KubernetesCluster](#KubernetesCluster)
-* [MachineInstance](#MachineInstance)
-
-## KubernetesCluster
-
-A KubernetesCluster is a portable resource claim that may be satisfied by binding to a Kubernetes cluster managed resource such as an AWS EKS cluster or an Azure AKS cluster.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.crossplane.io/v1alpha1`
-`kind` | string | `KubernetesCluster`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [KubernetesClusterSpec](#KubernetesClusterSpec) | KubernetesClusterSpec specifies the desired state of a KubernetesCluster.
-`status` | [v1alpha1.ResourceClaimStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimstatus) |
-
-
-
-## MachineInstance
-
-A MachineInstance is a portable resource claim that may be satisfied by binding to a machine instance, which may include Virtual Machine managed resources such as an AWS EC2 instance or bare metal managed resources such as a Packet Device.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.crossplane.io/v1alpha1`
-`kind` | string | `MachineInstance`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [MachineInstanceSpec](#MachineInstanceSpec) | MachineInstanceSpec specifies the desired state of a MachineInstance.
-`status` | [v1alpha1.ResourceClaimStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimstatus) |
-
-
-
-## KubernetesClusterSpec
-
-KubernetesClusterSpec specifies the desired state of a KubernetesCluster.
-
-Appears in:
-
-* [KubernetesCluster](#KubernetesCluster)
-
-
-Name | Type | Description
------|------|------------
-`clusterVersion` | string | ClusterVersion specifies the desired Kubernetes version, e.g. 1.15.
-
-
-KubernetesClusterSpec supports all fields of:
-
-* [v1alpha1.ResourceClaimSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimspec)
-
-
-## MachineInstanceSpec
-
-MachineInstanceSpec specifies the desired state of a MachineInstance.
-
-Appears in:
-
-* [MachineInstance](#MachineInstance)
-
-
-
-
-MachineInstanceSpec supports all fields of:
-
-* [v1alpha1.ResourceClaimSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimspec)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/crossplane/database-crossplane-io-v1alpha1.md b/docs/v0.4/api/crossplaneio/crossplane/database-crossplane-io-v1alpha1.md
deleted file mode 100644
index 9bfb5405..00000000
--- a/docs/v0.4/api/crossplaneio/crossplane/database-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,78 +0,0 @@
-# database.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains portable resource claims for database services such as MySQL or PostgreSQL.
-
-This API group contains the following Crossplane resources:
-
-* [MySQLInstance](#MySQLInstance)
-* [PostgreSQLInstance](#PostgreSQLInstance)
-
-## MySQLInstance
-
-A MySQLInstance is a portable resource claim that may be satisfied by binding to a MySQL managed resource such as an AWS RDS instance or a GCP CloudSQL instance.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.crossplane.io/v1alpha1`
-`kind` | string | `MySQLInstance`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [MySQLInstanceSpec](#MySQLInstanceSpec) | MySQLInstanceSpec specifies the desired state of a MySQLInstance.
-`status` | [v1alpha1.ResourceClaimStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimstatus) |
-
-
-
-## PostgreSQLInstance
-
-A PostgreSQLInstance is a portable resource claim that may be satisfied by binding to a PostgreSQL managed resource such as an AWS RDS instance or a GCP CloudSQL instance.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.crossplane.io/v1alpha1`
-`kind` | string | `PostgreSQLInstance`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [PostgreSQLInstanceSpec](#PostgreSQLInstanceSpec) | PostgreSQLInstanceSpec specifies the desired state of a PostgreSQLInstance. PostgreSQLInstance.
-`status` | [v1alpha1.ResourceClaimStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimstatus) |
-
-
-
-## MySQLInstanceSpec
-
-MySQLInstanceSpec specifies the desired state of a MySQLInstance.
-
-Appears in:
-
-* [MySQLInstance](#MySQLInstance)
-
-
-Name | Type | Description
------|------|------------
-`engineVersion` | string | EngineVersion specifies the desired MySQL engine version, e.g. 5.7.
-
-
-MySQLInstanceSpec supports all fields of:
-
-* [v1alpha1.ResourceClaimSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimspec)
-
-
-## PostgreSQLInstanceSpec
-
-PostgreSQLInstanceSpec specifies the desired state of a PostgreSQLInstance. PostgreSQLInstance.
-
-Appears in:
-
-* [PostgreSQLInstance](#PostgreSQLInstance)
-
-
-Name | Type | Description
------|------|------------
-`engineVersion` | string | EngineVersion specifies the desired PostgreSQL engine version, e.g. 9.6.
-
-
-PostgreSQLInstanceSpec supports all fields of:
-
-* [v1alpha1.ResourceClaimSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimspec)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/crossplane/kubernetes-crossplane-io-v1alpha1.md b/docs/v0.4/api/crossplaneio/crossplane/kubernetes-crossplane-io-v1alpha1.md
deleted file mode 100644
index f9459117..00000000
--- a/docs/v0.4/api/crossplaneio/crossplane/kubernetes-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# kubernetes.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains resources relating to Crossplane Kubernetes.
-
-This API group contains the following Crossplane resources:
-
-* [Provider](#Provider)
-
-## Provider
-
-A Provider configures a Kubernetes 'provider', i.e. a connection to a particular Kubernetes cluster using the referenced Secret.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `kubernetes.crossplane.io/v1alpha1`
-`kind` | string | `Provider`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ProviderSpec](#ProviderSpec) | A ProviderSpec defines the desired state of a Provider.
-
-
-
-## ProviderSpec
-
-A ProviderSpec defines the desired state of a Provider.
-
-Appears in:
-
-* [Provider](#Provider)
-
-
-Name | Type | Description
------|------|------------
-`credentialsSecretRef` | [v1alpha1.SecretReference](../crossplane-runtime/core-crossplane-io-v1alpha1.md#secretreference) | A Secret containing connection credentials for a Kubernetes cluster client that will be used to authenticate to this Kubernetes Provider. This will typically be the connection secret of a KubernetesCluster claim, or the secret created by a Kubernetes service account, but could also be manually configured to connect to a preexisting cluster.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/crossplane/stacks-crossplane-io-v1alpha1.md b/docs/v0.4/api/crossplaneio/crossplane/stacks-crossplane-io-v1alpha1.md
deleted file mode 100644
index 3359301d..00000000
--- a/docs/v0.4/api/crossplaneio/crossplane/stacks-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,260 +0,0 @@
-# stacks.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains resources relating to Crossplane Stacks.
-
-This API group contains the following Crossplane resources:
-
-* [ClusterStackInstall](#ClusterStackInstall)
-* [Stack](#Stack)
-* [StackInstall](#StackInstall)
-
-## ClusterStackInstall
-
-ClusterStackInstall is the CRD type for a request to add a stack to Crossplane.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `stacks.crossplane.io/v1alpha1`
-`kind` | string | `ClusterStackInstall`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [StackInstallSpec](#StackInstallSpec) | StackInstallSpec specifies details about a request to install a stack to Crossplane.
-`status` | [StackInstallStatus](#StackInstallStatus) | StackInstallStatus represents the observed state of a StackInstall.
-
-
-
-## Stack
-
-A Stack that has been added to Crossplane.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `stacks.crossplane.io/v1alpha1`
-`kind` | string | `Stack`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [StackSpec](#StackSpec) | StackSpec specifies the desired state of a Stack.
-`status` | [StackStatus](#StackStatus) | StackStatus represents the observed state of a Stack.
-
-
-
-## StackInstall
-
-A StackInstall requests a stack be installed to Crossplane.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `stacks.crossplane.io/v1alpha1`
-`kind` | string | `StackInstall`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [StackInstallSpec](#StackInstallSpec) | StackInstallSpec specifies details about a request to install a stack to Crossplane.
-`status` | [StackInstallStatus](#StackInstallStatus) | StackInstallStatus represents the observed state of a StackInstall.
-
-
-
-## AppMetadataSpec
-
-AppMetadataSpec defines metadata about the stack application
-
-Appears in:
-
-* [StackSpec](#StackSpec)
-
-
-Name | Type | Description
------|------|------------
-`title` | string |
-`overviewShort` | string |
-`overview` | string |
-`readme` | string |
-`version` | string |
-`icons` | [[]IconSpec](#IconSpec) |
-`maintainers` | [[]ContributorSpec](#ContributorSpec) |
-`owners` | [[]ContributorSpec](#ContributorSpec) |
-`company` | string |
-`category` | string |
-`keywords` | []string |
-`website` | string |
-`source` | string |
-`license` | string |
-`dependsOn` | [[]StackInstallSpec](#StackInstallSpec) | DependsOn is the list of CRDs that this stack depends on. This data drives the dependency resolution process.
-`permissionScope` | string |
-
-
-
-## ContributorSpec
-
-ContributorSpec defines a contributor for a stack (e.g., maintainer, owner, etc.)
-
-Appears in:
-
-* [AppMetadataSpec](#AppMetadataSpec)
-
-
-Name | Type | Description
------|------|------------
-`name` | string |
-`email` | string |
-
-
-
-## ControllerDeployment
-
-ControllerDeployment defines a controller for a stack that is managed by a Deployment.
-
-Appears in:
-
-* [ControllerSpec](#ControllerSpec)
-
-
-Name | Type | Description
------|------|------------
-`name` | string |
-`spec` | [apps/v1.DeploymentSpec](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#deploymentspec-v1-apps) |
-
-
-
-## ControllerJob
-
-ControllerJob defines a controller for a stack that is installed by a Job.
-
-Appears in:
-
-* [ControllerSpec](#ControllerSpec)
-
-
-Name | Type | Description
------|------|------------
-`name` | string |
-`spec` | [batch/v1.JobSpec](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#jobspec-v1-batch) |
-
-
-
-## ControllerSpec
-
-ControllerSpec defines the controller that implements the logic for a stack, which can come in different flavors. A golang code (controller-runtime) controller with a managing Deployment is all that is supported currently, but more types will come in the future (e.g., templates, functions/hooks, templates, a new DSL, etc.
-
-Appears in:
-
-* [StackSpec](#StackSpec)
-
-
-Name | Type | Description
------|------|------------
-`deployment` | [ControllerDeployment](#ControllerDeployment) |
-`job` | [ControllerJob](#ControllerJob) |
-
-
-
-## IconSpec
-
-IconSpec defines the icon for a stack
-
-Appears in:
-
-* [AppMetadataSpec](#AppMetadataSpec)
-
-
-Name | Type | Description
------|------|------------
-`base64Data` | string |
-`mediatype` | string |
-
-
-
-## PermissionsSpec
-
-PermissionsSpec defines the permissions that a stack will require to operate.
-
-Appears in:
-
-* [StackSpec](#StackSpec)
-
-
-Name | Type | Description
------|------|------------
-`rules` | [[]rbac/v1.PolicyRule](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#policyrule-v1-rbac) |
-
-
-
-## StackInstallSpec
-
-StackInstallSpec specifies details about a request to install a stack to Crossplane.
-
-Appears in:
-
-* [ClusterStackInstall](#ClusterStackInstall)
-* [StackInstall](#StackInstall)
-* [AppMetadataSpec](#AppMetadataSpec)
-
-
-Name | Type | Description
------|------|------------
-`source` | string | Source is the domain name for the stack registry hosting the stack being requested, e.g., registry.crossplane.io
-`package` | string | Package is the name of the stack package that is being requested, e.g., myapp. Either Package or CustomResourceDefinition can be specified.
-`crd` | string | CustomResourceDefinition is the full name of a CRD that is owned by the stack being requested. This can be a convenient way of installing a stack when the desired CRD is known, but the package name that contains it is not known. Either Package or CustomResourceDefinition can be specified.
-
-
-
-## StackInstallStatus
-
-StackInstallStatus represents the observed state of a StackInstall.
-
-Appears in:
-
-* [ClusterStackInstall](#ClusterStackInstall)
-* [StackInstall](#StackInstall)
-
-
-Name | Type | Description
------|------|------------
-`conditionedStatus` | [v1alpha1.ConditionedStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#conditionedstatus) |
-`installJob` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) |
-`stackRecord` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) |
-
-
-
-## StackInstaller
-
-StackInstaller provides a common interface for StackInstall and ClusterStackInstall to share controller and reconciler logic
-
-
-## StackSpec
-
-StackSpec specifies the desired state of a Stack.
-
-Appears in:
-
-* [Stack](#Stack)
-
-
-Name | Type | Description
------|------|------------
-`customresourcedefinitions` | [CRDList](#CRDList) | CRDList is the full list of CRDs that this stack owns and depends on
-`controller` | [ControllerSpec](#ControllerSpec) | ControllerSpec defines the controller that implements the logic for a stack, which can come in different flavors. A golang code (controller-runtime) controller with a managing Deployment is all that is supported currently, but more types will come in the future (e.g., templates, functions/hooks, templates, a new DSL, etc.
-`permissions` | [PermissionsSpec](#PermissionsSpec) | PermissionsSpec defines the permissions that a stack will require to operate.
-
-
-StackSpec supports all fields of:
-
-* [AppMetadataSpec](#AppMetadataSpec)
-
-
-## StackStatus
-
-StackStatus represents the observed state of a Stack.
-
-Appears in:
-
-* [Stack](#Stack)
-
-
-Name | Type | Description
------|------|------------
-`conditionedStatus` | [v1alpha1.ConditionedStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#conditionedstatus) |
-`controllerRef` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) |
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/crossplane/storage-crossplane-io-v1alpha1.md b/docs/v0.4/api/crossplaneio/crossplane/storage-crossplane-io-v1alpha1.md
deleted file mode 100644
index 8b131fd3..00000000
--- a/docs/v0.4/api/crossplaneio/crossplane/storage-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,63 +0,0 @@
-# storage.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains portable resource claims for storage services such as buckets.
-
-This API group contains the following Crossplane resources:
-
-* [Bucket](#Bucket)
-
-## Bucket
-
-A Bucket is a portable resource claim that may be satisfied by binding to a storage bucket PostgreSQL managed resource such as an AWS S3 bucket or Azure storage container.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.crossplane.io/v1alpha1`
-`kind` | string | `Bucket`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [BucketSpec](#BucketSpec) | BucketSpec specifies the desired state of a Bucket.
-`status` | [v1alpha1.ResourceClaimStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimstatus) |
-
-
-
-## BucketSpec
-
-BucketSpec specifies the desired state of a Bucket.
-
-Appears in:
-
-* [Bucket](#Bucket)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name specifies the desired name of the bucket.
-`predefinedACL` | [PredefinedACL](#PredefinedACL) | PredefinedACL specifies a predefined ACL (e.g. Private, ReadWrite, etc) to be applied to the bucket.
-`localPermission` | [LocalPermissionType](#LocalPermissionType) | LocalPermission specifies permissions granted to a provider specific service account for this bucket, e.g. Read, ReadWrite, or Write.
-
-
-BucketSpec supports all fields of:
-
-* [v1alpha1.ResourceClaimSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourceclaimspec)
-
-
-## LocalPermissionType
-
-A LocalPermissionType is a type of permission that may be granted to a Bucket. Alias of string.
-
-Appears in:
-
-* [BucketSpec](#BucketSpec)
-
-
-## PredefinedACL
-
-A PredefinedACL is a predefined ACL that may be applied to a Bucket. Alias of string.
-
-Appears in:
-
-* [BucketSpec](#BucketSpec)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/crossplane/workload-crossplane-io-v1alpha1.md b/docs/v0.4/api/crossplaneio/crossplane/workload-crossplane-io-v1alpha1.md
deleted file mode 100644
index a9ee2a4c..00000000
--- a/docs/v0.4/api/crossplaneio/crossplane/workload-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,160 +0,0 @@
-# workload.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains resources relating to Crossplane Workloads.
-
-This API group contains the following Crossplane resources:
-
-* [KubernetesApplication](#KubernetesApplication)
-* [KubernetesApplicationResource](#KubernetesApplicationResource)
-
-## KubernetesApplication
-
-A KubernetesApplication defines an application deployed by Crossplane to a Kubernetes cluster, i.e. a portable KubernetesCluster resource claim.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `workload.crossplane.io/v1alpha1`
-`kind` | string | `KubernetesApplication`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [KubernetesApplicationSpec](#KubernetesApplicationSpec) | A KubernetesApplicationSpec specifies the resources of a Kubernetes application.
-`status` | [KubernetesApplicationStatus](#KubernetesApplicationStatus) | KubernetesApplicationStatus represents the observed state of a KubernetesApplication.
-
-
-
-## KubernetesApplicationResource
-
-A KubernetesApplicationResource is a resource of a Kubernetes application. Each resource templates a single Kubernetes resource to be deployed to its scheduled KubernetesCluster.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `workload.crossplane.io/v1alpha1`
-`kind` | string | `KubernetesApplicationResource`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [KubernetesApplicationResourceSpec](#KubernetesApplicationResourceSpec) | KubernetesApplicationResourceSpec specifies the desired state of a KubernetesApplicationResource.
-`status` | [KubernetesApplicationResourceStatus](#KubernetesApplicationResourceStatus) | KubernetesApplicationResourceStatus represents the observed state of a KubernetesApplicationResource.
-
-
-
-## KubernetesApplicationResourceSpec
-
-KubernetesApplicationResourceSpec specifies the desired state of a KubernetesApplicationResource.
-
-Appears in:
-
-* [KubernetesApplicationResource](#KubernetesApplicationResource)
-* [KubernetesApplicationResourceTemplate](#KubernetesApplicationResourceTemplate)
-
-
-Name | Type | Description
------|------|------------
-`template` | [meta/v1/unstructured.Unstructured](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#unstructured-unstructured-v1) | A Template for a Kubernetes resource to be submitted to the KubernetesCluster to which this application resource is scheduled. The resource must be understood by the KubernetesCluster. Crossplane requires only that the resource contains standard Kubernetes type and object metadata.
-`secrets` | [[]core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core) | Secrets upon which this application resource depends. These secrets will be propagated to the Kubernetes cluster to which this application is scheduled.
-
-
-
-## KubernetesApplicationResourceState
-
-KubernetesApplicationResourceState represents the state of a KubernetesApplicationResource. Alias of string.
-
-Appears in:
-
-* [KubernetesApplicationResourceStatus](#KubernetesApplicationResourceStatus)
-
-
-## KubernetesApplicationResourceStatus
-
-KubernetesApplicationResourceStatus represents the observed state of a KubernetesApplicationResource.
-
-Appears in:
-
-* [KubernetesApplicationResource](#KubernetesApplicationResource)
-
-
-Name | Type | Description
------|------|------------
-`conditionedStatus` | [v1alpha1.ConditionedStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#conditionedstatus) |
-`state` | [KubernetesApplicationResourceState](#KubernetesApplicationResourceState) | State of the application.
-`clusterRef` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | Cluster to which this application has been scheduled.
-`remote` | [RemoteStatus](#RemoteStatus) | Remote status of the resource templated by this application resource.
-
-
-
-## KubernetesApplicationResourceTemplate
-
-A KubernetesApplicationResourceTemplate is used to instantiate new KubernetesApplicationResources.
-
-Appears in:
-
-* [KubernetesApplicationSpec](#KubernetesApplicationSpec)
-
-
-Name | Type | Description
------|------|------------
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [KubernetesApplicationResourceSpec](#KubernetesApplicationResourceSpec) | KubernetesApplicationResourceSpec specifies the desired state of a KubernetesApplicationResource.
-
-
-
-## KubernetesApplicationSpec
-
-A KubernetesApplicationSpec specifies the resources of a Kubernetes application.
-
-Appears in:
-
-* [KubernetesApplication](#KubernetesApplication)
-
-
-Name | Type | Description
------|------|------------
-`resourceSelector` | [meta/v1.LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#labelselector-v1-meta) | ResourceSelector selects the KubernetesApplicationResources that are managed by this KubernetesApplication. Note that a KubernetesApplication will never adopt orphaned KubernetesApplicationResources, and thus this selector serves only to help match a KubernetesApplication to its KubernetesApplicationResources.
-`clusterSelector` | [meta/v1.LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#labelselector-v1-meta) | ClusterSelector selects the clusters to which this application may be scheduled. Leave both match labels and expressions empty to match any cluster.
-`resourceTemplates` | [[]KubernetesApplicationResourceTemplate](#KubernetesApplicationResourceTemplate) | ResourceTemplates specifies a set of Kubernetes application resources managed by this application.
-
-
-
-## KubernetesApplicationState
-
-KubernetesApplicationState represents the state of a Kubernetes application. Alias of string.
-
-Appears in:
-
-* [KubernetesApplicationStatus](#KubernetesApplicationStatus)
-
-
-## KubernetesApplicationStatus
-
-KubernetesApplicationStatus represents the observed state of a KubernetesApplication.
-
-Appears in:
-
-* [KubernetesApplication](#KubernetesApplication)
-
-
-Name | Type | Description
------|------|------------
-`conditionedStatus` | [v1alpha1.ConditionedStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#conditionedstatus) |
-`state` | [KubernetesApplicationState](#KubernetesApplicationState) | State of the application.
-`clusterRef` | [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | Cluster to which this application has been scheduled.
-`desiredResources` | int | Desired resources of this application, i.e. the number of resources that match this application's resource selector.
-`submittedResources` | int | Submitted resources of this workload, i.e. the subset of desired resources that have been successfully submitted to their scheduled Kubernetes cluster.
-
-
-
-## RemoteStatus
-
-RemoteStatus represents the observed state of a remote cluster.
-
-Appears in:
-
-* [KubernetesApplicationResourceStatus](#KubernetesApplicationResourceStatus)
-
-
-Name | Type | Description
------|------|------------
-`raw` | [encoding/json.RawMessage](https://golang.org/pkg/encoding/json#RawMessage) | Raw JSON representation of the remote status as a byte array.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-aws/aws-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-aws/aws-crossplane-io-v1alpha3.md
deleted file mode 100644
index 8ae39190..00000000
--- a/docs/v0.4/api/crossplaneio/stack-aws/aws-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# aws.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains core AWS resources.
-
-This API group contains the following Crossplane resources:
-
-* [Provider](#Provider)
-
-## Provider
-
-A Provider configures an AWS 'provider', i.e. a connection to a particular AWS account using a particular AWS IAM role.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `aws.crossplane.io/v1alpha3`
-`kind` | string | `Provider`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ProviderSpec](#ProviderSpec) | A ProviderSpec defines the desired state of a Provider.
-
-
-
-## ProviderSpec
-
-A ProviderSpec defines the desired state of a Provider.
-
-Appears in:
-
-* [Provider](#Provider)
-
-
-Name | Type | Description
------|------|------------
-`region` | string | Region for managed resources created using this AWS provider.
-`credentialsSecretRef` | [v1alpha1.SecretKeySelector](../crossplane-runtime/core-crossplane-io-v1alpha1.md#secretkeyselector) | A Secret containing INI encoded credentials for an AWS IAM role that will be used to authenticate to this AWS account.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-aws/cache-aws-crossplane-io-v1beta1.md b/docs/v0.4/api/crossplaneio/stack-aws/cache-aws-crossplane-io-v1beta1.md
deleted file mode 100644
index 267acc86..00000000
--- a/docs/v0.4/api/crossplaneio/stack-aws/cache-aws-crossplane-io-v1beta1.md
+++ /dev/null
@@ -1,308 +0,0 @@
-# cache.aws.crossplane.io/v1beta1 API Reference
-
-Package v1beta1 contains managed resources for AWS caching services such as ElastiCache.
-
-This API group contains the following Crossplane resources:
-
-* [ReplicationGroup](#ReplicationGroup)
-* [ReplicationGroupClass](#ReplicationGroupClass)
-
-## ReplicationGroup
-
-A ReplicationGroup is a managed resource that represents an AWS ElastiCache Replication Group.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.aws.crossplane.io/v1beta1`
-`kind` | string | `ReplicationGroup`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ReplicationGroupSpec](#ReplicationGroupSpec) | A ReplicationGroupSpec defines the desired state of a ReplicationGroup.
-`status` | [ReplicationGroupStatus](#ReplicationGroupStatus) | A ReplicationGroupStatus defines the observed state of a ReplicationGroup.
-
-
-
-## ReplicationGroupClass
-
-A ReplicationGroupClass is a resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.aws.crossplane.io/v1beta1`
-`kind` | string | `ReplicationGroupClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [ReplicationGroupClassSpecTemplate](#ReplicationGroupClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned ReplicationGroup.
-
-
-
-## Endpoint
-
-Endpoint represents the information required for client programs to connect to a cache node. Please also see https://docs.aws.amazon.com/goto/WebAPI/elasticache-2015-02-02/Endpoint
-
-Appears in:
-
-* [NodeGroup](#NodeGroup)
-* [NodeGroupMember](#NodeGroupMember)
-* [ReplicationGroupObservation](#ReplicationGroupObservation)
-
-
-Name | Type | Description
------|------|------------
-`address` | string | Address is the DNS hostname of the cache node.
-`port` | int | Port number that the cache engine is listening on.
-
-
-
-## MinorVersion
-
-MinorVersion represents a supported minor version of Redis. Alias of string.
-
-
-## NodeGroup
-
-NodeGroup represents a collection of cache nodes in a replication group. One node in the node group is the read/write primary node. All the other nodes are read-only Replica nodes. Please also see https://docs.aws.amazon.com/goto/WebAPI/elasticache-2015-02-02/NodeGroup
-
-Appears in:
-
-* [ReplicationGroupObservation](#ReplicationGroupObservation)
-
-
-Name | Type | Description
------|------|------------
-`port` | string | NodeGroupID is the identifier for the node group (shard). A Redis (cluster mode disabled) replication group contains only 1 node group; therefore, the node group ID is 0001. A Redis (cluster mode enabled) replication group contains 1 to 15 node groups numbered 0001 to 0015.
-`nodeGroupMembers` | [[]NodeGroupMember](#NodeGroupMember) | NodeGroupMembers is a list containing information about individual nodes within the node group (shard).
-`primaryEndpoint` | [Endpoint](#Endpoint) | PrimaryEndpoint is the endpoint of the primary node in this node group (shard).
-`slots` | string | Slots is the keyspace for this node group (shard).
-`status` | string | Status of this replication group - creating, available, etc.
-
-
-
-## NodeGroupConfigurationSpec
-
-A NodeGroupConfigurationSpec specifies the desired state of a node group.
-
-Appears in:
-
-* [ReplicationGroupParameters](#ReplicationGroupParameters)
-
-
-Name | Type | Description
------|------|------------
-`primaryAvailabilityZone` | Optional string | PrimaryAvailabilityZone specifies the Availability Zone where the primary node of this node group (shard) is launched.
-`replicaAvailabilityZones` | Optional []string | ReplicaAvailabilityZones specifies a list of Availability Zones to be used for the read replicas. The number of Availability Zones in this list must match the value of ReplicaCount or ReplicasPerNodeGroup if not specified.
-`replicaCount` | Optional int | ReplicaCount specifies the number of read replica nodes in this node group (shard).
-`slots` | Optional string | Slots specifies the keyspace for a particular node group. Keyspaces range from 0 to 16,383. The string is in the format startkey-endkey. Example: "0-3999"
-
-
-
-## NodeGroupMember
-
-NodeGroupMember represents a single node within a node group (shard). Please also see https://docs.aws.amazon.com/goto/WebAPI/elasticache-2015-02-02/NodeGroupMember
-
-Appears in:
-
-* [NodeGroup](#NodeGroup)
-
-
-Name | Type | Description
------|------|------------
-`cacheClusterId` | string | CacheClusterID is the ID of the cluster to which the node belongs.
-`cacheNodeId` | string | CacheNodeID is the ID of the node within its cluster. A node ID is a numeric identifier (0001, 0002, etc.).
-`currentRole` | string | CurrentRole is the role that is currently assigned to the node - primary or replica. This member is only applicable for Redis (cluster mode disabled) replication groups.
-`preferredAvailabilityZone` | string | PreferredAvailabilityZone is the name of the Availability Zone in which the node is located.
-`readEndpoint` | [Endpoint](#Endpoint) | ReadEndpoint is the information required for client programs to connect to a node for read operations. The read endpoint is only applicable on Redis (cluster mode disabled) clusters.
-
-
-
-## PatchVersion
-
-PatchVersion represents a supported patch version of Redis. Alias of string.
-
-
-## ReplicationGroupClassSpecTemplate
-
-A ReplicationGroupClassSpecTemplate is a template for the spec of a dynamically provisioned ReplicationGroup.
-
-Appears in:
-
-* [ReplicationGroupClass](#ReplicationGroupClass)
-
-
-Name | Type | Description
------|------|------------
-`forProvider` | [ReplicationGroupParameters](#ReplicationGroupParameters) | ReplicationGroupParameters define the desired state of an AWS ElastiCache Replication Group. Most fields map directly to an AWS ReplicationGroup: https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html#API_CreateReplicationGroup_RequestParameters
-
-
-ReplicationGroupClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-
-
-## ReplicationGroupObservation
-
-ReplicationGroupObservation contains the observation of the status of the given ReplicationGroup.
-
-Appears in:
-
-* [ReplicationGroupStatus](#ReplicationGroupStatus)
-
-
-Name | Type | Description
------|------|------------
-`automaticFailoverStatus` | string | AutomaticFailover indicates the status of Multi-AZ with automatic failover for this Redis replication group.
-`clusterEnabled` | bool | ClusterEnabled is a flag indicating whether or not this replication group is cluster enabled; i.e., whether its data can be partitioned across multiple shards (API/CLI: node groups).
-`configurationEndpoint` | [Endpoint](#Endpoint) | ConfigurationEndpoint for this replication group. Use the configuration endpoint to connect to this replication group.
-`memberClusters` | []string | MemberClusters is the list of names of all the cache clusters that are part of this replication group.
-`nodeGroups` | [[]NodeGroup](#NodeGroup) | NodeGroups is a list of node groups in this replication group. For Redis (cluster mode disabled) replication groups, this is a single-element list. For Redis (cluster mode enabled) replication groups, the list contains an entry for each node group (shard).
-`pendingModifiedValues` | [ReplicationGroupPendingModifiedValues](#ReplicationGroupPendingModifiedValues) | PendingModifiedValues is a group of settings to be applied to the replication group, either immediately or during the next maintenance window.
-`status` | string | Status is the current state of this replication group - creating, available, modifying, deleting, create-failed, snapshotting.
-
-
-
-## ReplicationGroupParameters
-
-ReplicationGroupParameters define the desired state of an AWS ElastiCache Replication Group. Most fields map directly to an AWS ReplicationGroup: https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html#API_CreateReplicationGroup_RequestParameters
-
-Appears in:
-
-* [ReplicationGroupClassSpecTemplate](#ReplicationGroupClassSpecTemplate)
-* [ReplicationGroupSpec](#ReplicationGroupSpec)
-
-
-Name | Type | Description
------|------|------------
-`applyModificationsImmediately` | bool | If true, this parameter causes the modifications in this request and any pending modifications to be applied, asynchronously and as soon as possible, regardless of the PreferredMaintenanceWindow setting for the replication group. If false, changes to the nodes in the replication group are applied on the next maintenance reboot, or the next failure reboot, whichever occurs first.
-`atRestEncryptionEnabled` | Optional bool | AtRestEncryptionEnabled enables encryption at rest when set to true. You cannot modify the value of AtRestEncryptionEnabled after the replication group is created. To enable encryption at rest on a replication group you must set AtRestEncryptionEnabled to true when you create the replication group. Only available when creating a replication group in an Amazon VPC using redis version 3.2.6 or 4.x.
-`authEnabled` | Optional bool | AuthEnabled enables mandatory authentication when connecting to the managed replication group. AuthEnabled requires TransitEncryptionEnabled to be true. While ReplicationGroupSpec mirrors the fields of the upstream replication group object as closely as possible, we expose a boolean here rather than requiring the operator pass in a string authentication token. Crossplane will generate a token automatically and expose it via a Secret.
-`automaticFailoverEnabled` | Optional bool | AutomaticFailoverEnabled specifies whether a read-only replica is automatically promoted to read/write primary if the existing primary fails. If true, Multi-AZ is enabled for this replication group. If false, Multi-AZ is disabled for this replication group. AutomaticFailoverEnabled must be enabled for Redis (cluster mode enabled) replication groups. Amazon ElastiCache for Redis does not support Multi-AZ with automatic failover on: * Redis versions earlier than 2.8.6. * Redis (cluster mode disabled): T1 and T2 cache node types. * Redis (cluster mode enabled): T1 node types.
-`cacheNodeType` | string | CacheNodeType specifies the compute and memory capacity of the nodes in the node group (shard). For a complete listing of node types and specifications, see: * Amazon ElastiCache Product Features and Details (http://aws.amazon.com/elasticache/details) * Cache Node Type-Specific Parameters for Memcached (http://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/ParameterGroups.Memcached.html#ParameterGroups.Memcached.NodeSpecific) * Cache Node Type-Specific Parameters for Redis (http://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html#ParameterGroups.Redis.NodeSpecific)
-`cacheParameterGroupName` | Optional string | CacheParameterGroupName specifies the name of the parameter group to associate with this replication group. If this argument is omitted, the default cache parameter group for the specified engine is used. If you are running Redis version 3.2.4 or later, only one node group (shard), and want to use a default parameter group, we recommend that you specify the parameter group by name. * To create a Redis (cluster mode disabled) replication group, use CacheParameterGroupName=default.redis3.2. * To create a Redis (cluster mode enabled) replication group, use CacheParameterGroupName=default.redis3.2.cluster.on.
-`cacheSecurityGroupNames` | Optional []string | CacheSecurityGroupNames specifies a list of cache security group names to associate with this replication group.
-`cacheSubnetGroupName` | Optional string | CacheSubnetGroupName specifies the name of the cache subnet group to be used for the replication group. If you're going to launch your cluster in an Amazon VPC, you need to create a subnet group before you start creating a cluster. For more information, see Subnets and Subnet Groups (http://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/SubnetGroups.html).
-`engine` | string | Engine is the name of the cache engine (memcached or redis) to be used for the clusters in this replication group.
-`engineVersion` | Optional string | EngineVersion specifies the version number of the cache engine to be used for the clusters in this replication group. To view the supported cache engine versions, use the DescribeCacheEngineVersions operation. Important: You can upgrade to a newer engine version (see Selecting a Cache Engine and Version (http://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/SelectEngine.html#VersionManagement)) in the ElastiCache User Guide, but you cannot downgrade to an earlier engine version. If you want to use an earlier engine version, you must delete the existing cluster or replication group and create it anew with the earlier engine version.
-`nodeGroupConfiguration` | Optional [[]NodeGroupConfigurationSpec](#NodeGroupConfigurationSpec) | NodeGroupConfigurationSpec specifies a list of node group (shard) configuration options. If you're creating a Redis (cluster mode disabled) or a Redis (cluster mode enabled) replication group, you can use this parameter to individually configure each node group (shard), or you can omit this parameter. However, when seeding a Redis (cluster mode enabled) cluster from a S3 rdb file, you must configure each node group (shard) using this parameter because you must specify the slots for each node group.
-`notificationTopicArn` | Optional string | NotificationTopicARN specifies the Amazon Resource Name (ARN) of the Amazon Simple Notification Service (SNS) topic to which notifications are sent. The Amazon SNS topic owner must be the same as the cluster owner.
-`notificationTopicStatus` | Optional string | NotificationTopicStatus is the status of the Amazon SNS notification topic for the replication group. Notifications are sent only if the status is active. Valid values: active | inactive
-`numCacheClusters` | Optional int | NumCacheClusters specifies the number of clusters this replication group initially has. This parameter is not used if there is more than one node group (shard). You should use ReplicasPerNodeGroup instead. If AutomaticFailoverEnabled is true, the value of this parameter must be at least 2. If AutomaticFailoverEnabled is false you can omit this parameter (it will default to 1), or you can explicitly set it to a value between 2 and 6. The maximum permitted value for NumCacheClusters is 6 (1 primary plus 5 replicas).
-`numNodeGroups` | Optional int | NumNodeGroups specifies the number of node groups (shards) for this Redis (cluster mode enabled) replication group. For Redis (cluster mode disabled) either omit this parameter or set it to 1. Default: 1
-`port` | Optional int | Port number on which each member of the replication group accepts connections.
-`preferredCacheClusterAzs` | Optional []string | PreferredCacheClusterAZs specifies a list of EC2 Availability Zones in which the replication group's clusters are created. The order of the Availability Zones in the list is the order in which clusters are allocated. The primary cluster is created in the first AZ in the list. This parameter is not used if there is more than one node group (shard). You should use NodeGroupConfigurationSpec instead. If you are creating your replication group in an Amazon VPC (recommended), you can only locate clusters in Availability Zones associated with the subnets in the selected subnet group. The number of Availability Zones listed must equal the value of NumCacheClusters. Default: system chosen Availability Zones.
-`preferredMaintenanceWindow` | Optional string | PreferredMaintenanceWindow specifies the weekly time range during which maintenance on the cluster is performed. It is specified as a range in the format ddd:hh24:mi-ddd:hh24:mi (24H Clock UTC). The minimum maintenance window is a 60 minute period. Example: sun:23:00-mon:01:30
-`primaryClusterId` | Optional string | PrimaryClusterId is the identifier of the cluster that serves as the primary for this replication group. This cluster must already exist and have a status of available. This parameter is not required if NumCacheClusters, NumNodeGroups or ReplicasPerNodeGroup is specified.
-`replicasPerNodeGroup` | Optional int | ReplicasPerNodeGroup specifies the number of replica nodes in each node group (shard). Valid values are 0 to 5.
-`replicationGroupDescription` | string | ReplicationGroupDescription is the description for the replication group.
-`securityGroupIds` | Optional []string | SecurityGroupIDs specifies one or more Amazon VPC security groups associated with this replication group. Use this parameter only when you are creating a replication group in an Amazon VPC.
-`snapshotArns` | Optional []string | SnapshotARNs specifies a list of Amazon Resource Names (ARN) that uniquely identify the Redis RDB snapshot files stored in Amazon S3. The snapshot files are used to populate the new replication group. The Amazon S3 object name in the ARN cannot contain any commas. The new replication group will have the number of node groups (console: shards) specified by the parameter NumNodeGroups or the number of node groups configured by NodeGroupConfigurationSpec regardless of the number of ARNs specified here.
-`snapshotName` | Optional string | SnapshotName specifies the name of a snapshot from which to restore data into the new replication group. The snapshot status changes to restoring while the new replication group is being created.
-`snapshotRetentionLimit` | Optional int | SnapshotRetentionLimit specifies the number of days for which ElastiCache retains automatic snapshots before deleting them. For example, if you set SnapshotRetentionLimit to 5, a snapshot that was taken today is retained for 5 days before being deleted. Default: 0 (i.e., automatic backups are disabled for this cluster).
-`snapshotWindow` | Optional string | SnapshotWindow specifies the daily time range (in UTC) during which ElastiCache begins taking a daily snapshot of your node group (shard). Example: 05:00-09:00 If you do not specify this parameter, ElastiCache automatically chooses an appropriate time range.
-`snapshottingClusterID` | Optional string | SnapshottingClusterID is used as the daily snapshot source for the replication group. This parameter cannot be set for Redis (cluster mode enabled) replication groups.
-`tags` | Optional [[]Tag](#Tag) | A list of cost allocation tags to be added to this resource. A tag is a key-value pair.
-`transitEncryptionEnabled` | Optional bool | TransitEncryptionEnabled enables in-transit encryption when set to true. You cannot modify the value of TransitEncryptionEnabled after the cluster is created. To enable in-transit encryption on a cluster you must TransitEncryptionEnabled to true when you create a cluster. This parameter is valid only if the Engine parameter is redis, the EngineVersion parameter is 3.2.6 or 4.x, and the cluster is being created in an Amazon VPC. If you enable in-transit encryption, you must also specify a value for CacheSubnetGroup. Required: Only available when creating a replication group in an Amazon VPC using redis version 3.2.6 or 4.x. Default: false For HIPAA compliance, you must specify TransitEncryptionEnabled as true, an AuthToken, and a CacheSubnetGroup.
-
-
-
-## ReplicationGroupPendingModifiedValues
-
-ReplicationGroupPendingModifiedValues are the settings to be applied to the Redis replication group, either immediately or during the next maintenance window. Please also see https://docs.aws.amazon.com/goto/WebAPI/elasticache-2015-02-02/ReplicationGroupPendingModifiedValues
-
-Appears in:
-
-* [ReplicationGroupObservation](#ReplicationGroupObservation)
-
-
-Name | Type | Description
------|------|------------
-`automaticFailoverStatus` | string | AutomaticFailoverStatus indicates the status of Multi-AZ with automatic failover for this Redis replication group.
-`primaryClusterId` | string | PrimaryClusterID that is applied immediately or during the next maintenance window.
-`resharding` | [ReshardingStatus](#ReshardingStatus) | Resharding is the status of an online resharding operation.
-
-
-
-## ReplicationGroupSpec
-
-A ReplicationGroupSpec defines the desired state of a ReplicationGroup.
-
-Appears in:
-
-* [ReplicationGroup](#ReplicationGroup)
-
-
-Name | Type | Description
------|------|------------
-`forProvider` | [ReplicationGroupParameters](#ReplicationGroupParameters) | ReplicationGroupParameters define the desired state of an AWS ElastiCache Replication Group. Most fields map directly to an AWS ReplicationGroup: https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html#API_CreateReplicationGroup_RequestParameters
-
-
-ReplicationGroupSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## ReplicationGroupStatus
-
-A ReplicationGroupStatus defines the observed state of a ReplicationGroup.
-
-Appears in:
-
-* [ReplicationGroup](#ReplicationGroup)
-
-
-Name | Type | Description
------|------|------------
-`atProvider` | [ReplicationGroupObservation](#ReplicationGroupObservation) | ReplicationGroupObservation contains the observation of the status of the given ReplicationGroup.
-
-
-ReplicationGroupStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## ReshardingStatus
-
-ReshardingStatus is the status of an online resharding operation. Please also see https://docs.aws.amazon.com/goto/WebAPI/elasticache-2015-02-02/ReshardingStatus
-
-Appears in:
-
-* [ReplicationGroupPendingModifiedValues](#ReplicationGroupPendingModifiedValues)
-
-
-Name | Type | Description
------|------|------------
-`slotMigration` | [SlotMigration](#SlotMigration) | Represents the progress of an online resharding operation.
-
-
-
-## SlotMigration
-
-SlotMigration represents the progress of an online resharding operation. Please also see https://docs.aws.amazon.com/goto/WebAPI/elasticache-2015-02-02/SlotMigration
-
-Appears in:
-
-* [ReshardingStatus](#ReshardingStatus)
-
-
-Name | Type | Description
------|------|------------
-`progressPercentage` | int | ProgressPercentage is the percentage of the slot migration that is complete.
-
-
-
-## Tag
-
-A Tag is used to tag the ElastiCache resources in AWS.
-
-Appears in:
-
-* [ReplicationGroupParameters](#ReplicationGroupParameters)
-
-
-Name | Type | Description
------|------|------------
-`key` | string | Key for the tag.
-`value` | string | Value of the tag.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-aws/compute-aws-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-aws/compute-aws-crossplane-io-v1alpha3.md
deleted file mode 100644
index dfa838f4..00000000
--- a/docs/v0.4/api/crossplaneio/stack-aws/compute-aws-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,263 +0,0 @@
-# compute.aws.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains managed resources for AWS compute services such as EKS.
-
-This API group contains the following Crossplane resources:
-
-* [EKSCluster](#EKSCluster)
-* [EKSClusterClass](#EKSClusterClass)
-
-## EKSCluster
-
-An EKSCluster is a managed resource that represents an AWS Elastic Kubernetes Service cluster.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.aws.crossplane.io/v1alpha3`
-`kind` | string | `EKSCluster`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [EKSClusterSpec](#EKSClusterSpec) | An EKSClusterSpec defines the desired state of an EKSCluster.
-`status` | [EKSClusterStatus](#EKSClusterStatus) | An EKSClusterStatus represents the observed state of an EKSCluster.
-
-
-
-## EKSClusterClass
-
-An EKSClusterClass is a resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.aws.crossplane.io/v1alpha3`
-`kind` | string | `EKSClusterClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [EKSClusterClassSpecTemplate](#EKSClusterClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned EKSCluster.
-
-
-
-## EKSClusterClassSpecTemplate
-
-An EKSClusterClassSpecTemplate is a template for the spec of a dynamically provisioned EKSCluster.
-
-Appears in:
-
-* [EKSClusterClass](#EKSClusterClass)
-
-
-
-
-EKSClusterClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-* [EKSClusterParameters](#EKSClusterParameters)
-
-
-## EKSClusterParameters
-
-EKSClusterParameters define the desired state of an AWS Elastic Kubernetes Service cluster.
-
-Appears in:
-
-* [EKSClusterClassSpecTemplate](#EKSClusterClassSpecTemplate)
-* [EKSClusterSpec](#EKSClusterSpec)
-
-
-Name | Type | Description
------|------|------------
-`region` | [EKSRegion](#EKSRegion) | Region for this EKS Cluster.
-`roleARN` | string | RoleARN: The Amazon Resource Name (ARN) of the IAM role that provides permis sions for Amazon EKS to make calls to other AWS API operations on your behalf. For more information, see 'Amazon EKS Service IAM Role' in the Amazon EKS User Guide.
-`roleARNRef` | [IAMRoleARNReferencerForEKSCluster](#IAMRoleARNReferencerForEKSCluster) | RoleARNRef references to an IAMRole to retrieve its ARN
-`vpcId` | string | VPCID is the ID of the VPC.
-`vpcIdRef` | [VPCIDReferencerForEKSCluster](#VPCIDReferencerForEKSCluster) | VPCIDRef references to a VPC to and retrieves its vpcId
-`subnetIds` | []string | SubnetIDs of this EKS cluster.
-`subnetIdRefs` | [[]*github.com/crossplaneio/stack-aws/apis/compute/v1alpha3.SubnetIDReferencerForEKSCluster](#*github.com/crossplaneio/stack-aws/apis/compute/v1alpha3.SubnetIDReferencerForEKSCluster) | SubnetIDRefs is a set of referencers that each retrieve the subnetID from the referenced Subnet
-`securityGroupIds` | []string | SecurityGroupIDs of this EKS cluster.
-`securityGroupIdRefs` | [[]*github.com/crossplaneio/stack-aws/apis/compute/v1alpha3.SecurityGroupIDReferencerForEKSCluster](#*github.com/crossplaneio/stack-aws/apis/compute/v1alpha3.SecurityGroupIDReferencerForEKSCluster) | SecurityGroupIDRefs is a set of referencers that each retrieve the ID from the referenced SecurityGroup
-`clusterVersion` | Optional string | ClusterVersion: The desired Kubernetes version of this EKS Cluster. If you do not specify a value here, the latest version available is used.
-`workerNodes` | [WorkerNodesSpec](#WorkerNodesSpec) | WorkerNodes configuration for cloudformation
-`mapRoles` | Optional [[]MapRole](#MapRole) | MapRoles map AWS roles to one or more Kubernetes groups. A Default role that allows nodes access to communicate with master is autogenerated when a node pool comes online.
-`mapUsers` | Optional [[]MapUser](#MapUser) | MapUsers map AWS users to one or more Kubernetes groups.
-
-
-
-## EKSClusterSpec
-
-An EKSClusterSpec defines the desired state of an EKSCluster.
-
-Appears in:
-
-* [EKSCluster](#EKSCluster)
-
-
-
-
-EKSClusterSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [EKSClusterParameters](#EKSClusterParameters)
-
-
-## EKSClusterStatus
-
-An EKSClusterStatus represents the observed state of an EKSCluster.
-
-Appears in:
-
-* [EKSCluster](#EKSCluster)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State of the cluster.
-`resourceName` | string | ClusterName of the cluster.
-`resourceVersion` | string | ClusterVersion of the cluster.
-`endpoint` | string | Endpoint for connecting to the cluster.
-`cloudformationStackId` | string | CloudFormationStackID of the Stack used to create node groups.
-
-
-EKSClusterStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## EKSRegion
-
-EKSRegion represents an EKS enabled AWS region. Alias of string.
-
-Appears in:
-
-* [EKSClusterParameters](#EKSClusterParameters)
-
-
-## IAMRoleARNReferencerForEKSCluster
-
-IAMRoleARNReferencerForEKSCluster is an attribute referencer that retrieves IAMRoleARN from a referenced IAMRole
-
-Appears in:
-
-* [EKSClusterParameters](#EKSClusterParameters)
-
-
-
-
-IAMRoleARNReferencerForEKSCluster supports all fields of:
-
-* github.com/crossplaneio/stack-aws/apis/identity/v1alpha3.IAMRoleARNReferencer
-
-
-## MapRole
-
-MapRole maps an AWS IAM role to one or more Kubernetes groups. See https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html and https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/README.md
-
-Appears in:
-
-* [EKSClusterParameters](#EKSClusterParameters)
-
-
-Name | Type | Description
------|------|------------
-`rolearn` | string | RoleARN to match, e.g. 'arn:aws:iam::000000000000:role/KubernetesNode'.
-`username` | string | Username (in Kubernetes) the RoleARN should map to.
-`groups` | []string | Groups (in Kubernetes) the RoleARN should map to.
-
-
-
-## MapUser
-
-MapUser maps an AWS IAM user to one or more Kubernetes groups. See https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html and https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/README.md
-
-Appears in:
-
-* [EKSClusterParameters](#EKSClusterParameters)
-
-
-Name | Type | Description
------|------|------------
-`userarn` | string | UserARN to match, e.g. 'arn:aws:iam::000000000000:user/Alice'
-`username` | string | Username (in Kubernetes) the UserARN should map to.
-`groups` | []string | Groups (in Kubernetes) the UserARN should map to.
-
-
-
-## SecurityGroupIDReferencerForEKSCluster
-
-SecurityGroupIDReferencerForEKSCluster is an attribute referencer that resolves ID from a referenced SecurityGroup
-
-
-
-
-SecurityGroupIDReferencerForEKSCluster supports all fields of:
-
-* github.com/crossplaneio/stack-aws/apis/network/v1alpha3.SecurityGroupIDReferencer
-
-
-## SecurityGroupIDReferencerForEKSWorkerNodes
-
-SecurityGroupIDReferencerForEKSWorkerNodes is an attribute referencer that resolves ID from a referenced SecurityGroup
-
-Appears in:
-
-* [WorkerNodesSpec](#WorkerNodesSpec)
-
-
-
-
-SecurityGroupIDReferencerForEKSWorkerNodes supports all fields of:
-
-* github.com/crossplaneio/stack-aws/apis/network/v1alpha3.SecurityGroupIDReferencer
-
-
-## SubnetIDReferencerForEKSCluster
-
-SubnetIDReferencerForEKSCluster is an attribute referencer that resolves SubnetID from a referenced Subnet
-
-
-
-
-SubnetIDReferencerForEKSCluster supports all fields of:
-
-* github.com/crossplaneio/stack-aws/apis/network/v1alpha3.SubnetIDReferencer
-
-
-## VPCIDReferencerForEKSCluster
-
-VPCIDReferencerForEKSCluster is an attribute referencer that resolves VPCID from a referenced VPC
-
-Appears in:
-
-* [EKSClusterParameters](#EKSClusterParameters)
-
-
-
-
-VPCIDReferencerForEKSCluster supports all fields of:
-
-* github.com/crossplaneio/stack-aws/apis/network/v1alpha3.VPCIDReferencer
-
-
-## WorkerNodesSpec
-
-WorkerNodesSpec - Worker node spec used to define cloudformation template that provisions workers for cluster
-
-Appears in:
-
-* [EKSClusterParameters](#EKSClusterParameters)
-
-
-Name | Type | Description
------|------|------------
-`keyName` | Optional string | KeyName of the EC2 Key Pair to allow SSH access to the EC2 instances.
-`nodeImageId` | Optional string | NodeImageId that the EC2 instances should run. Defaults to the region's standard AMI.
-`nodeInstanceType` | string | NodeInstanceType of the EC2 instances.
-`nodeAutoScalingGroupMinSize` | Optional int | NodeAutoScalingGroupMinSize configures the minimum size of this node group's Autoscaling Group. Defaults to 1.
-`nodeAutoScalingGroupMaxSize` | Optional int | NodeAutoScalingGroupMaxSize configures the maximum size of this node group's Autoscaling Group. Defaults to 3.
-`nodeVolumeSize` | Optional int | NodeVolumeSize configures the volume size in GB. Defaults to 20.
-`bootstrapArguments` | Optional string | BootstrapArguments to pass to the bootstrap script. See files/bootstrap.sh in https://github.com/awslabs/amazon-eks-ami
-`nodeGroupName` | Optional string | NodeGroupName is a unique identifier for the Node Group.
-`clusterControlPlaneSecurityGroup` | Optional string | ClusterControlPlaneSecurityGroup configures the security group of the cluster control plane in order to allow communication to this node group.
-`clusterControlPlaneSecurityGroupRef` | [SecurityGroupIDReferencerForEKSWorkerNodes](#SecurityGroupIDReferencerForEKSWorkerNodes) | ClusterControlPlaneSecurityGroupRef references to a SecurityGroup to retrieve its ID
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-aws/database-aws-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-aws/database-aws-crossplane-io-v1alpha3.md
deleted file mode 100644
index fdbd0ce4..00000000
--- a/docs/v0.4/api/crossplaneio/stack-aws/database-aws-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,151 +0,0 @@
-# database.aws.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains managed resources for AWS database services such as RDS.
-
-This API group contains the following Crossplane resources:
-
-* [DBSubnetGroup](#DBSubnetGroup)
-
-## DBSubnetGroup
-
-A DBSubnetGroup is a managed resource that represents an AWS VPC Database Subnet Group.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.aws.crossplane.io/v1alpha3`
-`kind` | string | `DBSubnetGroup`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [DBSubnetGroupSpec](#DBSubnetGroupSpec) | A DBSubnetGroupSpec defines the desired state of a DBSubnetGroup.
-`status` | [DBSubnetGroupStatus](#DBSubnetGroupStatus) | A DBSubnetGroupStatus represents the observed state of a DBSubnetGroup.
-
-
-
-## DBSubnetGroupExternalStatus
-
-DBSubnetGroupExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [DBSubnetGroupStatus](#DBSubnetGroupStatus)
-
-
-Name | Type | Description
------|------|------------
-`groupArn` | string | The Amazon Resource Name (ARN) for the DB subnet group.
-`groupStatus` | string | Provides the status of the DB subnet group.
-`subnets` | [[]Subnet](#Subnet) | Contains a list of Subnet elements.
-`vpcId` | string | Provides the VpcId of the DB subnet group.
-
-
-
-## DBSubnetGroupNameReferencer
-
-DBSubnetGroupNameReferencer is used to get a Name from another DBSubnetGroup
-
-
-
-
-DBSubnetGroupNameReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## DBSubnetGroupParameters
-
-DBSubnetGroupParameters define the desired state of an AWS VPC Database Subnet Group.
-
-Appears in:
-
-* [DBSubnetGroupSpec](#DBSubnetGroupSpec)
-
-
-Name | Type | Description
------|------|------------
-`description` | string | The description for the DB subnet group.
-`groupName` | string | The name for the DB subnet group. This value is stored as a lowercase string.
-`subnetIds` | []string | The EC2 Subnet IDs for the DB subnet group.
-`subnetIdRefs` | [[]*github.com/crossplaneio/stack-aws/apis/database/v1alpha3.SubnetIDReferencerForDBSubnetGroup](#*github.com/crossplaneio/stack-aws/apis/database/v1alpha3.SubnetIDReferencerForDBSubnetGroup) | SubnetIDRefs is a set of referencers that each retrieve the subnetID from the referenced Subnet
-`tags` | [[]Tag](#Tag) | A list of tags. For more information, see Tagging Amazon RDS Resources (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html) in the Amazon RDS User Guide.
-
-
-
-## DBSubnetGroupSpec
-
-A DBSubnetGroupSpec defines the desired state of a DBSubnetGroup.
-
-Appears in:
-
-* [DBSubnetGroup](#DBSubnetGroup)
-
-
-
-
-DBSubnetGroupSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [DBSubnetGroupParameters](#DBSubnetGroupParameters)
-
-
-## DBSubnetGroupStatus
-
-A DBSubnetGroupStatus represents the observed state of a DBSubnetGroup.
-
-Appears in:
-
-* [DBSubnetGroup](#DBSubnetGroup)
-
-
-
-
-DBSubnetGroupStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [DBSubnetGroupExternalStatus](#DBSubnetGroupExternalStatus)
-
-
-## Subnet
-
-Subnet represents a aws subnet
-
-Appears in:
-
-* [DBSubnetGroupExternalStatus](#DBSubnetGroupExternalStatus)
-
-
-Name | Type | Description
------|------|------------
-`subnetID` | string | Specifies the identifier of the subnet.
-`subnetStatus` | string | Specifies the status of the subnet.
-
-
-
-## SubnetIDReferencerForDBSubnetGroup
-
-SubnetIDReferencerForDBSubnetGroup is an attribute referencer that resolves SubnetID from a referenced Subnet
-
-
-
-
-SubnetIDReferencerForDBSubnetGroup supports all fields of:
-
-* github.com/crossplaneio/stack-aws/apis/network/v1alpha3.SubnetIDReferencer
-
-
-## Tag
-
-Tag defines a tag
-
-Appears in:
-
-* [DBSubnetGroupParameters](#DBSubnetGroupParameters)
-
-
-Name | Type | Description
------|------|------------
-`key` | string | Key is the name of the tag.
-`value` | string | Value is the value of the tag.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-aws/database-aws-crossplane-io-v1beta1.md b/docs/v0.4/api/crossplaneio/stack-aws/database-aws-crossplane-io-v1beta1.md
deleted file mode 100644
index cad87633..00000000
--- a/docs/v0.4/api/crossplaneio/stack-aws/database-aws-crossplane-io-v1beta1.md
+++ /dev/null
@@ -1,545 +0,0 @@
-# database.aws.crossplane.io/v1beta1 API Reference
-
-Package v1beta1 contains managed resources for AWS database services such as RDS.
-
-This API group contains the following Crossplane resources:
-
-* [RDSInstance](#RDSInstance)
-* [RDSInstanceClass](#RDSInstanceClass)
-
-## RDSInstance
-
-An RDSInstance is a managed resource that represents an AWS Relational Database Service instance.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.aws.crossplane.io/v1beta1`
-`kind` | string | `RDSInstance`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [RDSInstanceSpec](#RDSInstanceSpec) | An RDSInstanceSpec defines the desired state of an RDSInstance.
-`status` | [RDSInstanceStatus](#RDSInstanceStatus) | An RDSInstanceStatus represents the observed state of an RDSInstance.
-
-
-
-## RDSInstanceClass
-
-An RDSInstanceClass is a resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.aws.crossplane.io/v1beta1`
-`kind` | string | `RDSInstanceClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [RDSInstanceClassSpecTemplate](#RDSInstanceClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned RDSInstance.
-
-
-
-## AvailabilityZone
-
-AvailabilityZone contains Availability Zone information. This data type is used as an element in the following data type: * OrderableDBInstanceOption Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/AvailabilityZone
-
-Appears in:
-
-* [SubnetInRDS](#SubnetInRDS)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name of the Availability Zone.
-
-
-
-## CloudwatchLogsExportConfiguration
-
-CloudwatchLogsExportConfiguration is the configuration setting for the log types to be enabled for export to CloudWatch Logs for a specific DB instance or DB cluster. The EnableLogTypes and DisableLogTypes arrays determine which logs will be exported (or not exported) to CloudWatch Logs. The values within these arrays depend on the DB engine being used. For more information, see Publishing Database Logs to Amazon CloudWatch Logs (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.html#USER_LogAccess.Procedural.UploadtoCloudWatch) in the Amazon RDS User Guide. Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/CloudwatchLogsExportConfiguration
-
-Appears in:
-
-* [RDSInstanceParameters](#RDSInstanceParameters)
-
-
-Name | Type | Description
------|------|------------
-`disableLogTypes` | []string | DisableLogTypes is the list of log types to disable.
-`enableLogTypes` | []string | EnableLogTypes is the list of log types to enable.
-
-
-
-## DBInstanceStatusInfo
-
-DBInstanceStatusInfo provides a list of status information for a DB instance. Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/DBInstanceStatusInfo
-
-Appears in:
-
-* [RDSInstanceObservation](#RDSInstanceObservation)
-
-
-Name | Type | Description
------|------|------------
-`message` | string | Message is the details of the error if there is an error for the instance. If the instance is not in an error state, this value is blank.
-`normal` | bool | Normal is true if the instance is operating normally, or false if the instance is in an error state.
-`status` | string | Status of the DB instance. For a StatusType of read replica, the values can be replicating, replication stop point set, replication stop point reached, error, stopped, or terminated.
-`statusType` | string | StatusType is currently "read replication."
-
-
-
-## DBParameterGroupStatus
-
-DBParameterGroupStatus is the status of the DB parameter group. This data type is used as a response element in the following actions: * CreateDBInstance * CreateDBInstanceReadReplica * DeleteDBInstance * ModifyDBInstance * RebootDBInstance * RestoreDBInstanceFromDBSnapshot Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/DBParameterGroupStatus
-
-Appears in:
-
-* [RDSInstanceObservation](#RDSInstanceObservation)
-
-
-Name | Type | Description
------|------|------------
-`dbParameterGroupName` | string | DBParameterGroupName is the name of the DP parameter group.
-`parameterApplyStatus` | string | ParameterApplyStatus is the status of parameter updates.
-
-
-
-## DBSecurityGroupMembership
-
-DBSecurityGroupMembership is used as a response element in the following actions: * ModifyDBInstance * RebootDBInstance * RestoreDBInstanceFromDBSnapshot * RestoreDBInstanceToPointInTime Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/DBSecurityGroupMembership
-
-Appears in:
-
-* [RDSInstanceObservation](#RDSInstanceObservation)
-
-
-Name | Type | Description
------|------|------------
-`dbSecurityGroupName` | string | DBSecurityGroupName is the name of the DB security group.
-`status` | string | Status is the status of the DB security group.
-
-
-
-## DBSubnetGroupInRDS
-
-DBSubnetGroupInRDS contains the details of an Amazon RDS DB subnet group. This data type is used as a response element in the DescribeDBSubnetGroups action. Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/DBSubnetGroup
-
-Appears in:
-
-* [RDSInstanceObservation](#RDSInstanceObservation)
-
-
-Name | Type | Description
------|------|------------
-`dbSubnetGroupArn` | string | DBSubnetGroupARN is the Amazon Resource Name (ARN) for the DB subnet group.
-`dbSubnetGroupDescription` | string | DBSubnetGroupDescription provides the description of the DB subnet group.
-`dbSubnetGroupName` | string | DBSubnetGroupName is the name of the DB subnet group.
-`subnetGroupStatus` | string | SubnetGroupStatus provides the status of the DB subnet group.
-`subnets` | [[]SubnetInRDS](#SubnetInRDS) | Subnets contains a list of Subnet elements.
-`vpcId` | string | VPCID provides the VPCID of the DB subnet group.
-
-
-
-## DBSubnetGroupNameReferencerForRDSInstance
-
-DBSubnetGroupNameReferencerForRDSInstance is an attribute referencer that retrieves the name from a referenced DBSubnetGroup
-
-Appears in:
-
-* [RDSInstanceParameters](#RDSInstanceParameters)
-
-
-
-
-DBSubnetGroupNameReferencerForRDSInstance supports all fields of:
-
-* github.com/crossplaneio/stack-aws/apis/database/v1alpha3.DBSubnetGroupNameReferencer
-
-
-## DomainMembership
-
-DomainMembership is an Active Directory Domain membership record associated with the DB instance. Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/DomainMembership
-
-Appears in:
-
-* [RDSInstanceObservation](#RDSInstanceObservation)
-
-
-Name | Type | Description
------|------|------------
-`domain` | string | Domain is the identifier of the Active Directory Domain.
-`fqdn` | string | FQDN us the fully qualified domain name of the Active Directory Domain.
-`iamRoleName` | string | IAMRoleName is the name of the IAM role to be used when making API calls to the Directory Service.
-`status` | string | Status of the DB instance's Active Directory Domain membership, such as joined, pending-join, failed etc).
-
-
-
-## Endpoint
-
-Endpoint is used as a response element in the following actions: * CreateDBInstance * DescribeDBInstances * DeleteDBInstance Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/Endpoint
-
-Appears in:
-
-* [RDSInstanceObservation](#RDSInstanceObservation)
-
-
-Name | Type | Description
------|------|------------
-`address` | string | Address specifies the DNS address of the DB instance.
-`hostedZoneId` | string | HostedZoneID specifies the ID that Amazon Route 53 assigns when you create a hosted zone.
-`port` | int | Port specifies the port that the database engine is listening on.
-
-
-
-## IAMRoleARNReferencerForRDSInstanceMonitoringRole
-
-IAMRoleARNReferencerForRDSInstanceMonitoringRole is an attribute referencer that retrieves an RDSInstance's MonitoringRoleARN from a referenced IAMRole.
-
-Appears in:
-
-* [RDSInstanceParameters](#RDSInstanceParameters)
-
-
-
-
-IAMRoleARNReferencerForRDSInstanceMonitoringRole supports all fields of:
-
-* github.com/crossplaneio/stack-aws/apis/identity/v1alpha3.IAMRoleARNReferencer
-
-
-## IAMRoleNameReferencerForRDSInstanceDomainRole
-
-IAMRoleNameReferencerForRDSInstanceDomainRole is an attribute referencer that retrieves an RDSInstance's DomainRoleName from a referenced IAMRole.
-
-Appears in:
-
-* [RDSInstanceParameters](#RDSInstanceParameters)
-
-
-
-
-IAMRoleNameReferencerForRDSInstanceDomainRole supports all fields of:
-
-* github.com/crossplaneio/stack-aws/apis/identity/v1alpha3.IAMRoleNameReferencer
-
-
-## OptionGroupMembership
-
-OptionGroupMembership provides information on the option groups the DB instance is a member of. Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/OptionGroupMembership
-
-Appears in:
-
-* [RDSInstanceObservation](#RDSInstanceObservation)
-
-
-Name | Type | Description
------|------|------------
-`optionGroupName` | string | OptionGroupName is the name of the option group that the instance belongs to.
-`status` | string | Status is the status of the DB instance's option group membership. Valid values are: in-sync, pending-apply, pending-removal, pending-maintenance-apply, pending-maintenance-removal, applying, removing, and failed.
-
-
-
-## PendingCloudwatchLogsExports
-
-PendingCloudwatchLogsExports is a list of the log types whose configuration is still pending. In other words, these log types are in the process of being activated or deactivated. Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/PendingCloudwatchLogsExports
-
-Appears in:
-
-* [PendingModifiedValues](#PendingModifiedValues)
-
-
-Name | Type | Description
------|------|------------
-`logTypesToDisable` | []string | LogTypesToDisable is list of log types that are in the process of being enabled. After they are enabled, these log types are exported to CloudWatch Logs.
-`logTypesToEnable` | []string | LogTypesToEnable is the log types that are in the process of being deactivated. After they are deactivated, these log types aren't exported to CloudWatch Logs.
-
-
-
-## PendingModifiedValues
-
-PendingModifiedValues is used as a response element in the ModifyDBInstance action. Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/PendingModifiedValues
-
-Appears in:
-
-* [RDSInstanceObservation](#RDSInstanceObservation)
-
-
-Name | Type | Description
------|------|------------
-`allocatedStorage` | int | AllocatedStorage contains the new AllocatedStorage size for the DB instance that will be applied or is currently being applied.
-`backupRetentionPeriod` | int | BackupRetentionPeriod specifies the pending number of days for which automated backups are retained.
-`caCertificateIdentifier` | string | CACertificateIdentifier specifies the identifier of the CA certificate for the DB instance.
-`dbInstanceClass` | string | DBInstanceClass contains the new DBInstanceClass for the DB instance that will be applied or is currently being applied.
-`dbSubnetGroupName` | string | DBSubnetGroupName is the new DB subnet group for the DB instance.
-`engineVersion` | string | EngineVersion indicates the database engine version.
-`iops` | int | IOPS specifies the new Provisioned IOPS value for the DB instance that will be applied or is currently being applied.
-`licenseModel` | string | LicenseModel is the license model for the DB instance. Valid values: license-included | bring-your-own-license | general-public-license
-`multiAZ` | bool | MultiAZ indicates that the Single-AZ DB instance is to change to a Multi-AZ deployment.
-`pendingCloudwatchLogsExports` | [PendingCloudwatchLogsExports](#PendingCloudwatchLogsExports) | PendingCloudwatchLogsExports is a list of the log types whose configuration is still pending. In other words, these log types are in the process of being activated or deactivated.
-`port` | int | Port specifies the pending port for the DB instance.
-`processorFeatures` | [[]ProcessorFeature](#ProcessorFeature) | ProcessorFeatures is the number of CPU cores and the number of threads per core for the DB instance class of the DB instance.
-`storageType` | string | StorageType specifies the storage type to be associated with the DB instance.
-
-
-
-## ProcessorFeature
-
-ProcessorFeature is a processor feature entry. For more information, see Configuring the Processor of the DB Instance Class (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html#USER_ConfigureProcessor) in the Amazon RDS User Guide. Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/ProcessorFeature
-
-Appears in:
-
-* [PendingModifiedValues](#PendingModifiedValues)
-* [RDSInstanceParameters](#RDSInstanceParameters)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name of the processor feature. Valid names are coreCount and threadsPerCore.
-`value` | string | Value of a processor feature name.
-
-
-
-## RDSInstanceClassSpecTemplate
-
-An RDSInstanceClassSpecTemplate is a template for the spec of a dynamically provisioned RDSInstance.
-
-Appears in:
-
-* [RDSInstanceClass](#RDSInstanceClass)
-
-
-Name | Type | Description
------|------|------------
-`forProvider` | [RDSInstanceParameters](#RDSInstanceParameters) | RDSInstanceParameters define the desired state of an AWS Relational Database Service instance.
-
-
-RDSInstanceClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-
-
-## RDSInstanceObservation
-
-RDSInstanceObservation is the representation of the current state that is observed.
-
-Appears in:
-
-* [RDSInstanceStatus](#RDSInstanceStatus)
-
-
-Name | Type | Description
------|------|------------
-`dbInstanceStatus` | string | DBInstanceStatus specifies the current state of this database.
-`dbInstanceArn` | string | DBInstanceArn is the Amazon Resource Name (ARN) for the DB instance.
-`dbParameterGroups` | [[]DBParameterGroupStatus](#DBParameterGroupStatus) | DBParameterGroups provides the list of DB parameter groups applied to this DB instance.
-`dbSecurityGroups` | [[]DBSecurityGroupMembership](#DBSecurityGroupMembership) | DBSecurityGroups provides List of DB security group elements containing only DBSecurityGroup.Name and DBSecurityGroup.Status subelements.
-`dbSubnetGroup` | [DBSubnetGroupInRDS](#DBSubnetGroupInRDS) | DBSubnetGroup specifies information on the subnet group associated with the DB instance, including the name, description, and subnets in the subnet group.
-`dbInstancePort` | int | DBInstancePort specifies the port that the DB instance listens on. If the DB instance is part of a DB cluster, this can be a different port than the DB cluster port.
-`dbResourceId` | string | DBResourceID is the AWS Region-unique, immutable identifier for the DB instance. This identifier is found in AWS CloudTrail log entries whenever the AWS KMS key for the DB instance is accessed.
-`domainMemberships` | [[]DomainMembership](#DomainMembership) | DomainMemberships is the Active Directory Domain membership records associated with the DB instance.
-`instanceCreateTime` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | InstanceCreateTime provides the date and time the DB instance was created.
-`endpoint` | [Endpoint](#Endpoint) | Endpoint specifies the connection endpoint.
-`enhancedMonitoringResourceArn` | string | EnhancedMonitoringResourceArn is the Amazon Resource Name (ARN) of the Amazon CloudWatch Logs log stream that receives the Enhanced Monitoring metrics data for the DB instance.
-`latestRestorableTime` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | LatestRestorableTime specifies the latest time to which a database can be restored with point-in-time restore.
-`optionGroupMemberships` | [[]OptionGroupMembership](#OptionGroupMembership) | OptionGroupMemberships provides the list of option group memberships for this DB instance.
-`pendingModifiedValues` | [PendingModifiedValues](#PendingModifiedValues) | PendingModifiedValues specifies that changes to the DB instance are pending. This element is only included when changes are pending. Specific changes are identified by subelements.
-`performanceInsightsEnabled` | bool | PerformanceInsightsEnabled is true if Performance Insights is enabled for the DB instance, and otherwise false.
-`readReplicaDBClusterIdentifiers` | []string | ReadReplicaDBClusterIdentifiers contains one or more identifiers of Aurora DB clusters to which the RDS DB instance is replicated as a Read Replica. For example, when you create an Aurora Read Replica of an RDS MySQL DB instance, the Aurora MySQL DB cluster for the Aurora Read Replica is shown. This output does not contain information about cross region Aurora Read Replicas.
-`readReplicaDBInstanceIdentifiers` | []string | ReadReplicaDBInstanceIdentifiers contains one or more identifiers of the Read Replicas associated with this DB instance.
-`readReplicaSourceDBInstanceIdentifier` | string | ReadReplicaSourceDBInstanceIdentifier contains the identifier of the source DB instance if this DB instance is a Read Replica.
-`secondaryAvailabilityZone` | string | SecondaryAvailabilityZone specifies the name of the secondary Availability Zone for a DB instance with multi-AZ support when it is present.
-`statusInfos` | [[]DBInstanceStatusInfo](#DBInstanceStatusInfo) | StatusInfos is the status of a Read Replica. If the instance is not a Read Replica, this is blank.
-`vpcSecurityGroups` | [[]VPCSecurityGroupMembership](#VPCSecurityGroupMembership) | VPCSecurityGroups provides a list of VPC security group elements that the DB instance belongs to.
-
-
-
-## RDSInstanceParameters
-
-RDSInstanceParameters define the desired state of an AWS Relational Database Service instance.
-
-Appears in:
-
-* [RDSInstanceClassSpecTemplate](#RDSInstanceClassSpecTemplate)
-* [RDSInstanceSpec](#RDSInstanceSpec)
-
-
-Name | Type | Description
------|------|------------
-`allocatedStorage` | Optional int | AllocatedStorage is the amount of storage (in gibibytes) to allocate for the DB instance. Type: Integer Amazon Aurora Not applicable. Aurora cluster volumes automatically grow as the amount of data in your database increases, though you are only charged for the space that you use in an Aurora cluster volume. MySQL Constraints to the amount of storage for each storage type are the following: * General Purpose (SSD) storage (gp2): Must be an integer from 20 to 16384. * Provisioned IOPS storage (io1): Must be an integer from 100 to 16384. * Magnetic storage (standard): Must be an integer from 5 to 3072. MariaDB Constraints to the amount of storage for each storage type are the following: * General Purpose (SSD) storage (gp2): Must be an integer from 20 to 16384. * Provisioned IOPS storage (io1): Must be an integer from 100 to 16384. * Magnetic storage (standard): Must be an integer from 5 to 3072. PostgreSQL Constraints to the amount of storage for each storage type are the following: * General Purpose (SSD) storage (gp2): Must be an integer from 20 to 16384. * Provisioned IOPS storage (io1): Must be an integer from 100 to 16384. * Magnetic storage (standard): Must be an integer from 5 to 3072. Oracle Constraints to the amount of storage for each storage type are the following: * General Purpose (SSD) storage (gp2): Must be an integer from 20 to 16384. * Provisioned IOPS storage (io1): Must be an integer from 100 to 16384. * Magnetic storage (standard): Must be an integer from 10 to 3072. SQL Server Constraints to the amount of storage for each storage type are the following: * General Purpose (SSD) storage (gp2): Enterprise and Standard editions: Must be an integer from 200 to 16384. Web and Express editions: Must be an integer from 20 to 16384. * Provisioned IOPS storage (io1): Enterprise and Standard editions: Must be an integer from 200 to 16384. Web and Express editions: Must be an integer from 100 to 16384. * Magnetic storage (standard): Enterprise and Standard editions: Must be an integer from 200 to 1024. Web and Express editions: Must be an integer from 20 to 1024.
-`autoMinorVersionUpgrade` | Optional bool | AutoMinorVersionUpgrade indicates that minor engine upgrades are applied automatically to the DB instance during the maintenance window. Default: true
-`availabilityZone` | Optional string | AvailabilityZone is the EC2 Availability Zone that the DB instance is created in. For information on AWS Regions and Availability Zones, see Regions and Availability Zones (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html). Default: A random, system-chosen Availability Zone in the endpoint's AWS Region. Example: us-east-1d Constraint: The AvailabilityZone parameter can't be specified if the MultiAZ parameter is set to true. The specified Availability Zone must be in the same AWS Region as the current endpoint.
-`backupRetentionPeriod` | Optional int | BackupRetentionPeriod is the number of days for which automated backups are retained. Setting this parameter to a positive number enables backups. Setting this parameter to 0 disables automated backups. Amazon Aurora Not applicable. The retention period for automated backups is managed by the DB cluster. For more information, see CreateDBCluster. Default: 1 Constraints: * Must be a value from 0 to 35 * Cannot be set to 0 if the DB instance is a source to Read Replicas
-`caCertificateIdentifier` | Optional string | CACertificateIdentifier indicates the certificate that needs to be associated with the instance.
-`characterSetName` | Optional string | CharacterSetName indicates that the DB instance should be associated with the specified CharacterSet for supported engines, Amazon Aurora Not applicable. The character set is managed by the DB cluster. For more information, see CreateDBCluster.
-`copyTagsToSnapshot` | Optional bool | CopyTagsToSnapshot should be true to copy all tags from the DB instance to snapshots of the DB instance, and otherwise false. The default is false.
-`dbClusterIdentifier` | Optional string | DBClusterIdentifier is the identifier of the DB cluster that the instance will belong to. For information on creating a DB cluster, see CreateDBCluster. Type: String
-`dbClusterParameterGroupName` | Optional string | DBClusterParameterGroupName is the name of the DB cluster parameter group to use for the DB cluster.
-`dbInstanceClass` | string | DBInstanceClass is the compute and memory capacity of the DB instance, for example, db.m4.large. Not all DB instance classes are available in all AWS Regions, or for all database engines. For the full list of DB instance classes, and availability for your engine, see DB Instance Class (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html) in the Amazon RDS User Guide.
-`dbName` | Optional string | DBName is the meaning of this parameter differs according to the database engine you use. Type: String MySQL The name of the database to create when the DB instance is created. If this parameter is not specified, no database is created in the DB instance. Constraints: * Must contain 1 to 64 letters or numbers. * Cannot be a word reserved by the specified database engine MariaDB The name of the database to create when the DB instance is created. If this parameter is not specified, no database is created in the DB instance. Constraints: * Must contain 1 to 64 letters or numbers. * Cannot be a word reserved by the specified database engine PostgreSQL The name of the database to create when the DB instance is created. If this parameter is not specified, the default "postgres" database is created in the DB instance. Constraints: * Must contain 1 to 63 letters, numbers, or underscores. * Must begin with a letter or an underscore. Subsequent characters can be letters, underscores, or digits (0-9). * Cannot be a word reserved by the specified database engine Oracle The Oracle System ID (SID) of the created DB instance. If you specify null, the default value ORCL is used. You can't specify the string NULL, or any other reserved word, for DBName. Default: ORCL Constraints: * Cannot be longer than 8 characters SQL Server Not applicable. Must be null. Amazon Aurora The name of the database to create when the primary instance of the DB cluster is created. If this parameter is not specified, no database is created in the DB instance. Constraints: * Must contain 1 to 64 letters or numbers. * Cannot be a word reserved by the specified database engine
-`dbSecurityGroups` | Optional []string | DBSecurityGroups is a list of DB security groups to associate with this DB instance. Default: The default DB security group for the database engine.
-`dbSubnetGroupName` | Optional string | DBSubnetGroupName is a DB subnet group to associate with this DB instance. If there is no DB subnet group, then it is a non-VPC DB instance.
-`dbSubnetGroupNameRef` | Optional [DBSubnetGroupNameReferencerForRDSInstance](#DBSubnetGroupNameReferencerForRDSInstance) | DBSubnetGroupNameRef is a reference to a DBSubnetGroup used to set DBSubnetGroupName.
-`deletionProtection` | Optional bool | DeletionProtection indicates if the DB instance should have deletion protection enabled. The database can't be deleted when this value is set to true. The default is false. For more information, see Deleting a DB Instance (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteInstance.html).
-`enableCloudwatchLogsExports` | Optional []string | EnableCloudwatchLogsExports is the list of log types that need to be enabled for exporting to CloudWatch Logs. The values in the list depend on the DB engine being used. For more information, see Publishing Database Logs to Amazon CloudWatch Logs (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.html#USER_LogAccess.Procedural.UploadtoCloudWatch) in the Amazon Relational Database Service User Guide.
-`enableIAMDatabaseAuthentication` | Optional bool | EnableIAMDatabaseAuthentication should be true to enable mapping of AWS Identity and Access Management (IAM) accounts to database accounts, and otherwise false. You can enable IAM database authentication for the following database engines: Amazon Aurora Not applicable. Mapping AWS IAM accounts to database accounts is managed by the DB cluster. For more information, see CreateDBCluster. MySQL * For MySQL 5.6, minor version 5.6.34 or higher * For MySQL 5.7, minor version 5.7.16 or higher Default: false
-`enablePerformanceInsights` | Optional bool | EnablePerformanceInsights should be true to enable Performance Insights for the DB instance, and otherwise false. For more information, see Using Amazon Performance Insights (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) in the Amazon Relational Database Service User Guide.
-`engine` | string | Engine is the name of the database engine to be used for this instance. Not every database engine is available for every AWS Region. Valid Values: * aurora (for MySQL 5.6-compatible Aurora) * aurora-mysql (for MySQL 5.7-compatible Aurora) * aurora-postgresql * mariadb * mysql * oracle-ee * oracle-se2 * oracle-se1 * oracle-se * postgres * sqlserver-ee * sqlserver-se * sqlserver-ex * sqlserver-web Engine is a required field
-`engineVersion` | Optional string | EngineVersion is the version number of the database engine to use. For a list of valid engine versions, call DescribeDBEngineVersions. The following are the database engines and links to information about the major and minor versions that are available with Amazon RDS. Not every database engine is available for every AWS Region. Amazon Aurora Not applicable. The version number of the database engine to be used by the DB instance is managed by the DB cluster. For more information, see CreateDBCluster. MariaDB See MariaDB on Amazon RDS Versions (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MariaDB.html#MariaDB.Concepts.VersionMgmt) in the Amazon RDS User Guide. Microsoft SQL Server See Version and Feature Support on Amazon RDS (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.FeatureSupport) in the Amazon RDS User Guide. MySQL See MySQL on Amazon RDS Versions (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.VersionMgmt) in the Amazon RDS User Guide. Oracle See Oracle Database Engine Release Notes (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.PatchComposition.html) in the Amazon RDS User Guide. PostgreSQL See Supported PostgreSQL Database Versions (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.DBVersions) in the Amazon RDS User Guide.
-`iops` | Optional int | IOPS is the amount of Provisioned IOPS (input/output operations per second) to be initially allocated for the DB instance. For information about valid IOPS values, see see Amazon RDS Provisioned IOPS Storage to Improve Performance (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html#USER_PIOPS) in the Amazon RDS User Guide. Constraints: Must be a multiple between 1 and 50 of the storage amount for the DB instance. Must also be an integer multiple of 1000. For example, if the size of your DB instance is 500 GiB, then your IOPS value can be 2000, 3000, 4000, or 5000.
-`kmsKeyId` | Optional string | KMSKeyID for an encrypted DB instance. The KMS key identifier is the Amazon Resource Name (ARN) for the KMS encryption key. If you are creating a DB instance with the same AWS account that owns the KMS encryption key used to encrypt the new DB instance, then you can use the KMS key alias instead of the ARN for the KM encryption key. Amazon Aurora Not applicable. The KMS key identifier is managed by the DB cluster. For more information, see CreateDBCluster. If the StorageEncrypted parameter is true, and you do not specify a value for the KMSKeyID parameter, then Amazon RDS will use your default encryption key. AWS KMS creates the default encryption key for your AWS account. Your AWS account has a different default encryption key for each AWS Region.
-`licenseModel` | Optional string | LicenseModel information for this DB instance. Valid values: license-included | bring-your-own-license | general-public-license
-`masterUserPassword` | Optional string | MasterUserPassword is the password for the master user. The password can include any printable ASCII character except "/", """, or "@". Amazon Aurora Not applicable. The password for the master user is managed by the DB cluster. For more information, see CreateDBCluster. MariaDB Constraints: Must contain from 8 to 41 characters. Microsoft SQL Server Constraints: Must contain from 8 to 128 characters. MySQL Constraints: Must contain from 8 to 41 characters. Oracle Constraints: Must contain from 8 to 30 characters. PostgreSQL Constraints: Must contain from 8 to 128 characters.
-`masterUsername` | Optional string | MasterUsername is the name for the master user. Amazon Aurora Not applicable. The name for the master user is managed by the DB cluster. For more information, see CreateDBCluster. MariaDB Constraints: * Required for MariaDB. * Must be 1 to 16 letters or numbers. * Cannot be a reserved word for the chosen database engine. Microsoft SQL Server Constraints: * Required for SQL Server. * Must be 1 to 128 letters or numbers. * The first character must be a letter. * Cannot be a reserved word for the chosen database engine. MySQL Constraints: * Required for MySQL. * Must be 1 to 16 letters or numbers. * First character must be a letter. * Cannot be a reserved word for the chosen database engine. Oracle Constraints: * Required for Oracle. * Must be 1 to 30 letters or numbers. * First character must be a letter. * Cannot be a reserved word for the chosen database engine. PostgreSQL Constraints: * Required for PostgreSQL. * Must be 1 to 63 letters or numbers. * First character must be a letter. * Cannot be a reserved word for the chosen database engine.
-`monitoringInterval` | Optional int | MonitoringInterval is the interval, in seconds, between points when Enhanced Monitoring metrics are collected for the DB instance. To disable collecting Enhanced Monitoring metrics, specify 0. The default is 0. If MonitoringRoleARN is specified, then you must also set MonitoringInterval to a value other than 0. Valid Values: 0, 1, 5, 10, 15, 30, 60
-`monitoringRoleArn` | Optional string | MonitoringRoleARN is the ARN for the IAM role that permits RDS to send enhanced monitoring metrics to Amazon CloudWatch Logs. For example, arn:aws:iam:123456789012:role/emaccess. For information on creating a monitoring role, go to Setting Up and Enabling Enhanced Monitoring (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html#USER_Monitoring.OS.Enabling) in the Amazon RDS User Guide. If MonitoringInterval is set to a value other than 0, then you must supply a MonitoringRoleARN value.
-`monitoringRoleArnRef` | Optional [IAMRoleARNReferencerForRDSInstanceMonitoringRole](#IAMRoleARNReferencerForRDSInstanceMonitoringRole) | MonitoringRoleARNRef is a reference to an IAMRole used to set MonitoringRoleARN.
-`multiAZ` | Optional bool | MultiAZ specifies if the DB instance is a Multi-AZ deployment. You can't set the AvailabilityZone parameter if the MultiAZ parameter is set to true.
-`performanceInsightsKMSKeyId` | Optional string | PerformanceInsightsKMSKeyID is the AWS KMS key identifier for encryption of Performance Insights data. The KMS key ID is the Amazon Resource Name (ARN), KMS key identifier, or the KMS key alias for the KMS encryption key.
-`performanceInsightsRetentionPeriod` | Optional int | PerformanceInsightsRetentionPeriod is the amount of time, in days, to retain Performance Insights data. Valid values are 7 or 731 (2 years).
-`port` | Optional int | Port number on which the database accepts connections. MySQL Default: 3306 Valid Values: 1150-65535 Type: Integer MariaDB Default: 3306 Valid Values: 1150-65535 Type: Integer PostgreSQL Default: 5432 Valid Values: 1150-65535 Type: Integer Oracle Default: 1521 Valid Values: 1150-65535 SQL Server Default: 1433 Valid Values: 1150-65535 except for 1434, 3389, 47001, 49152, and 49152 through 49156. Amazon Aurora Default: 3306 Valid Values: 1150-65535 Type: Integer
-`preferredBackupWindow` | Optional string | PreferredBackupWindow is the daily time range during which automated backups are created if automated backups are enabled, using the BackupRetentionPeriod parameter. For more information, see The Backup Window (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html#USER_WorkingWithAutomatedBackups.BackupWindow) in the Amazon RDS User Guide. Amazon Aurora Not applicable. The daily time range for creating automated backups is managed by the DB cluster. For more information, see CreateDBCluster. The default is a 30-minute window selected at random from an 8-hour block of time for each AWS Region. To see the time blocks available, see Adjusting the Preferred DB Instance Maintenance Window (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Maintenance.html#AdjustingTheMaintenanceWindow) in the Amazon RDS User Guide. Constraints: * Must be in the format hh24:mi-hh24:mi. * Must be in Universal Coordinated Time (UTC). * Must not conflict with the preferred maintenance window. * Must be at least 30 minutes.
-`preferredMaintenanceWindow` | Optional string | PreferredMaintenanceWindow is the time range each week during which system maintenance can occur, in Universal Coordinated Time (UTC). For more information, see Amazon RDS Maintenance Window (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Maintenance.html#Concepts.DBMaintenance). Format: ddd:hh24:mi-ddd:hh24:mi The default is a 30-minute window selected at random from an 8-hour block of time for each AWS Region, occurring on a random day of the week. Valid Days: Mon, Tue, Wed, Thu, Fri, Sat, Sun. Constraints: Minimum 30-minute window.
-`processorFeatures` | Optional [[]ProcessorFeature](#ProcessorFeature) | ProcessorFeatures is the number of CPU cores and the number of threads per core for the DB instance class of the DB instance.
-`promotionTier` | Optional int | PromotionTier specifies the order in which an Aurora Replica is promoted to the primary instance after a failure of the existing primary instance. For more information, see Fault Tolerance for an Aurora DB Cluster (http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.html#Aurora.Managing.FaultTolerance) in the Amazon Aurora User Guide. Default: 1 Valid Values: 0 - 15
-`publiclyAccessible` | Optional bool | PubliclyAccessible specifies the accessibility options for the DB instance. A value of true specifies an Internet-facing instance with a publicly resolvable DNS name, which resolves to a public IP address. A value of false specifies an internal instance with a DNS name that resolves to a private IP address. Default: The default behavior varies depending on whether DBSubnetGroupName is specified. If DBSubnetGroupName is not specified, and PubliclyAccessible is not specified, the following applies: * If the default VPC in the target region doesn’t have an Internet gateway attached to it, the DB instance is private. * If the default VPC in the target region has an Internet gateway attached to it, the DB instance is public. If DBSubnetGroupName is specified, and PubliclyAccessible is not specified, the following applies: * If the subnets are part of a VPC that doesn’t have an Internet gateway attached to it, the DB instance is private. * If the subnets are part of a VPC that has an Internet gateway attached to it, the DB instance is public.
-`scalingConfiguration` | Optional [ScalingConfiguration](#ScalingConfiguration) | ScalingConfiguration is the scaling properties of the DB cluster. You can only modify scaling properties for DB clusters in serverless DB engine mode.
-`storageEncrypted` | Optional bool | StorageEncrypted specifies whether the DB instance is encrypted. Amazon Aurora Not applicable. The encryption for DB instances is managed by the DB cluster. For more information, see CreateDBCluster. Default: false
-`storageType` | Optional string | StorageType specifies the storage type to be associated with the DB instance. Valid values: standard | gp2 | io1 If you specify io1, you must also include a value for the IOPS parameter. Default: io1 if the IOPS parameter is specified, otherwise standard
-`tags` | Optional [[]Tag](#Tag) | Tags. For more information, see Tagging Amazon RDS Resources (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html) in the Amazon RDS User Guide.
-`timezone` | Optional string | Timezone of the DB instance. The time zone parameter is currently supported only by Microsoft SQL Server (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.TimeZone).
-`vpcSecurityGroupIds` | Optional []string | VPCSecurityGroupIDs is a list of EC2 VPC security groups to associate with this DB instance. Amazon Aurora Not applicable. The associated list of EC2 VPC security groups is managed by the DB cluster. For more information, see CreateDBCluster. Default: The default EC2 VPC security group for the DB subnet group's VPC.
-`vpcSecurityGroupIDRefs` | Optional [[]*github.com/crossplaneio/stack-aws/apis/database/v1beta1.VPCSecurityGroupIDReferencerForRDSInstance](#*github.com/crossplaneio/stack-aws/apis/database/v1beta1.VPCSecurityGroupIDReferencerForRDSInstance) | VPCSecurityGroupIDRefs are references to VPCSecurityGroups used to set the VPCSecurityGroupIDs.
-`allowMajorVersionUpgrade` | Optional bool | AllowMajorVersionUpgrade indicates that major version upgrades are allowed. Changing this parameter doesn't result in an outage and the change is asynchronously applied as soon as possible. Constraints: This parameter must be set to true when specifying a value for the EngineVersion parameter that is a different major version than the DB instance's current version.
-`applyModificationsImmediately` | Optional bool | ApplyModificationsImmediately specifies whether the modifications in this request and any pending modifications are asynchronously applied as soon as possible, regardless of the PreferredMaintenanceWindow setting for the DB instance. If this parameter is set to false, changes to the DB instance are applied during the next maintenance window. Some parameter changes can cause an outage and are applied on the next call to RebootDBInstance, or the next failure reboot. Review the table of parameters in Modifying a DB Instance and Using the Apply Immediately Parameter (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html) in the Amazon RDS User Guide. to see the impact that setting ApplyImmediately to true or false has for each modified parameter and to determine when the changes are applied. Default: false
-`cloudwatchLogsExportConfiguration` | Optional [CloudwatchLogsExportConfiguration](#CloudwatchLogsExportConfiguration) | CloudwatchLogsExportConfiguration is the configuration setting for the log types to be enabled for export to CloudWatch Logs for a specific DB instance.
-`dbParameterGroupName` | Optional string | DBParameterGroupName is the name of the DB parameter group to associate with this DB instance. If this argument is omitted, the default DBParameterGroup for the specified engine is used. Constraints: * Must be 1 to 255 letters, numbers, or hyphens. * First character must be a letter * Cannot end with a hyphen or contain two consecutive hyphens
-`domain` | Optional string | Domain specifies the Active Directory Domain to create the instance in.
-`domainIAMRoleName` | Optional string | DomainIAMRoleName specifies the name of the IAM role to be used when making API calls to the Directory Service.
-`domainIAMRoleNameRef` | Optional [IAMRoleNameReferencerForRDSInstanceDomainRole](#IAMRoleNameReferencerForRDSInstanceDomainRole) | DomainIAMRoleNameRef is a reference to an IAMRole used to set DomainIAMRoleName.
-`optionGroupName` | Optional string | OptionGroupName indicates that the DB instance should be associated with the specified option group. Permanent options, such as the TDE option for Oracle Advanced Security TDE, can't be removed from an option group, and that option group can't be removed from a DB instance once it is associated with a DB instance
-`useDefaultProcessorFeatures` | bool | A value that specifies that the DB instance class of the DB instance uses its default processor features.
-`skipFinalSnapshotBeforeDeletion` | bool | Determines whether a final DB snapshot is created before the DB instance is deleted. If true is specified, no DBSnapshot is created. If false is specified, a DB snapshot is created before the DB instance is deleted. Note that when a DB instance is in a failure state and has a status of 'failed', 'incompatible-restore', or 'incompatible-network', it can only be deleted when the SkipFinalSnapshotBeforeDeletion parameter is set to "true". Specify true when deleting a Read Replica. The FinalDBSnapshotIdentifier parameter must be specified if SkipFinalSnapshotBeforeDeletion is false. Default: false
-`finalDBSnapshotIdentifier` | string | The DBSnapshotIdentifier of the new DBSnapshot created when SkipFinalSnapshot is set to false. Specifying this parameter and also setting the SkipFinalShapshot parameter to true results in an error. Constraints: * Must be 1 to 255 letters or numbers. * First character must be a letter * Cannot end with a hyphen or contain two consecutive hyphens * Cannot be specified when deleting a Read Replica.
-
-
-
-## RDSInstanceSpec
-
-An RDSInstanceSpec defines the desired state of an RDSInstance.
-
-Appears in:
-
-* [RDSInstance](#RDSInstance)
-
-
-Name | Type | Description
------|------|------------
-`forProvider` | [RDSInstanceParameters](#RDSInstanceParameters) | RDSInstanceParameters define the desired state of an AWS Relational Database Service instance.
-
-
-RDSInstanceSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## RDSInstanceState
-
-RDSInstanceState represents the state of an RDS instance. Alias of string.
-
-
-## RDSInstanceStatus
-
-An RDSInstanceStatus represents the observed state of an RDSInstance.
-
-Appears in:
-
-* [RDSInstance](#RDSInstance)
-
-
-Name | Type | Description
------|------|------------
-`atProvider` | [RDSInstanceObservation](#RDSInstanceObservation) | RDSInstanceObservation is the representation of the current state that is observed.
-
-
-RDSInstanceStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## ScalingConfiguration
-
-ScalingConfiguration contains the scaling configuration of an Aurora Serverless DB cluster. For more information, see Using Amazon Aurora Serverless (http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.html) in the Amazon Aurora User Guide. Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/ScalingConfiguration
-
-Appears in:
-
-* [RDSInstanceParameters](#RDSInstanceParameters)
-
-
-Name | Type | Description
------|------|------------
-`autoPause` | Optional bool | AutoPause specifies whether to allow or disallow automatic pause for an Aurora DB cluster in serverless DB engine mode. A DB cluster can be paused only when it's idle (it has no connections). If a DB cluster is paused for more than seven days, the DB cluster might be backed up with a snapshot. In this case, the DB cluster is restored when there is a request to connect to it.
-`maxCapacity` | Optional int | MaxCapacity is the maximum capacity for an Aurora DB cluster in serverless DB engine mode. Valid capacity values are 2, 4, 8, 16, 32, 64, 128, and 256. The maximum capacity must be greater than or equal to the minimum capacity.
-`minCapacity` | Optional int | MinCapacity is the minimum capacity for an Aurora DB cluster in serverless DB engine mode. Valid capacity values are 2, 4, 8, 16, 32, 64, 128, and 256. The minimum capacity must be less than or equal to the maximum capacity.
-`secondsUntilAutoPause` | Optional int | SecondsUntilAutoPause is the time, in seconds, before an Aurora DB cluster in serverless mode is paused.
-
-
-
-## SubnetInRDS
-
-SubnetInRDS is used as a response element in the DescribeDBSubnetGroups action. Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/Subnet
-
-Appears in:
-
-* [DBSubnetGroupInRDS](#DBSubnetGroupInRDS)
-
-
-Name | Type | Description
------|------|------------
-`subnetAvailabilityZone` | [AvailabilityZone](#AvailabilityZone) | SubnetAvailabilityZone contains Availability Zone information. This data type is used as an element in the following data type: * OrderableDBInstanceOption
-`subnetIdentifier` | string | SubnetIdentifier specifies the identifier of the subnet.
-`subnetStatus` | string | SubnetStatus specifies the status of the subnet.
-
-
-
-## Tag
-
-Tag is a metadata assigned to an Amazon RDS resource consisting of a key-value pair. Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/Tag
-
-Appears in:
-
-* [RDSInstanceParameters](#RDSInstanceParameters)
-
-
-Name | Type | Description
------|------|------------
-`key` | string | A key is the required name of the tag. The string value can be from 1 to 128 Unicode characters in length and can't be prefixed with "aws:" or "rds:". The string can only contain only the set of Unicode letters, digits, white-space, '_', '.', '/', '=', '+', '-' (Java regex: "^([\\p{L}\\p{Z}\\p{N}_.:/=+\\-]*)$").
-`value` | string | A value is the optional value of the tag. The string value can be from 1 to 256 Unicode characters in length and can't be prefixed with "aws:" or "rds:". The string can only contain only the set of Unicode letters, digits, white-space, '_', '.', '/', '=', '+', '-' (Java regex: "^([\\p{L}\\p{Z}\\p{N}_.:/=+\\-]*)$").
-
-
-
-## VPCSecurityGroupIDReferencerForRDSInstance
-
-VPCSecurityGroupIDReferencerForRDSInstance is an attribute referencer that resolves SecurityGroupID from a referenced SecurityGroup
-
-
-
-
-VPCSecurityGroupIDReferencerForRDSInstance supports all fields of:
-
-* github.com/crossplaneio/stack-aws/apis/network/v1alpha3.SecurityGroupIDReferencer
-
-
-## VPCSecurityGroupMembership
-
-VPCSecurityGroupMembership is used as a response element for queries on VPC security group membership. Please also see https://docs.aws.amazon.com/goto/WebAPI/rds-2014-10-31/VpcSecurityGroupMembership
-
-Appears in:
-
-* [RDSInstanceObservation](#RDSInstanceObservation)
-
-
-Name | Type | Description
------|------|------------
-`status` | string | Status is the status of the VPC security group.
-`vpcSecurityGroupId` | string | VPCSecurityGroupID is the name of the VPC security group.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-aws/identity-aws-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-aws/identity-aws-crossplane-io-v1alpha3.md
deleted file mode 100644
index 29c3f07b..00000000
--- a/docs/v0.4/api/crossplaneio/stack-aws/identity-aws-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,217 +0,0 @@
-# identity.aws.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains managed resources for AWS identity services such as IAM.
-
-This API group contains the following Crossplane resources:
-
-* [IAMRole](#IAMRole)
-* [IAMRolePolicyAttachment](#IAMRolePolicyAttachment)
-
-## IAMRole
-
-An IAMRole is a managed resource that represents an AWS IAM Role.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `identity.aws.crossplane.io/v1alpha3`
-`kind` | string | `IAMRole`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [IAMRoleSpec](#IAMRoleSpec) | An IAMRoleSpec defines the desired state of an IAMRole.
-`status` | [IAMRoleStatus](#IAMRoleStatus) | An IAMRoleStatus represents the observed state of an IAMRole.
-
-
-
-## IAMRolePolicyAttachment
-
-An IAMRolePolicyAttachment is a managed resource that represents an AWS IAM Role policy attachment.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `identity.aws.crossplane.io/v1alpha3`
-`kind` | string | `IAMRolePolicyAttachment`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [IAMRolePolicyAttachmentSpec](#IAMRolePolicyAttachmentSpec) | An IAMRolePolicyAttachmentSpec defines the desired state of an IAMRolePolicyAttachment.
-`status` | [IAMRolePolicyAttachmentStatus](#IAMRolePolicyAttachmentStatus) | An IAMRolePolicyAttachmentStatus represents the observed state of an IAMRolePolicyAttachment.
-
-
-
-## IAMRoleARNReferencer
-
-IAMRoleARNReferencer is used to get the ARN from a referenced IAMRole object
-
-
-
-
-IAMRoleARNReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## IAMRoleExternalStatus
-
-IAMRoleExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [IAMRoleStatus](#IAMRoleStatus)
-
-
-Name | Type | Description
------|------|------------
-`arn` | string | ARN is the Amazon Resource Name (ARN) specifying the role. For more information about ARNs and how to use them in policies, see IAM Identifiers (http://docs.aws.amazon.com/IAM/latest/UserGuide/Using_Identifiers.html) in the IAM User Guide guide.
-`roleID` | string | RoleID is the stable and unique string identifying the role. For more information about IDs, see IAM Identifiers (http://docs.aws.amazon.com/IAM/latest/UserGuide/Using_Identifiers.html) in the Using IAM guide.
-
-
-
-## IAMRoleNameReferencer
-
-IAMRoleNameReferencer is used to get the Name from a referenced IAMRole object
-
-Appears in:
-
-* [IAMRoleNameReferencerForIAMRolePolicyAttachment](#IAMRoleNameReferencerForIAMRolePolicyAttachment)
-
-
-
-
-IAMRoleNameReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## IAMRoleNameReferencerForIAMRolePolicyAttachment
-
-IAMRoleNameReferencerForIAMRolePolicyAttachment is an attribute referencer that retrieves Name from a referenced IAMRole
-
-Appears in:
-
-* [IAMRolePolicyAttachmentParameters](#IAMRolePolicyAttachmentParameters)
-
-
-
-
-IAMRoleNameReferencerForIAMRolePolicyAttachment supports all fields of:
-
-* [IAMRoleNameReferencer](#IAMRoleNameReferencer)
-
-
-## IAMRoleParameters
-
-IAMRoleParameters define the desired state of an AWS IAM Role.
-
-Appears in:
-
-* [IAMRoleSpec](#IAMRoleSpec)
-
-
-Name | Type | Description
------|------|------------
-`assumeRolePolicyDocument` | string | AssumeRolePolicyDocument is the the trust relationship policy document that grants an entity permission to assume the role.
-`description` | Optional string | Description is a description of the role.
-`roleName` | string | RoleName presents the name of the IAM role.
-
-
-
-## IAMRolePolicyAttachmentExternalStatus
-
-IAMRolePolicyAttachmentExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [IAMRolePolicyAttachmentStatus](#IAMRolePolicyAttachmentStatus)
-
-
-Name | Type | Description
------|------|------------
-`attachedPolicyArn` | string | AttachedPolicyARN is the arn for the attached policy. If nil, the policy is not yet attached
-
-
-
-## IAMRolePolicyAttachmentParameters
-
-IAMRolePolicyAttachmentParameters define the desired state of an AWS IAM Role policy attachment.
-
-Appears in:
-
-* [IAMRolePolicyAttachmentSpec](#IAMRolePolicyAttachmentSpec)
-
-
-Name | Type | Description
------|------|------------
-`policyArn` | string | PolicyARN is the Amazon Resource Name (ARN) of the IAM policy you want to attach.
-`roleName` | string | RoleName presents the name of the IAM role.
-`roleNameRef` | [IAMRoleNameReferencerForIAMRolePolicyAttachment](#IAMRoleNameReferencerForIAMRolePolicyAttachment) | RoleNameRef references to an IAMRole to retrieve its Name
-
-
-
-## IAMRolePolicyAttachmentSpec
-
-An IAMRolePolicyAttachmentSpec defines the desired state of an IAMRolePolicyAttachment.
-
-Appears in:
-
-* [IAMRolePolicyAttachment](#IAMRolePolicyAttachment)
-
-
-
-
-IAMRolePolicyAttachmentSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [IAMRolePolicyAttachmentParameters](#IAMRolePolicyAttachmentParameters)
-
-
-## IAMRolePolicyAttachmentStatus
-
-An IAMRolePolicyAttachmentStatus represents the observed state of an IAMRolePolicyAttachment.
-
-Appears in:
-
-* [IAMRolePolicyAttachment](#IAMRolePolicyAttachment)
-
-
-
-
-IAMRolePolicyAttachmentStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [IAMRolePolicyAttachmentExternalStatus](#IAMRolePolicyAttachmentExternalStatus)
-
-
-## IAMRoleSpec
-
-An IAMRoleSpec defines the desired state of an IAMRole.
-
-Appears in:
-
-* [IAMRole](#IAMRole)
-
-
-
-
-IAMRoleSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [IAMRoleParameters](#IAMRoleParameters)
-
-
-## IAMRoleStatus
-
-An IAMRoleStatus represents the observed state of an IAMRole.
-
-Appears in:
-
-* [IAMRole](#IAMRole)
-
-
-
-
-IAMRoleStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [IAMRoleExternalStatus](#IAMRoleExternalStatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-aws/network-aws-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-aws/network-aws-crossplane-io-v1alpha3.md
deleted file mode 100644
index 046e5686..00000000
--- a/docs/v0.4/api/crossplaneio/stack-aws/network-aws-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,733 +0,0 @@
-# network.aws.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains managed resources for AWS network services such as VPC and Subnet.
-
-This API group contains the following Crossplane resources:
-
-* [InternetGateway](#InternetGateway)
-* [RouteTable](#RouteTable)
-* [SecurityGroup](#SecurityGroup)
-* [Subnet](#Subnet)
-* [VPC](#VPC)
-
-## InternetGateway
-
-An InternetGateway is a managed resource that represents an AWS VPC Internet Gateway.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `network.aws.crossplane.io/v1alpha3`
-`kind` | string | `InternetGateway`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [InternetGatewaySpec](#InternetGatewaySpec) | An InternetGatewaySpec defines the desired state of an InternetGateway.
-`status` | [InternetGatewayStatus](#InternetGatewayStatus) | An InternetGatewayStatus represents the observed state of an InternetGateway.
-
-
-
-## RouteTable
-
-A RouteTable is a managed resource that represents an AWS VPC Route Table.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `network.aws.crossplane.io/v1alpha3`
-`kind` | string | `RouteTable`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [RouteTableSpec](#RouteTableSpec) | A RouteTableSpec defines the desired state of a RouteTable.
-`status` | [RouteTableStatus](#RouteTableStatus) | A RouteTableStatus represents the observed state of a RouteTable.
-
-
-
-## SecurityGroup
-
-A SecurityGroup is a managed resource that represents an AWS VPC Security Group.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `network.aws.crossplane.io/v1alpha3`
-`kind` | string | `SecurityGroup`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [SecurityGroupSpec](#SecurityGroupSpec) | A SecurityGroupSpec defines the desired state of a SecurityGroup.
-`status` | [SecurityGroupStatus](#SecurityGroupStatus) | A SecurityGroupStatus represents the observed state of a SecurityGroup.
-
-
-
-## Subnet
-
-A Subnet is a managed resource that represents an AWS VPC Subnet.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `network.aws.crossplane.io/v1alpha3`
-`kind` | string | `Subnet`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [SubnetSpec](#SubnetSpec) | A SubnetSpec defines the desired state of a Subnet.
-`status` | [SubnetStatus](#SubnetStatus) | A SubnetStatus represents the observed state of a Subnet.
-
-
-
-## VPC
-
-A VPC is a managed resource that represents an AWS Virtual Private Cloud.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `network.aws.crossplane.io/v1alpha3`
-`kind` | string | `VPC`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [VPCSpec](#VPCSpec) | A VPCSpec defines the desired state of a VPC.
-`status` | [VPCStatus](#VPCStatus) | A VPCStatus represents the observed state of a VPC.
-
-
-
-## Association
-
-Association describes an association between a route table and a subnet.
-
-Appears in:
-
-* [AssociationState](#AssociationState)
-* [RouteTableParameters](#RouteTableParameters)
-
-
-Name | Type | Description
------|------|------------
-`subnetId` | string | The ID of the subnet. A subnet ID is not returned for an implicit association.
-`subnetIdRef` | [SubnetIDReferencerForRouteTable](#SubnetIDReferencerForRouteTable) | A referencer to retrieve the ID of a subnet
-
-
-
-## AssociationState
-
-AssociationState describes an association state in the route table.
-
-Appears in:
-
-* [RouteTableExternalStatus](#RouteTableExternalStatus)
-
-
-Name | Type | Description
------|------|------------
-`main` | bool | Indicates whether this is the main route table.
-`associationId` | string | The ID of the association between a route table and a subnet.
-
-
-AssociationState supports all fields of:
-
-* [Association](#Association)
-
-
-## IPPermission
-
-IPPermission Describes a set of permissions for a security group rule.
-
-Appears in:
-
-* [SecurityGroupParameters](#SecurityGroupParameters)
-
-
-Name | Type | Description
------|------|------------
-`fromPort` | int64 | The start of port range for the TCP and UDP protocols, or an ICMP/ICMPv6 type number. A value of -1 indicates all ICMP/ICMPv6 types. If you specify all ICMP/ICMPv6 types, you must specify all codes.
-`toPort` | int64 | The end of port range for the TCP and UDP protocols, or an ICMP/ICMPv6 code. A value of -1 indicates all ICMP/ICMPv6 codes for the specified ICMP type. If you specify all ICMP/ICMPv6 types, you must specify all codes.
-`protocol` | string | The IP protocol name (tcp, udp, icmp) or number (see Protocol Numbers (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml)). [EC2-VPC only] Use -1 to specify all protocols. When authorizing security group rules, specifying -1 or a protocol number other than tcp, udp, icmp, or 58 (ICMPv6) allows traffic on all ports, regardless of any port range you specify. For tcp, udp, and icmp, you must specify a port range. For 58 (ICMPv6), you can optionally specify a port range; if you don't, traffic for all types and codes is allowed when authorizing rules.
-`cidrBlocks` | [[]IPRange](#IPRange) | One or more IPv4 ranges.
-
-
-
-## IPRange
-
-IPRange describes an IPv4 range.
-
-Appears in:
-
-* [IPPermission](#IPPermission)
-
-
-Name | Type | Description
------|------|------------
-`cidrIp` | string | The IPv4 CIDR range. You can either specify a CIDR range or a source security group, not both. To specify a single IPv4 address, use the /32 prefix length.
-`description` | string | A description for the ip range
-
-
-
-## InternetGatewayAttachment
-
-InternetGatewayAttachment describes the attachment of a VPC to an internet gateway or an egress-only internet gateway.
-
-Appears in:
-
-* [InternetGatewayExternalStatus](#InternetGatewayExternalStatus)
-
-
-Name | Type | Description
------|------|------------
-`attachmentStatus` | string | The current state of the attachment. For an internet gateway, the state is available when attached to a VPC; otherwise, this value is not returned.
-`vpcId` | string | VPCID is the ID of the attached VPC.
-
-
-
-## InternetGatewayExternalStatus
-
-InternetGatewayExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [InternetGatewayStatus](#InternetGatewayStatus)
-
-
-Name | Type | Description
------|------|------------
-`attachments` | [[]InternetGatewayAttachment](#InternetGatewayAttachment) | Any VPCs attached to the internet gateway.
-`internetGatewayId` | string | The ID of the internet gateway.
-`tags` | [[]Tag](#Tag) | Tags represents to current ec2 tags.
-
-
-
-## InternetGatewayIDReferencer
-
-InternetGatewayIDReferencer is used to get a InternetGatewayID from a InternetGateway
-
-Appears in:
-
-* [InternetGatewayIDReferencerForRouteTable](#InternetGatewayIDReferencerForRouteTable)
-
-
-
-
-InternetGatewayIDReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## InternetGatewayIDReferencerForRouteTable
-
-InternetGatewayIDReferencerForRouteTable is an attribute referencer that resolves VPCID from a referenced VPC
-
-Appears in:
-
-* [Route](#Route)
-
-
-
-
-InternetGatewayIDReferencerForRouteTable supports all fields of:
-
-* [InternetGatewayIDReferencer](#InternetGatewayIDReferencer)
-
-
-## InternetGatewayParameters
-
-InternetGatewayParameters define the desired state of an AWS VPC Internet Gateway.
-
-Appears in:
-
-* [InternetGatewaySpec](#InternetGatewaySpec)
-
-
-Name | Type | Description
------|------|------------
-`vpcId` | string | VPCID is the ID of the VPC.
-`vpcIdRef` | [VPCIDReferencerForInternetGateway](#VPCIDReferencerForInternetGateway) | VPCIDRef references to a VPC to and retrieves its vpcId
-
-
-
-## InternetGatewaySpec
-
-An InternetGatewaySpec defines the desired state of an InternetGateway.
-
-Appears in:
-
-* [InternetGateway](#InternetGateway)
-
-
-
-
-InternetGatewaySpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [InternetGatewayParameters](#InternetGatewayParameters)
-
-
-## InternetGatewayStatus
-
-An InternetGatewayStatus represents the observed state of an InternetGateway.
-
-Appears in:
-
-* [InternetGateway](#InternetGateway)
-
-
-
-
-InternetGatewayStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [InternetGatewayExternalStatus](#InternetGatewayExternalStatus)
-
-
-## Route
-
-Route describes a route in a route table.
-
-Appears in:
-
-* [RouteState](#RouteState)
-* [RouteTableParameters](#RouteTableParameters)
-
-
-Name | Type | Description
------|------|------------
-`destinationCidrBlock` | string | The IPv4 CIDR address block used for the destination match. Routing decisions are based on the most specific match.
-`gatewayId` | string | The ID of an internet gateway or virtual private gateway attached to your VPC.
-`gatewayIdRef` | [InternetGatewayIDReferencerForRouteTable](#InternetGatewayIDReferencerForRouteTable) | A referencer to retrieve the ID of a gateway
-
-
-
-## RouteState
-
-RouteState describes a route state in the route table.
-
-Appears in:
-
-* [RouteTableExternalStatus](#RouteTableExternalStatus)
-
-
-Name | Type | Description
------|------|------------
-`routeState` | string | The state of the route. The blackhole state indicates that the route's target isn't available (for example, the specified gateway isn't attached to the VPC, or the specified NAT instance has been terminated).
-
-
-RouteState supports all fields of:
-
-* [Route](#Route)
-
-
-## RouteTableExternalStatus
-
-RouteTableExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [RouteTableStatus](#RouteTableStatus)
-
-
-Name | Type | Description
------|------|------------
-`routeTableId` | string | RouteTableID is the ID of the RouteTable.
-`routes` | [[]RouteState](#RouteState) | The actual routes created for the route table.
-`associations` | [[]AssociationState](#AssociationState) | The actual associations created for the route table.
-
-
-
-## RouteTableParameters
-
-RouteTableParameters define the desired state of an AWS VPC Route Table.
-
-Appears in:
-
-* [RouteTableSpec](#RouteTableSpec)
-
-
-Name | Type | Description
------|------|------------
-`vpcId` | string | VPCID is the ID of the VPC.
-`vpcIdRef` | [VPCIDReferencerForRouteTable](#VPCIDReferencerForRouteTable) | VPCIDRef references to a VPC to and retrieves its vpcId
-`routes` | [[]Route](#Route) | the routes in the route table
-`associations` | [[]Association](#Association) | The associations between the route table and one or more subnets.
-
-
-
-## RouteTableSpec
-
-A RouteTableSpec defines the desired state of a RouteTable.
-
-Appears in:
-
-* [RouteTable](#RouteTable)
-
-
-
-
-RouteTableSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [RouteTableParameters](#RouteTableParameters)
-
-
-## RouteTableStatus
-
-A RouteTableStatus represents the observed state of a RouteTable.
-
-Appears in:
-
-* [RouteTable](#RouteTable)
-
-
-
-
-RouteTableStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [RouteTableExternalStatus](#RouteTableExternalStatus)
-
-
-## SecurityGroupExternalStatus
-
-SecurityGroupExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [SecurityGroupStatus](#SecurityGroupStatus)
-
-
-Name | Type | Description
------|------|------------
-`securityGroupID` | string | SecurityGroupID is the ID of the SecurityGroup.
-`tags` | [[]Tag](#Tag) | Tags represents to current ec2 tags.
-
-
-
-## SecurityGroupIDReferencer
-
-SecurityGroupIDReferencer is used to get the ID from another SecurityGroup
-
-
-
-
-SecurityGroupIDReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## SecurityGroupParameters
-
-SecurityGroupParameters define the desired state of an AWS VPC Security Group.
-
-Appears in:
-
-* [SecurityGroupSpec](#SecurityGroupSpec)
-
-
-Name | Type | Description
------|------|------------
-`vpcId` | string | VPCID is the ID of the VPC.
-`vpcIdRef` | [VPCIDReferencerForSecurityGroup](#VPCIDReferencerForSecurityGroup) | VPCIDRef references to a VPC to and retrieves its vpcId
-`description` | string | A description of the security group.
-`groupName` | string | The name of the security group.
-`ingress` | [[]IPPermission](#IPPermission) | One or more inbound rules associated with the security group.
-`egress` | [[]IPPermission](#IPPermission) | [EC2-VPC] One or more outbound rules associated with the security group.
-
-
-
-## SecurityGroupSpec
-
-A SecurityGroupSpec defines the desired state of a SecurityGroup.
-
-Appears in:
-
-* [SecurityGroup](#SecurityGroup)
-
-
-
-
-SecurityGroupSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [SecurityGroupParameters](#SecurityGroupParameters)
-
-
-## SecurityGroupStatus
-
-A SecurityGroupStatus represents the observed state of a SecurityGroup.
-
-Appears in:
-
-* [SecurityGroup](#SecurityGroup)
-
-
-
-
-SecurityGroupStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [SecurityGroupExternalStatus](#SecurityGroupExternalStatus)
-
-
-## SubnetExternalStatus
-
-SubnetExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [SubnetStatus](#SubnetStatus)
-
-
-Name | Type | Description
------|------|------------
-`subnetState` | string | SubnetState is the current state of the Subnet.
-`tags` | [[]Tag](#Tag) | Tags represents to current ec2 tags.
-`subnetId` | string | SubnetID is the ID of the Subnet.
-
-
-
-## SubnetIDReferencer
-
-SubnetIDReferencer is used to get a SubnetID from another Subnet
-
-Appears in:
-
-* [SubnetIDReferencerForRouteTable](#SubnetIDReferencerForRouteTable)
-
-
-
-
-SubnetIDReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## SubnetIDReferencerForRouteTable
-
-SubnetIDReferencerForRouteTable is an attribute referencer that resolves SubnetID from a referenced Subnet
-
-Appears in:
-
-* [Association](#Association)
-
-
-
-
-SubnetIDReferencerForRouteTable supports all fields of:
-
-* [SubnetIDReferencer](#SubnetIDReferencer)
-
-
-## SubnetParameters
-
-SubnetParameters define the desired state of an AWS VPC Subnet.
-
-Appears in:
-
-* [SubnetSpec](#SubnetSpec)
-
-
-Name | Type | Description
------|------|------------
-`cidrBlock` | string | CIDRBlock is the IPv4 network range for the Subnet, in CIDR notation. For example, 10.0.0.0/18.
-`availabilityZone` | string | The Availability Zone for the subnet. Default: AWS selects one for you. If you create more than one subnet in your VPC, we may not necessarily select a different zone for each subnet.
-`vpcId` | string | VPCID is the ID of the VPC.
-`vpcIdRef` | [VPCIDReferencerForSubnet](#VPCIDReferencerForSubnet) | VPCIDRef references to a VPC to and retrieves its vpcId
-
-
-
-## SubnetSpec
-
-A SubnetSpec defines the desired state of a Subnet.
-
-Appears in:
-
-* [Subnet](#Subnet)
-
-
-
-
-SubnetSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [SubnetParameters](#SubnetParameters)
-
-
-## SubnetStatus
-
-A SubnetStatus represents the observed state of a Subnet.
-
-Appears in:
-
-* [Subnet](#Subnet)
-
-
-
-
-SubnetStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [SubnetExternalStatus](#SubnetExternalStatus)
-
-
-## Tag
-
-Tag defines a tag
-
-Appears in:
-
-* [InternetGatewayExternalStatus](#InternetGatewayExternalStatus)
-* [SecurityGroupExternalStatus](#SecurityGroupExternalStatus)
-* [SubnetExternalStatus](#SubnetExternalStatus)
-* [VPCExternalStatus](#VPCExternalStatus)
-
-
-Name | Type | Description
------|------|------------
-`key` | string | Key is the name of the tag.
-`value` | string | Value is the value of the tag.
-
-
-
-## VPCExternalStatus
-
-VPCExternalStatus keeps the state for the external resource
-
-Appears in:
-
-* [VPCStatus](#VPCStatus)
-
-
-Name | Type | Description
------|------|------------
-`vpcState` | string | VPCState is the current state of the VPC.
-`tags` | [[]Tag](#Tag) | Tags represents to current ec2 tags.
-`vpcId` | string | VPCID is the ID of the VPC.
-
-
-
-## VPCIDReferencer
-
-VPCIDReferencer is used to get a VPCID from another VPC
-
-Appears in:
-
-* [VPCIDReferencerForInternetGateway](#VPCIDReferencerForInternetGateway)
-* [VPCIDReferencerForRouteTable](#VPCIDReferencerForRouteTable)
-* [VPCIDReferencerForSecurityGroup](#VPCIDReferencerForSecurityGroup)
-* [VPCIDReferencerForSubnet](#VPCIDReferencerForSubnet)
-
-
-
-
-VPCIDReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## VPCIDReferencerForInternetGateway
-
-VPCIDReferencerForInternetGateway is an attribute referencer that resolves VPCID from a referenced VPC
-
-Appears in:
-
-* [InternetGatewayParameters](#InternetGatewayParameters)
-
-
-
-
-VPCIDReferencerForInternetGateway supports all fields of:
-
-* [VPCIDReferencer](#VPCIDReferencer)
-
-
-## VPCIDReferencerForRouteTable
-
-VPCIDReferencerForRouteTable is an attribute referencer that resolves VPCID from a referenced VPC
-
-Appears in:
-
-* [RouteTableParameters](#RouteTableParameters)
-
-
-
-
-VPCIDReferencerForRouteTable supports all fields of:
-
-* [VPCIDReferencer](#VPCIDReferencer)
-
-
-## VPCIDReferencerForSecurityGroup
-
-VPCIDReferencerForSecurityGroup is an attribute referencer that resolves VPCID from a referenced VPC
-
-Appears in:
-
-* [SecurityGroupParameters](#SecurityGroupParameters)
-
-
-
-
-VPCIDReferencerForSecurityGroup supports all fields of:
-
-* [VPCIDReferencer](#VPCIDReferencer)
-
-
-## VPCIDReferencerForSubnet
-
-VPCIDReferencerForSubnet is an attribute referencer that resolves VPCID from a referenced VPC
-
-Appears in:
-
-* [SubnetParameters](#SubnetParameters)
-
-
-
-
-VPCIDReferencerForSubnet supports all fields of:
-
-* [VPCIDReferencer](#VPCIDReferencer)
-
-
-## VPCParameters
-
-VPCParameters define the desired state of an AWS Virtual Private Cloud.
-
-Appears in:
-
-* [VPCSpec](#VPCSpec)
-
-
-Name | Type | Description
------|------|------------
-`cidrBlock` | string | CIDRBlock is the IPv4 network range for the VPC, in CIDR notation. For example, 10.0.0.0/16.
-`enableDnsSupport` | bool | A boolean flag to enable/disable DNS support in the VPC
-`enableDnsHostNames` | bool | A boolean flag to enable/disable DNS hostnames in the VPC
-
-
-
-## VPCSpec
-
-A VPCSpec defines the desired state of a VPC.
-
-Appears in:
-
-* [VPC](#VPC)
-
-
-
-
-VPCSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [VPCParameters](#VPCParameters)
-
-
-## VPCStatus
-
-A VPCStatus represents the observed state of a VPC.
-
-Appears in:
-
-* [VPC](#VPC)
-
-
-
-
-VPCStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [VPCExternalStatus](#VPCExternalStatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-aws/storage-aws-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-aws/storage-aws-crossplane-io-v1alpha3.md
deleted file mode 100644
index 2f2a8498..00000000
--- a/docs/v0.4/api/crossplaneio/stack-aws/storage-aws-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,115 +0,0 @@
-# storage.aws.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains managed resources for AWS storage services such as S3.
-
-This API group contains the following Crossplane resources:
-
-* [S3Bucket](#S3Bucket)
-* [S3BucketClass](#S3BucketClass)
-
-## S3Bucket
-
-An S3Bucket is a managed resource that represents an AWS S3 Bucket.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.aws.crossplane.io/v1alpha3`
-`kind` | string | `S3Bucket`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [S3BucketSpec](#S3BucketSpec) | S3BucketSpec defines the desired state of S3Bucket
-`status` | [S3BucketStatus](#S3BucketStatus) | S3BucketStatus defines the observed state of S3Bucket
-
-
-
-## S3BucketClass
-
-An S3BucketClass is a resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.aws.crossplane.io/v1alpha3`
-`kind` | string | `S3BucketClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [S3BucketClassSpecTemplate](#S3BucketClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned S3Bucket.
-
-
-
-## S3BucketClassSpecTemplate
-
-An S3BucketClassSpecTemplate is a template for the spec of a dynamically provisioned S3Bucket.
-
-Appears in:
-
-* [S3BucketClass](#S3BucketClass)
-
-
-
-
-S3BucketClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-* [S3BucketParameters](#S3BucketParameters)
-
-
-## S3BucketParameters
-
-S3BucketParameters define the desired state of an AWS S3 Bucket.
-
-Appears in:
-
-* [S3BucketClassSpecTemplate](#S3BucketClassSpecTemplate)
-* [S3BucketSpec](#S3BucketSpec)
-
-
-Name | Type | Description
------|------|------------
-`nameFormat` | Optional string | NameFormat specifies the name of the external S3Bucket instance. The first instance of the string '%s' will be replaced with the Kubernetes UID of this S3Bucket. Omit this field to use the UID alone as the name.
-`region` | string | Region of the bucket.
-`cannedACL` | Optional [s3.BucketCannedACL](https://godoc.org/github.com/aws/aws-sdk-go-v2/service/s3#BucketCannedACL) | CannedACL applies a standard AWS built-in ACL for common bucket use cases.
-`versioning` | Optional bool | Versioning enables versioning of objects stored in this bucket.
-`localPermission` | [storage/v1alpha1.LocalPermissionType](../crossplane/storage-crossplane-io-v1alpha1.md#localpermissiontype) | LocalPermission is the permissions granted on the bucket for the provider specific bucket service account that is available in a secret after provisioning.
-
-
-
-## S3BucketSpec
-
-S3BucketSpec defines the desired state of S3Bucket
-
-Appears in:
-
-* [S3Bucket](#S3Bucket)
-
-
-
-
-S3BucketSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [S3BucketParameters](#S3BucketParameters)
-
-
-## S3BucketStatus
-
-S3BucketStatus defines the observed state of S3Bucket
-
-Appears in:
-
-* [S3Bucket](#S3Bucket)
-
-
-Name | Type | Description
------|------|------------
-`providerID` | string | ProviderID is the AWS identifier for this bucket.
-`iamUsername` | string | IAMUsername is the name of an IAM user that is automatically created and granted access to this bucket by Crossplane at bucket creation time.
-`lastUserPolicyVersion` | int | LastUserPolicyVersion is the most recent version of the policy associated with this bucket's IAMUser.
-`lastLocalPermission` | [storage/v1alpha1.LocalPermissionType](../crossplane/storage-crossplane-io-v1alpha1.md#localpermissiontype) | LastLocalPermission is the most recent local permission that was set for this bucket.
-
-
-S3BucketStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-azure/azure-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-azure/azure-crossplane-io-v1alpha3.md
deleted file mode 100644
index 5fcb5fe8..00000000
--- a/docs/v0.4/api/crossplaneio/stack-azure/azure-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,105 +0,0 @@
-# azure.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains core resources for Microsoft Azure.
-
-This API group contains the following Crossplane resources:
-
-* [Provider](#Provider)
-* [ResourceGroup](#ResourceGroup)
-
-## Provider
-
-A Provider configures an Azure 'provider', i.e. a connection to a particular Azure account using a particular Azure Service Principal.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `azure.crossplane.io/v1alpha3`
-`kind` | string | `Provider`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ProviderSpec](#ProviderSpec) | A ProviderSpec defines the desired state of a Provider.
-
-
-
-## ResourceGroup
-
-A ResourceGroup is a managed resource that represents an Azure Resource Group.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `azure.crossplane.io/v1alpha3`
-`kind` | string | `ResourceGroup`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ResourceGroupSpec](#ResourceGroupSpec) | A ResourceGroupSpec defines the desired state of a ResourceGroup.
-`status` | [ResourceGroupStatus](#ResourceGroupStatus) | A ResourceGroupStatus represents the observed status of a ResourceGroup.
-
-
-
-## ProviderSpec
-
-A ProviderSpec defines the desired state of a Provider.
-
-Appears in:
-
-* [Provider](#Provider)
-
-
-Name | Type | Description
------|------|------------
-`credentialsSecretRef` | [v1alpha1.SecretKeySelector](../crossplane-runtime/core-crossplane-io-v1alpha1.md#secretkeyselector) | Azure service principal credentials json secret key reference A Secret containing JSON encoded credentials for an Azure Service Principal that will be used to authenticate to this Azure Provider.
-
-
-
-## ResourceGroupNameReferencer
-
-ResourceGroupNameReferencer is used to get the name from another ResourceGroup
-
-
-
-
-ResourceGroupNameReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## ResourceGroupSpec
-
-A ResourceGroupSpec defines the desired state of a ResourceGroup.
-
-Appears in:
-
-* [ResourceGroup](#ResourceGroup)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name of the resource group.
-`location` | string | Location of the resource group. See the official list of valid regions - https://azure.microsoft.com/en-us/global-infrastructure/regions/
-
-
-ResourceGroupSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## ResourceGroupStatus
-
-A ResourceGroupStatus represents the observed status of a ResourceGroup.
-
-Appears in:
-
-* [ResourceGroup](#ResourceGroup)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name of the resource group.
-
-
-ResourceGroupStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-azure/cache-azure-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-azure/cache-azure-crossplane-io-v1alpha3.md
deleted file mode 100644
index de965f35..00000000
--- a/docs/v0.4/api/crossplaneio/stack-azure/cache-azure-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,138 +0,0 @@
-# cache.azure.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains managed resources for Azure cache services such as Redis.
-
-This API group contains the following Crossplane resources:
-
-* [Redis](#Redis)
-* [RedisClass](#RedisClass)
-
-## Redis
-
-A Redis is a managed resource that represents an Azure Redis cluster.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.azure.crossplane.io/v1alpha3`
-`kind` | string | `Redis`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [RedisSpec](#RedisSpec) | A RedisSpec defines the desired state of a Redis.
-`status` | [RedisStatus](#RedisStatus) | A RedisStatus represents the observed state of a Redis.
-
-
-
-## RedisClass
-
-A RedisClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.azure.crossplane.io/v1alpha3`
-`kind` | string | `RedisClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [RedisClassSpecTemplate](#RedisClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned Redis.
-
-
-
-## RedisClassSpecTemplate
-
-A RedisClassSpecTemplate is a template for the spec of a dynamically provisioned Redis.
-
-Appears in:
-
-* [RedisClass](#RedisClass)
-
-
-
-
-RedisClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-* [RedisParameters](#RedisParameters)
-
-
-## RedisParameters
-
-RedisParameters define the desired state of an Azure Redis cluster. Most fields map directly to an Azure Redis resource: https://docs.microsoft.com/en-us/rest/api/redis/redis/create#redisresource
-
-Appears in:
-
-* [RedisClassSpecTemplate](#RedisClassSpecTemplate)
-* [RedisSpec](#RedisSpec)
-
-
-Name | Type | Description
------|------|------------
-`resourceGroupName` | string | ResourceGroupName in which to create this resource.
-`location` | string | Location in which to create this resource.
-`sku` | [SKUSpec](#SKUSpec) | SKU of the Redis cache to deploy.
-`enableNonSslPort` | Optional bool | EnableNonSSLPort specifies whether the non-ssl Redis server port (6379) is enabled.
-`shardCount` | Optional int | ShardCount specifies the number of shards to be created on a Premium Cluster Cache.
-`staticIP` | Optional string | StaticIP address. Required when deploying a Redis cache inside an existing Azure Virtual Network.
-`subnetId` | Optional string | SubnetID specifies the full resource ID of a subnet in a virtual network to deploy the Redis cache in. Example format: /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/Microsoft.{Network|ClassicNetwork}/VirtualNetworks/vnet1/subnets/subnet1
-`redisConfiguration` | Optional map[string]string | RedisConfiguration specifies Redis Settings.
-
-
-
-## RedisSpec
-
-A RedisSpec defines the desired state of a Redis.
-
-Appears in:
-
-* [Redis](#Redis)
-
-
-
-
-RedisSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [RedisParameters](#RedisParameters)
-
-
-## RedisStatus
-
-A RedisStatus represents the observed state of a Redis.
-
-Appears in:
-
-* [Redis](#Redis)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State represents the state of an Azure Redis.
-`providerID` | string | ProviderID is the external ID to identify this resource in the cloud provider.
-`endpoint` | string | Endpoint of the Redis resource used in connection strings.
-`port` | int | Port at which the Redis endpoint is listening.
-`sslPort` | int | SSLPort at which the Redis endpoint is listening.
-`redisVersion` | string | RedisVersion the Redis endpoint is running.
-`resourceName` | string | ResourceName of the Redis cache resource.
-
-
-RedisStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## SKUSpec
-
-An SKUSpec represents the performance and cost oriented properties of a Redis.
-
-Appears in:
-
-* [RedisParameters](#RedisParameters)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name specifies what type of Redis cache to deploy. Valid values: (Basic, Standard, Premium). Possible values include: 'Basic', 'Standard', 'Premium'
-`family` | string | Family specifies which family to use. Valid values: (C, P). Possible values include: 'C', 'P'
-`capacity` | int | Capacity specifies the size of Redis cache to deploy. Valid values: for C family (0, 1, 2, 3, 4, 5, 6), for P family (1, 2, 3, 4).
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-azure/compute-azure-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-azure/compute-azure-crossplane-io-v1alpha3.md
deleted file mode 100644
index 9fefff17..00000000
--- a/docs/v0.4/api/crossplaneio/stack-azure/compute-azure-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,156 +0,0 @@
-# compute.azure.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains managed resources for Azure compute services such as AKS.
-
-This API group contains the following Crossplane resources:
-
-* [AKSCluster](#AKSCluster)
-* [AKSClusterClass](#AKSClusterClass)
-
-## AKSCluster
-
-An AKSCluster is a managed resource that represents an Azure Kubernetes Engine cluster.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.azure.crossplane.io/v1alpha3`
-`kind` | string | `AKSCluster`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [AKSClusterSpec](#AKSClusterSpec) | An AKSClusterSpec defines the desired state of a AKSCluster.
-`status` | [AKSClusterStatus](#AKSClusterStatus) | An AKSClusterStatus represents the observed state of an AKSCluster.
-
-
-
-## AKSClusterClass
-
-An AKSClusterClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.azure.crossplane.io/v1alpha3`
-`kind` | string | `AKSClusterClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [AKSClusterClassSpecTemplate](#AKSClusterClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned AKSCluster.
-
-
-
-## AKSClusterClassSpecTemplate
-
-An AKSClusterClassSpecTemplate is a template for the spec of a dynamically provisioned AKSCluster.
-
-Appears in:
-
-* [AKSClusterClass](#AKSClusterClass)
-
-
-
-
-AKSClusterClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-* [AKSClusterParameters](#AKSClusterParameters)
-
-
-## AKSClusterParameters
-
-AKSClusterParameters define the desired state of an Azure Kubernetes Engine cluster.
-
-Appears in:
-
-* [AKSClusterClassSpecTemplate](#AKSClusterClassSpecTemplate)
-* [AKSClusterSpec](#AKSClusterSpec)
-
-
-Name | Type | Description
------|------|------------
-`resourceGroupName` | string | ResourceGroupName is the name of the resource group that the cluster will be created in
-`resourceGroupNameRef` | [ResourceGroupNameReferencerForAKSCluster](#ResourceGroupNameReferencerForAKSCluster) | ResourceGroupNameRef - A reference to a ResourceGroup object to retrieve its name
-`location` | string | Location is the Azure location that the cluster will be created in
-`version` | string | Version is the Kubernetes version that will be deployed to the cluster
-`vnetSubnetID` | Optional string | VnetSubnetID is the subnet to which the cluster will be deployed.
-`vnetSubnetIDRef` | [SubnetIDReferencerForAKSCluster](#SubnetIDReferencerForAKSCluster) | ResourceGroupNameRef - A reference to a VnetSubnet object to retrieve its ID
-`nodeCount` | Optional int | NodeCount is the number of nodes that the cluster will initially be created with. This can be scaled over time and defaults to 1.
-`nodeVMSize` | Optional string | NodeVMSize is the name of the worker node VM size, e.g., Standard_B2s, Standard_F2s_v2, etc.
-`dnsNamePrefix` | Optional string | DNSNamePrefix is the DNS name prefix to use with the hosted Kubernetes API server FQDN. You will use this to connect to the Kubernetes API when managing containers after creating the cluster.
-`disableRBAC` | Optional bool | DisableRBAC determines whether RBAC will be disabled or enabled in the cluster.
-`writeServicePrincipalTo` | [v1alpha1.SecretReference](../crossplane-runtime/core-crossplane-io-v1alpha1.md#secretreference) | WriteServicePrincipalSecretTo the specified Secret. The service principal is automatically generated and used by the AKS cluster to interact with other Azure resources.
-
-
-
-## AKSClusterSpec
-
-An AKSClusterSpec defines the desired state of a AKSCluster.
-
-Appears in:
-
-* [AKSCluster](#AKSCluster)
-
-
-
-
-AKSClusterSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [AKSClusterParameters](#AKSClusterParameters)
-
-
-## AKSClusterStatus
-
-An AKSClusterStatus represents the observed state of an AKSCluster.
-
-Appears in:
-
-* [AKSCluster](#AKSCluster)
-
-
-Name | Type | Description
------|------|------------
-`clusterName` | string | ClusterName is the name of the cluster as registered with the cloud provider.
-`state` | string | State is the current state of the cluster.
-`providerID` | string | ProviderID is the external ID to identify this resource in the cloud provider.
-`endpoint` | string | Endpoint is the endpoint where the cluster can be reached
-`appObjectID` | string | ApplicationObjectID is the object ID of the AD application the cluster uses for Azure APIs.
-`servicePrincipalID` | string | ServicePrincipalID is the ID of the service principal the AD application uses.
-`runningOperation` | string | RunningOperation stores any current long running operation for this instance across reconciliation attempts.
-
-
-AKSClusterStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## ResourceGroupNameReferencerForAKSCluster
-
-ResourceGroupNameReferencerForAKSCluster is an attribute referencer that resolves name from a referenced ResourceGroup
-
-Appears in:
-
-* [AKSClusterParameters](#AKSClusterParameters)
-
-
-
-
-ResourceGroupNameReferencerForAKSCluster supports all fields of:
-
-* github.com/crossplaneio/stack-azure/apis/v1alpha3.ResourceGroupNameReferencer
-
-
-## SubnetIDReferencerForAKSCluster
-
-SubnetIDReferencerForAKSCluster is an attribute referencer that resolves name from a referenced ResourceGroup
-
-Appears in:
-
-* [AKSClusterParameters](#AKSClusterParameters)
-
-
-
-
-SubnetIDReferencerForAKSCluster supports all fields of:
-
-* github.com/crossplaneio/stack-azure/apis/network/v1alpha3.SubnetIDReferencer
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-azure/database-azure-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-azure/database-azure-crossplane-io-v1alpha3.md
deleted file mode 100644
index b7ddde50..00000000
--- a/docs/v0.4/api/crossplaneio/stack-azure/database-azure-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,398 +0,0 @@
-# database.azure.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains managed resources for Azure database services such as SQL server.
-
-This API group contains the following Crossplane resources:
-
-* [MySQLServer](#MySQLServer)
-* [MySQLServerVirtualNetworkRule](#MySQLServerVirtualNetworkRule)
-* [PostgreSQLServer](#PostgreSQLServer)
-* [PostgreSQLServerVirtualNetworkRule](#PostgreSQLServerVirtualNetworkRule)
-* [SQLServerClass](#SQLServerClass)
-
-## MySQLServer
-
-A MySQLServer is a managed resource that represents an Azure MySQL Database Server.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.azure.crossplane.io/v1alpha3`
-`kind` | string | `MySQLServer`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [SQLServerSpec](#SQLServerSpec) | A SQLServerSpec defines the desired state of a SQLServer.
-`status` | [SQLServerStatus](#SQLServerStatus) | A SQLServerStatus represents the observed state of a SQLServer.
-
-
-
-## MySQLServerVirtualNetworkRule
-
-A MySQLServerVirtualNetworkRule is a managed resource that represents an Azure MySQL Database virtual network rule.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.azure.crossplane.io/v1alpha3`
-`kind` | string | `MySQLServerVirtualNetworkRule`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [MySQLVirtualNetworkRuleSpec](#MySQLVirtualNetworkRuleSpec) | A MySQLVirtualNetworkRuleSpec defines the desired state of a MySQLVirtualNetworkRule.
-`status` | [VirtualNetworkRuleStatus](#VirtualNetworkRuleStatus) | A VirtualNetworkRuleStatus represents the observed state of a VirtualNetworkRule.
-
-
-
-## PostgreSQLServer
-
-A PostgreSQLServer is a managed resource that represents an Azure PostgreSQL Database Server.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.azure.crossplane.io/v1alpha3`
-`kind` | string | `PostgreSQLServer`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [SQLServerSpec](#SQLServerSpec) | A SQLServerSpec defines the desired state of a SQLServer.
-`status` | [SQLServerStatus](#SQLServerStatus) | A SQLServerStatus represents the observed state of a SQLServer.
-
-
-
-## PostgreSQLServerVirtualNetworkRule
-
-A PostgreSQLServerVirtualNetworkRule is a managed resource that represents an Azure PostgreSQL Database virtual network rule.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.azure.crossplane.io/v1alpha3`
-`kind` | string | `PostgreSQLServerVirtualNetworkRule`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [PostgreSQLVirtualNetworkRuleSpec](#PostgreSQLVirtualNetworkRuleSpec) | A PostgreSQLVirtualNetworkRuleSpec defines the desired state of a PostgreSQLVirtualNetworkRule.
-`status` | [VirtualNetworkRuleStatus](#VirtualNetworkRuleStatus) | A VirtualNetworkRuleStatus represents the observed state of a VirtualNetworkRule.
-
-
-
-## SQLServerClass
-
-A SQLServerClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.azure.crossplane.io/v1alpha3`
-`kind` | string | `SQLServerClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [SQLServerClassSpecTemplate](#SQLServerClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned SQLServer.
-
-
-
-## MySQLServerNameReferencer
-
-A MySQLServerNameReferencer returns the server name of a referenced MySQLServer.
-
-Appears in:
-
-* [MySQLVirtualNetworkRuleSpec](#MySQLVirtualNetworkRuleSpec)
-* [ServerNameReferencerForMySQLServerVirtualNetworkRule](#ServerNameReferencerForMySQLServerVirtualNetworkRule)
-
-
-
-
-MySQLServerNameReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## MySQLVirtualNetworkRuleSpec
-
-A MySQLVirtualNetworkRuleSpec defines the desired state of a MySQLVirtualNetworkRule.
-
-Appears in:
-
-* [MySQLServerVirtualNetworkRule](#MySQLServerVirtualNetworkRule)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name - Name of the Virtual Network Rule.
-`serverName` | string | ServerName - Name of the Virtual Network Rule's server.
-`serverNameRef` | [MySQLServerNameReferencer](#MySQLServerNameReferencer) | ServerNameRef - A reference to the Virtual Network Rule's MySQLServer.
-`resourceGroupName` | string | ResourceGroupName - Name of the Virtual Network Rule's resource group.
-`resourceGroupNameRef` | [ResourceGroupNameReferencerForVirtualNetworkRule](#ResourceGroupNameReferencerForVirtualNetworkRule) | ResourceGroupNameRef - A reference to a ResourceGroup object to retrieve its name
-`properties` | [VirtualNetworkRuleProperties](#VirtualNetworkRuleProperties) | VirtualNetworkRuleProperties - Resource properties.
-
-
-MySQLVirtualNetworkRuleSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## PostgreSQLServerNameReferencer
-
-A PostgreSQLServerNameReferencer returns the server name of a referenced PostgreSQLServer.
-
-Appears in:
-
-* [PostgreSQLVirtualNetworkRuleSpec](#PostgreSQLVirtualNetworkRuleSpec)
-* [ServerNameReferencerForPostgreSQLServerVirtualNetworkRule](#ServerNameReferencerForPostgreSQLServerVirtualNetworkRule)
-
-
-
-
-PostgreSQLServerNameReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## PostgreSQLVirtualNetworkRuleSpec
-
-A PostgreSQLVirtualNetworkRuleSpec defines the desired state of a PostgreSQLVirtualNetworkRule.
-
-Appears in:
-
-* [PostgreSQLServerVirtualNetworkRule](#PostgreSQLServerVirtualNetworkRule)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name - Name of the Virtual Network Rule.
-`serverName` | string | ServerName - Name of the Virtual Network Rule's PostgreSQLServer.
-`serverNameRef` | [PostgreSQLServerNameReferencer](#PostgreSQLServerNameReferencer) | ServerNameRef - A reference to the Virtual Network Rule's PostgreSQLServer.
-`resourceGroupName` | string | ResourceGroupName - Name of the Virtual Network Rule's resource group.
-`resourceGroupNameRef` | [ResourceGroupNameReferencerForVirtualNetworkRule](#ResourceGroupNameReferencerForVirtualNetworkRule) | ResourceGroupNameRef - A reference to a ResourceGroup object to retrieve its name
-`properties` | [VirtualNetworkRuleProperties](#VirtualNetworkRuleProperties) | VirtualNetworkRuleProperties - Resource properties.
-
-
-PostgreSQLVirtualNetworkRuleSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## PricingTierSpec
-
-PricingTierSpec represents the performance and cost oriented properties of a SQLServer.
-
-Appears in:
-
-* [SQLServerParameters](#SQLServerParameters)
-
-
-Name | Type | Description
------|------|------------
-`tier` | string | Tier of the particular SKU, e.g. Basic. Possible values include: 'Basic', 'GeneralPurpose', 'MemoryOptimized'
-`vcores` | int | VCores (aka Capacity) specifies how many virtual cores this SQLServer requires.
-`family` | string | Family of hardware.
-
-
-
-## ResourceGroupNameReferencerForSQLServer
-
-ResourceGroupNameReferencerForSQLServer is an attribute referencer that resolves the name of a the ResourceGroup.
-
-Appears in:
-
-* [SQLServerParameters](#SQLServerParameters)
-
-
-
-
-ResourceGroupNameReferencerForSQLServer supports all fields of:
-
-* github.com/crossplaneio/stack-azure/apis/v1alpha3.ResourceGroupNameReferencer
-
-
-## ResourceGroupNameReferencerForVirtualNetworkRule
-
-ResourceGroupNameReferencerForVirtualNetworkRule is an attribute referencer that resolves the name of a the ResourceGroup.
-
-Appears in:
-
-* [MySQLVirtualNetworkRuleSpec](#MySQLVirtualNetworkRuleSpec)
-* [PostgreSQLVirtualNetworkRuleSpec](#PostgreSQLVirtualNetworkRuleSpec)
-
-
-
-
-ResourceGroupNameReferencerForVirtualNetworkRule supports all fields of:
-
-* github.com/crossplaneio/stack-azure/apis/v1alpha3.ResourceGroupNameReferencer
-
-
-## SQLServerClassSpecTemplate
-
-A SQLServerClassSpecTemplate is a template for the spec of a dynamically provisioned MySQLServer or PostgreSQLServer.
-
-Appears in:
-
-* [SQLServerClass](#SQLServerClass)
-
-
-
-
-SQLServerClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-* [SQLServerParameters](#SQLServerParameters)
-
-
-## SQLServerParameters
-
-SQLServerParameters define the desired state of an Azure SQL Database, either PostgreSQL or MySQL.
-
-Appears in:
-
-* [SQLServerClassSpecTemplate](#SQLServerClassSpecTemplate)
-* [SQLServerSpec](#SQLServerSpec)
-
-
-Name | Type | Description
------|------|------------
-`resourceGroupName` | string | ResourceGroupName specifies the name of the resource group that should contain this SQLServer.
-`resourceGroupNameRef` | [ResourceGroupNameReferencerForSQLServer](#ResourceGroupNameReferencerForSQLServer) | ResourceGroupNameRef - A reference to a ResourceGroup object to retrieve its name
-`location` | string | Location specifies the location of this SQLServer.
-`pricingTier` | [PricingTierSpec](#PricingTierSpec) | PricingTier specifies the pricing tier (aka SKU) for this SQLServer.
-`storageProfile` | [StorageProfileSpec](#StorageProfileSpec) | StorageProfile configures the storage profile of this SQLServer.
-`adminLoginName` | string | AdminLoginName specifies the administrator login name for this SQLServer.
-`version` | string | Version specifies the version of this server, for example "5.6", or "9.6".
-`sslEnforced` | Optional bool | SSLEnforced specifies whether SSL is required to connect to this SQLServer.
-
-
-
-## SQLServerSpec
-
-A SQLServerSpec defines the desired state of a SQLServer.
-
-Appears in:
-
-* [MySQLServer](#MySQLServer)
-* [PostgreSQLServer](#PostgreSQLServer)
-
-
-
-
-SQLServerSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [SQLServerParameters](#SQLServerParameters)
-
-
-## SQLServerStatus
-
-A SQLServerStatus represents the observed state of a SQLServer.
-
-Appears in:
-
-* [MySQLServer](#MySQLServer)
-* [PostgreSQLServer](#PostgreSQLServer)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State of this SQLServer.
-`message` | string | A Message containing detail on the state of this SQLServer, if any.
-`providerID` | string | ProviderID is the external ID to identify this resource in the cloud provider.
-`endpoint` | string | Endpoint of the MySQL Server instance used in connection strings.
-
-
-SQLServerStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## ServerNameReferencerForMySQLServerVirtualNetworkRule
-
-ServerNameReferencerForMySQLServerVirtualNetworkRule is an attribute referencer that resolves the name of a MySQLServer.
-
-
-
-
-ServerNameReferencerForMySQLServerVirtualNetworkRule supports all fields of:
-
-* [MySQLServerNameReferencer](#MySQLServerNameReferencer)
-
-
-## ServerNameReferencerForPostgreSQLServerVirtualNetworkRule
-
-ServerNameReferencerForPostgreSQLServerVirtualNetworkRule is an attribute referencer that resolves the name of a PostgreSQLServer.
-
-
-
-
-ServerNameReferencerForPostgreSQLServerVirtualNetworkRule supports all fields of:
-
-* [PostgreSQLServerNameReferencer](#PostgreSQLServerNameReferencer)
-
-
-## StorageProfileSpec
-
-A StorageProfileSpec represents storage related properties of a SQLServer.
-
-Appears in:
-
-* [SQLServerParameters](#SQLServerParameters)
-
-
-Name | Type | Description
------|------|------------
-`storageGB` | int | StorageGB configures the maximum storage allowed.
-`backupRetentionDays` | int | BackupRetentionDays configures how many days backups will be retained.
-`geoRedundantBackup` | bool | GeoRedundantBackup enables geo-redunndant backups.
-
-
-
-## SubnetIDReferencerForVirtualNetworkRule
-
-SubnetIDReferencerForVirtualNetworkRule is an attribute referencer that resolves id from a referenced Subnet and assigns it to a PostgreSQLServer or MySQL server object
-
-Appears in:
-
-* [VirtualNetworkRuleProperties](#VirtualNetworkRuleProperties)
-
-
-
-
-SubnetIDReferencerForVirtualNetworkRule supports all fields of:
-
-* github.com/crossplaneio/stack-azure/apis/network/v1alpha3.SubnetIDReferencer
-
-
-## VirtualNetworkRuleProperties
-
-VirtualNetworkRuleProperties defines the properties of a VirtualNetworkRule.
-
-Appears in:
-
-* [MySQLVirtualNetworkRuleSpec](#MySQLVirtualNetworkRuleSpec)
-* [PostgreSQLVirtualNetworkRuleSpec](#PostgreSQLVirtualNetworkRuleSpec)
-
-
-Name | Type | Description
------|------|------------
-`virtualNetworkSubnetId` | string | VirtualNetworkSubnetID - The ARM resource id of the virtual network subnet.
-`virtualNetworkSubnetIdRef` | [SubnetIDReferencerForVirtualNetworkRule](#SubnetIDReferencerForVirtualNetworkRule) | VirtualNetworkSubnetIDRef - A reference to a Subnet to retrieve its ID
-`ignoreMissingVnetServiceEndpoint` | bool | IgnoreMissingVnetServiceEndpoint - Create firewall rule before the virtual network has vnet service endpoint enabled.
-
-
-
-## VirtualNetworkRuleStatus
-
-A VirtualNetworkRuleStatus represents the observed state of a VirtualNetworkRule.
-
-Appears in:
-
-* [MySQLServerVirtualNetworkRule](#MySQLServerVirtualNetworkRule)
-* [PostgreSQLServerVirtualNetworkRule](#PostgreSQLServerVirtualNetworkRule)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State of this virtual network rule.
-`message` | string | A Message containing details about the state of this virtual network rule, if any.
-`id` | string | ID - Resource ID
-`type` | string | Type - Resource type.
-
-
-VirtualNetworkRuleStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-azure/network-azure-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-azure/network-azure-crossplane-io-v1alpha3.md
deleted file mode 100644
index 8f79a1cc..00000000
--- a/docs/v0.4/api/crossplaneio/stack-azure/network-azure-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,276 +0,0 @@
-# network.azure.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains managed resources for Azure network services such as virtual networks.
-
-This API group contains the following Crossplane resources:
-
-* [Subnet](#Subnet)
-* [VirtualNetwork](#VirtualNetwork)
-
-## Subnet
-
-A Subnet is a managed resource that represents an Azure Subnet.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `network.azure.crossplane.io/v1alpha3`
-`kind` | string | `Subnet`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [SubnetSpec](#SubnetSpec) | A SubnetSpec defines the desired state of a Subnet.
-`status` | [SubnetStatus](#SubnetStatus) | A SubnetStatus represents the observed state of a Subnet.
-
-
-
-## VirtualNetwork
-
-A VirtualNetwork is a managed resource that represents an Azure Virtual Network.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `network.azure.crossplane.io/v1alpha3`
-`kind` | string | `VirtualNetwork`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [VirtualNetworkSpec](#VirtualNetworkSpec) | A VirtualNetworkSpec defines the desired state of a VirtualNetwork.
-`status` | [VirtualNetworkStatus](#VirtualNetworkStatus) | A VirtualNetworkStatus represents the observed state of a VirtualNetwork.
-
-
-
-## AddressSpace
-
-AddressSpace contains an array of IP address ranges that can be used by subnets of the virtual network.
-
-Appears in:
-
-* [VirtualNetworkPropertiesFormat](#VirtualNetworkPropertiesFormat)
-
-
-Name | Type | Description
------|------|------------
-`addressPrefixes` | []string | AddressPrefixes - A list of address blocks reserved for this virtual network in CIDR notation.
-
-
-
-## ResourceGroupNameReferencerForSubnet
-
-ResourceGroupNameReferencerForSubnet is an attribute referencer that resolves name from a referenced ResourceGroup
-
-Appears in:
-
-* [SubnetSpec](#SubnetSpec)
-
-
-
-
-ResourceGroupNameReferencerForSubnet supports all fields of:
-
-* github.com/crossplaneio/stack-azure/apis/v1alpha3.ResourceGroupNameReferencer
-
-
-## ResourceGroupNameReferencerForVirtualNetwork
-
-ResourceGroupNameReferencerForVirtualNetwork is an attribute referencer that resolves name from a referenced ResourceGroup
-
-Appears in:
-
-* [VirtualNetworkSpec](#VirtualNetworkSpec)
-
-
-
-
-ResourceGroupNameReferencerForVirtualNetwork supports all fields of:
-
-* github.com/crossplaneio/stack-azure/apis/v1alpha3.ResourceGroupNameReferencer
-
-
-## ServiceEndpointPropertiesFormat
-
-ServiceEndpointPropertiesFormat defines properties of a service endpoint.
-
-Appears in:
-
-* [SubnetPropertiesFormat](#SubnetPropertiesFormat)
-
-
-Name | Type | Description
------|------|------------
-`service` | Optional string | Service - The type of the endpoint service.
-`locations` | Optional []string | Locations - A list of locations.
-`provisioningState` | Optional string | ProvisioningState - The provisioning state of the resource.
-
-
-
-## SubnetIDReferencer
-
-SubnetIDReferencer is used to get the name from another Subnet
-
-
-
-
-SubnetIDReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## SubnetPropertiesFormat
-
-SubnetPropertiesFormat defines properties of a Subnet.
-
-Appears in:
-
-* [SubnetSpec](#SubnetSpec)
-
-
-Name | Type | Description
------|------|------------
-`addressPrefix` | string | AddressPrefix - The address prefix for the subnet.
-`serviceEndpoints` | [[]ServiceEndpointPropertiesFormat](#ServiceEndpointPropertiesFormat) | ServiceEndpoints - An array of service endpoints.
-
-
-
-## SubnetSpec
-
-A SubnetSpec defines the desired state of a Subnet.
-
-Appears in:
-
-* [Subnet](#Subnet)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name - The name of the resource that is unique within a resource group. This name can be used to access the resource.
-`virtualNetworkName` | string | VirtualNetworkName - Name of the Subnet's virtual network.
-`virtualNetworkNameRef` | [VirtualNetworkNameReferencerForSubnet](#VirtualNetworkNameReferencerForSubnet) | VirtualNetworkNameRef references to a VirtualNetwork to retrieve its name
-`resourceGroupName` | string | ResourceGroupName - Name of the Subnet's resource group.
-`resourceGroupNameRef` | [ResourceGroupNameReferencerForSubnet](#ResourceGroupNameReferencerForSubnet) | ResourceGroupNameRef - A reference to the the Subnets's resource group.
-`properties` | [SubnetPropertiesFormat](#SubnetPropertiesFormat) | SubnetPropertiesFormat - Properties of the subnet.
-
-
-SubnetSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## SubnetStatus
-
-A SubnetStatus represents the observed state of a Subnet.
-
-Appears in:
-
-* [Subnet](#Subnet)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State of this Subnet.
-`message` | string | A Message providing detail about the state of this Subnet, if any.
-`etag` | string | Etag - A unique string that changes whenever the resource is updated.
-`id` | string | ID of this Subnet.
-`purpose` | string | Purpose - A string identifying the intention of use for this subnet based on delegations and other user-defined properties.
-
-
-SubnetStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## VirtualNetworkNameReferencer
-
-VirtualNetworkNameReferencer is used to get the name from another VirtualNetwork
-
-Appears in:
-
-* [VirtualNetworkNameReferencerForSubnet](#VirtualNetworkNameReferencerForSubnet)
-
-
-
-
-VirtualNetworkNameReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## VirtualNetworkNameReferencerForSubnet
-
-VirtualNetworkNameReferencerForSubnet is an attribute referencer that resolves name from a referenced Network
-
-Appears in:
-
-* [SubnetSpec](#SubnetSpec)
-
-
-
-
-VirtualNetworkNameReferencerForSubnet supports all fields of:
-
-* [VirtualNetworkNameReferencer](#VirtualNetworkNameReferencer)
-
-
-## VirtualNetworkPropertiesFormat
-
-VirtualNetworkPropertiesFormat defines properties of a VirtualNetwork.
-
-Appears in:
-
-* [VirtualNetworkSpec](#VirtualNetworkSpec)
-
-
-Name | Type | Description
------|------|------------
-`addressSpace` | Optional [AddressSpace](#AddressSpace) | AddressSpace - The AddressSpace that contains an array of IP address ranges that can be used by subnets.
-`enableDdosProtection` | Optional bool | EnableDDOSProtection - Indicates if DDoS protection is enabled for all the protected resources in the virtual network. It requires a DDoS protection plan associated with the resource.
-`enableVmProtection` | Optional bool | EnableVMProtection - Indicates if VM protection is enabled for all the subnets in the virtual network.
-
-
-
-## VirtualNetworkSpec
-
-A VirtualNetworkSpec defines the desired state of a VirtualNetwork.
-
-Appears in:
-
-* [VirtualNetwork](#VirtualNetwork)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name - Name of the Virtual Network.
-`resourceGroupName` | string | ResourceGroupName - Name of the Virtual Network's resource group.
-`resourceGroupNameRef` | [ResourceGroupNameReferencerForVirtualNetwork](#ResourceGroupNameReferencerForVirtualNetwork) | ResourceGroupNameRef - A reference to the the Virtual Network's resource group.
-`properties` | [VirtualNetworkPropertiesFormat](#VirtualNetworkPropertiesFormat) | VirtualNetworkPropertiesFormat - Properties of the virtual network.
-`location` | string | Location - Resource location.
-`tags` | Optional map[string]string | Tags - Resource tags.
-
-
-VirtualNetworkSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## VirtualNetworkStatus
-
-A VirtualNetworkStatus represents the observed state of a VirtualNetwork.
-
-Appears in:
-
-* [VirtualNetwork](#VirtualNetwork)
-
-
-Name | Type | Description
------|------|------------
-`state` | string | State of this VirtualNetwork.
-`message` | string | A Message providing detail about the state of this VirtualNetwork, if any.
-`id` | string | ID of this VirtualNetwork.
-`etag` | string | Etag - A unique read-only string that changes whenever the resource is updated.
-`resourceGuid` | string | ResourceGUID - The GUID of this VirtualNetwork.
-`type` | string | Type of this VirtualNetwork.
-
-
-VirtualNetworkStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-azure/storage-azure-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-azure/storage-azure-crossplane-io-v1alpha3.md
deleted file mode 100644
index 7e236462..00000000
--- a/docs/v0.4/api/crossplaneio/stack-azure/storage-azure-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,469 +0,0 @@
-# storage.azure.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains managed resources for Azure storage services such as containers and accounts.
-
-This API group contains the following Crossplane resources:
-
-* [Account](#Account)
-* [AccountClass](#AccountClass)
-* [Container](#Container)
-* [ContainerClass](#ContainerClass)
-
-## Account
-
-An Account is a managed resource that represents an Azure Blob Service Account.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.azure.crossplane.io/v1alpha3`
-`kind` | string | `Account`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [AccountSpec](#AccountSpec) | An AccountSpec defines the desired state of an Account.
-`status` | [AccountStatus](#AccountStatus) | An AccountStatus represents the observed state of an Account.
-
-
-
-## AccountClass
-
-An AccountClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.azure.crossplane.io/v1alpha3`
-`kind` | string | `AccountClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [AccountClassSpecTemplate](#AccountClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned Account.
-
-
-
-## Container
-
-A Container is a managed resource that represents an Azure Blob Storage Container.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.azure.crossplane.io/v1alpha3`
-`kind` | string | `Container`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ContainerSpec](#ContainerSpec) | A ContainerSpec defines the desired state of a Container.
-`status` | [ContainerStatus](#ContainerStatus) | A ContainerStatus represents the observed status of a Container.
-
-
-
-## ContainerClass
-
-A ContainerClass is a non-portable resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.azure.crossplane.io/v1alpha3`
-`kind` | string | `ContainerClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [ContainerClassSpecTemplate](#ContainerClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned Container.
-
-
-
-## AccountClassSpecTemplate
-
-An AccountClassSpecTemplate is a template for the spec of a dynamically provisioned Account.
-
-Appears in:
-
-* [AccountClass](#AccountClass)
-
-
-
-
-AccountClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-* [AccountParameters](#AccountParameters)
-
-
-## AccountParameters
-
-AccountParameters define the desired state of an Azure Blob Storage Account.
-
-Appears in:
-
-* [AccountClassSpecTemplate](#AccountClassSpecTemplate)
-* [AccountSpec](#AccountSpec)
-
-
-Name | Type | Description
------|------|------------
-`resourceGroupName` | string | ResourceGroupName specifies the resource group for this Account.
-`storageAccountName` | string | StorageAccountName specifies the name for this Account.
-`storageAccountSpec` | [StorageAccountSpec](#StorageAccountSpec) | StorageAccountSpec specifies the desired state of this Account.
-
-
-
-## AccountSpec
-
-An AccountSpec defines the desired state of an Account.
-
-Appears in:
-
-* [Account](#Account)
-
-
-
-
-AccountSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [AccountParameters](#AccountParameters)
-
-
-## AccountStatus
-
-An AccountStatus represents the observed state of an Account.
-
-Appears in:
-
-* [Account](#Account)
-
-
-
-
-AccountStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [StorageAccountStatus](#StorageAccountStatus)
-
-
-## ContainerClassSpecTemplate
-
-A ContainerClassSpecTemplate is a template for the spec of a dynamically provisioned Container.
-
-Appears in:
-
-* [ContainerClass](#ContainerClass)
-
-
-
-
-ContainerClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-* [ContainerParameters](#ContainerParameters)
-
-
-## ContainerParameters
-
-ContainerParameters define the desired state of an Azure Blob Storage Container.
-
-Appears in:
-
-* [ContainerClassSpecTemplate](#ContainerClassSpecTemplate)
-* [ContainerSpec](#ContainerSpec)
-
-
-Name | Type | Description
------|------|------------
-`nameFormat` | string | NameFormat specifies the name of the external Container. The first instance of the string '%s' will be replaced with the Kubernetes UID of this Container.
-`metadata` | Optional [azblob.Metadata](https://godoc.org/github.com/Azure/azure-storage-blob-go/azblob#Metadata) | Metadata for this Container.
-`publicAccessType` | Optional [azblob.PublicAccessType](https://godoc.org/github.com/Azure/azure-storage-blob-go/azblob#PublicAccessType) | PublicAccessType for this container; either "blob" or "container".
-`accountReference` | [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core) | AccountReference to the Azure Blob Storage Account this Container will reside within.
-
-
-
-## ContainerSpec
-
-A ContainerSpec defines the desired state of a Container.
-
-Appears in:
-
-* [Container](#Container)
-
-
-Name | Type | Description
------|------|------------
-`writeConnectionSecretToRef` | Optional [v1alpha1.SecretReference](../crossplane-runtime/core-crossplane-io-v1alpha1.md#secretreference) | WriteConnectionSecretToReference specifies the name of a Secret, in the same namespace as this managed resource, to which any connection details for this managed resource should be written. Connection details frequently include the endpoint, username, and password required to connect to the managed resource.
-`claimRef` | Optional [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | ClaimReference specifies the resource claim to which this managed resource will be bound. ClaimReference is set automatically during dynamic provisioning. Crossplane does not currently support setting this field manually, per https://github.com/crossplaneio/crossplane-runtime/issues/19
-`classRef` | Optional [core/v1.ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectreference-v1-core) | ClassReference specifies the non-portable resource class that was used to dynamically provision this managed resource, if any. Crossplane does not currently support setting this field manually, per https://github.com/crossplaneio/crossplane-runtime/issues/20
-`reclaimPolicy` | Optional [v1alpha1.ReclaimPolicy](../crossplane-runtime/core-crossplane-io-v1alpha1.md#reclaimpolicy) | ReclaimPolicy specifies what will happen to the external resource this managed resource manages when the managed resource is deleted. "Delete" deletes the external resource, while "Retain" (the default) does not. Note this behaviour is subtly different from other uses of the ReclaimPolicy concept within the Kubernetes ecosystem per https://github.com/crossplaneio/crossplane-runtime/issues/21
-
-
-ContainerSpec supports all fields of:
-
-* [ContainerParameters](#ContainerParameters)
-
-
-## ContainerStatus
-
-A ContainerStatus represents the observed status of a Container.
-
-Appears in:
-
-* [Container](#Container)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name of this Container.
-
-
-ContainerStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## CustomDomain
-
-CustomDomain specifies the custom domain assigned to this storage account.
-
-Appears in:
-
-* [StorageAccountSpecProperties](#StorageAccountSpecProperties)
-
-
-Name | Type | Description
------|------|------------
-`name` | Optional string | Name - custom domain name assigned to the storage account. Name is the CNAME source.
-`useSubDomainName` | Optional bool | UseSubDomainName - Indicates whether indirect CNAME validation is enabled.
-
-
-
-## EnabledEncryptionServices
-
-EnabledEncryptionServices a list of services that support encryption.
-
-Appears in:
-
-* [Encryption](#Encryption)
-
-
-Name | Type | Description
------|------|------------
-`blob` | bool | Blob - The encryption function of the blob storage service.
-`file` | bool | File - The encryption function of the file storage service.
-`table` | bool | Table - The encryption function of the table storage service.
-`queue` | bool | Queue - The encryption function of the queue storage service.
-
-
-
-## Encryption
-
-Encryption the encryption settings on the storage account.
-
-Appears in:
-
-* [StorageAccountSpecProperties](#StorageAccountSpecProperties)
-
-
-Name | Type | Description
------|------|------------
-`services` | [EnabledEncryptionServices](#EnabledEncryptionServices) | Services - List of services which support encryption.
-`keySource` | [storage.KeySource](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#KeySource) | KeySource - The encryption keySource (provider). Possible values (case-insensitive): Microsoft.Storage, Microsoft.Keyvault
-`keyvaultproperties` | [KeyVaultProperties](#KeyVaultProperties) | KeyVaultProperties - Properties provided by key vault.
-
-
-
-## Endpoints
-
-Endpoints the URIs that are used to perform a retrieval of a public blob, queue, or table object.
-
-Appears in:
-
-* [StorageAccountStatusProperties](#StorageAccountStatusProperties)
-
-
-Name | Type | Description
------|------|------------
-`blob` | string | Blob - the blob endpoint.
-`queue` | string | Queue - the queue endpoint.
-`table` | string | Table - the table endpoint.
-`file` | string | File - the file endpoint.
-
-
-
-## IPRule
-
-IPRule IP rule with specific IP or IP range in CIDR format.
-
-Appears in:
-
-* [NetworkRuleSet](#NetworkRuleSet)
-
-
-Name | Type | Description
------|------|------------
-`value` | string | IPAddressOrRange - Specifies the IP or IP range in CIDR format. Only IPV4 address is allowed.
-`action` | [storage.Action](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#Action) | Action - The action of IP ACL rule. Possible values include: 'Allow'
-
-
-
-## Identity
-
-Identity identity for the resource.
-
-Appears in:
-
-* [StorageAccountSpec](#StorageAccountSpec)
-
-
-Name | Type | Description
------|------|------------
-`principalId` | string | PrincipalID - The principal ID of resource identity.
-`tenantId` | string | TenantID - The tenant ID of resource.
-`type` | string | Type - The identity type.
-
-
-
-## KeyVaultProperties
-
-KeyVaultProperties properties of key vault.
-
-Appears in:
-
-* [Encryption](#Encryption)
-
-
-Name | Type | Description
------|------|------------
-`keyname` | string | KeyName - The name of KeyVault key.
-`keyversion` | string | KeyVersion - The version of KeyVault key.
-`keyvaulturi` | string | KeyVaultURI - The Uri of KeyVault.
-
-
-
-## NetworkRuleSet
-
-NetworkRuleSet network rule set
-
-Appears in:
-
-* [StorageAccountSpecProperties](#StorageAccountSpecProperties)
-
-
-Name | Type | Description
------|------|------------
-`bypass` | [storage.Bypass](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#Bypass) | Bypass - Specifies whether traffic is bypassed for Logging/Metrics/AzureServices. Possible values are any combination of Logging|Metrics|AzureServices (For example, "Logging, Metrics"), or None to bypass none of those traffics. Possible values include: 'None', 'Logging', 'Metrics', 'AzureServices'
-`virtualNetworkRules` | [[]VirtualNetworkRule](#VirtualNetworkRule) | VirtualNetworkRules - Sets the virtual network rules
-`ipRules` | [[]IPRule](#IPRule) | IPRules - Sets the IP ACL rules
-`defaultAction` | [storage.DefaultAction](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#DefaultAction) | DefaultAction - Specifies the default action of allow or deny when no other rules match. Possible values include: 'Allow', 'Deny'
-
-
-
-## Sku
-
-Sku of an Azure Blob Storage Account.
-
-Appears in:
-
-* [StorageAccountSpec](#StorageAccountSpec)
-
-
-Name | Type | Description
------|------|------------
-`capabilities` | [[]skuCapability](#skuCapability) | Capabilities - The capability information in the specified sku, including file encryption, network acls, change notification, etc.
-`kind` | [storage.Kind](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#Kind) | Kind - Indicates the type of storage account. Possible values include: 'Storage', 'BlobStorage'
-`locations` | []string | Locations - The set of locations that the Sku is available. This will be supported and registered Azure Geo Regions (e.g. West US, East US, Southeast Asia, etc.).
-`name` | [storage.SkuName](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#SkuName) | Name - Gets or sets the sku name. Required for account creation; optional for update. Note that in older versions, sku name was called accountType. Possible values include: 'Standard_LRS', 'Standard_GRS', 'Standard_RAGRS', 'Standard_ZRS', 'Premium_LRS'
-`resourceType` | string | ResourceType - The type of the resource, usually it is 'storageAccounts'.
-`tier` | [storage.SkuTier](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#SkuTier) | Tier - Gets the sku tier. This is based on the Sku name. Possible values include: 'Standard', 'Premium'
-
-
-
-## StorageAccountSpec
-
-A StorageAccountSpec defines the desired state of an Azure Blob Storage account.
-
-Appears in:
-
-* [AccountParameters](#AccountParameters)
-
-
-Name | Type | Description
------|------|------------
-`identity` | Optional [Identity](#Identity) | Identity - The identity of the resource.
-`kind` | [storage.Kind](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#Kind) | Kind - Indicates the type of storage account. Possible values include: 'Storage', 'BlobStorage'
-`location` | string | Location - The location of the resource. This will be one of the supported and registered Azure Geo Regions (e.g. West US, East US, Southeast Asia, etc.).
-`sku` | [Sku](#Sku) | Sku of the storage account.
-`properties` | Optional [StorageAccountSpecProperties](#StorageAccountSpecProperties) | StorageAccountSpecProperties - The parameters used to create the storage account.
-`tags` | Optional map[string]string | Tags - A list of key value pairs that describe the resource. These tags can be used for viewing and grouping this resource (across resource groups). A maximum of 15 tags can be provided for a resource. Each tag must have a key with a length no greater than 128 characters and a value with a length no greater than 256 characters.
-
-
-
-## StorageAccountSpecProperties
-
-StorageAccountSpecProperties the parameters used to create the storage account.
-
-Appears in:
-
-* [StorageAccountSpec](#StorageAccountSpec)
-
-
-Name | Type | Description
------|------|------------
-`accessTier` | [storage.AccessTier](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#AccessTier) | AccessTier - Required for storage accounts where kind = BlobStorage. The access tier used for billing. Possible values include: 'Hot', 'Cool'
-`customDomain` | [CustomDomain](#CustomDomain) | CustomDomain - User domain assigned to the storage account. Name is the CNAME source. Only one custom domain is supported per storage account at this time. to clear the existing custom domain, use an empty string for the custom domain name property.
-`supportsHttpsTrafficOnly` | bool | EnableHTTPSTrafficOnly - Allows https traffic only to storage service if sets to true.
-`encryption` | [Encryption](#Encryption) | Encryption - Provides the encryption settings on the account. If left unspecified the account encryption settings will remain the same. The default setting is unencrypted.
-`networkAcls` | [NetworkRuleSet](#NetworkRuleSet) | NetworkRuleSet - Network rule set
-
-
-
-## StorageAccountStatus
-
-A StorageAccountStatus represents the observed status of an Account.
-
-Appears in:
-
-* [AccountStatus](#AccountStatus)
-
-
-Name | Type | Description
------|------|------------
-`id` | string | ID of this Account.
-`name` | string | Name of this Account.
-`type` | string | Type of this Account.
-`properties` | [StorageAccountStatusProperties](#StorageAccountStatusProperties) | Properties of this Account.
-
-
-
-## StorageAccountStatusProperties
-
-StorageAccountStatusProperties represent the observed state of an Account.
-
-Appears in:
-
-* [StorageAccountStatus](#StorageAccountStatus)
-
-
-Name | Type | Description
------|------|------------
-`creationTime` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | CreationTime - the creation date and time of the storage account in UTC.
-`lastGeoFailoverTime` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | LastGeoFailoverTime - the timestamp of the most recent instance of a failover to the secondary location. Only the most recent timestamp is retained. This element is not returned if there has never been a failover instance. Only available if the accountType is Standard_GRS or Standard_RAGRS.
-`primaryEndpoints` | [Endpoints](#Endpoints) | PrimaryEndpoints - the URLs that are used to perform a retrieval of a public blob, queue, or table object. Note that Standard_ZRS and Premium_LRS accounts only return the blob endpoint.
-`primaryLocation` | string | PrimaryLocation - the location of the primary data center for the storage account.
-`provisioningState` | [storage.ProvisioningState](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#ProvisioningState) | ProvisioningState - the status of the storage account at the time the operation was called. Possible values include: 'Creating', 'ResolvingDNS', 'Succeeded'
-`secondaryEndpoints` | [Endpoints](#Endpoints) | SecondaryEndpoints - the URLs that are used to perform a retrieval of a public blob, queue, or table object from the secondary location of the storage account. Only available if the Sku name is Standard_RAGRS.
-`secondaryLocation` | string | SecondaryLocation - the location of the geo-replicated secondary for the storage account. Only available if the accountType is Standard_GRS or Standard_RAGRS.
-`statusOfPrimary` | [storage.AccountStatus](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#AccountStatus) | StatusOfPrimary - the status indicating whether the primary location of the storage account is available or unavailable. Possible values include: 'Available', 'Unavailable'
-`statusOfSecondary` | [storage.AccountStatus](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#AccountStatus) | StatusOfSecondary - the status indicating whether the secondary location of the storage account is available or unavailable. Only available if the Sku name is Standard_GRS or Standard_RAGRS. Possible values include: 'Available', 'Unavailable'
-
-
-
-## VirtualNetworkRule
-
-VirtualNetworkRule virtual Network rule.
-
-Appears in:
-
-* [NetworkRuleSet](#NetworkRuleSet)
-
-
-Name | Type | Description
------|------|------------
-`id` | string | VirtualNetworkResourceID - Resource ID of a subnet, for example: /subscriptions/{subscriptionId}/resourceGroups/{groupName}/providers/Microsoft.Network/virtualNetworks/{vnetName}/subnets/{subnetName}.
-`action` | [storage.Action](https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2017-06-01/storage#Action) | Action - The action of virtual network rule. Possible values include: 'Allow'
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-gcp/cache-gcp-crossplane-io-v1beta1.md b/docs/v0.4/api/crossplaneio/stack-gcp/cache-gcp-crossplane-io-v1beta1.md
deleted file mode 100644
index 55171c5e..00000000
--- a/docs/v0.4/api/crossplaneio/stack-gcp/cache-gcp-crossplane-io-v1beta1.md
+++ /dev/null
@@ -1,144 +0,0 @@
-# cache.gcp.crossplane.io/v1beta1 API Reference
-
-Package v1beta1 contains managed resources for GCP cache services such as CloudMemorystore.
-
-This API group contains the following Crossplane resources:
-
-* [CloudMemorystoreInstance](#CloudMemorystoreInstance)
-* [CloudMemorystoreInstanceClass](#CloudMemorystoreInstanceClass)
-
-## CloudMemorystoreInstance
-
-A CloudMemorystoreInstance is a managed resource that represents a Google Cloud Memorystore instance.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.gcp.crossplane.io/v1beta1`
-`kind` | string | `CloudMemorystoreInstance`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [CloudMemorystoreInstanceSpec](#CloudMemorystoreInstanceSpec) | A CloudMemorystoreInstanceSpec defines the desired state of a CloudMemorystoreInstance.
-`status` | [CloudMemorystoreInstanceStatus](#CloudMemorystoreInstanceStatus) | A CloudMemorystoreInstanceStatus represents the observed state of a CloudMemorystoreInstance.
-
-
-
-## CloudMemorystoreInstanceClass
-
-A CloudMemorystoreInstanceClass is a resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `cache.gcp.crossplane.io/v1beta1`
-`kind` | string | `CloudMemorystoreInstanceClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [CloudMemorystoreInstanceClassSpecTemplate](#CloudMemorystoreInstanceClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned CloudMemorystoreInstance.
-
-
-
-## CloudMemorystoreInstanceClassSpecTemplate
-
-A CloudMemorystoreInstanceClassSpecTemplate is a template for the spec of a dynamically provisioned CloudMemorystoreInstance.
-
-Appears in:
-
-* [CloudMemorystoreInstanceClass](#CloudMemorystoreInstanceClass)
-
-
-Name | Type | Description
------|------|------------
-`forProvider` | [CloudMemorystoreInstanceParameters](#CloudMemorystoreInstanceParameters) | CloudMemorystoreInstanceParameters define the desired state of an Google Cloud Memorystore instance. Most fields map directly to an Instance: https://cloud.google.com/memorystore/docs/redis/reference/rest/v1/projects.locations.instances#Instance
-
-
-CloudMemorystoreInstanceClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-
-
-## CloudMemorystoreInstanceObservation
-
-CloudMemorystoreInstanceObservation is used to show the observed state of the CloudMemorystore resource on GCP.
-
-Appears in:
-
-* [CloudMemorystoreInstanceStatus](#CloudMemorystoreInstanceStatus)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Unique name of the resource in this scope including project and location using the form: `projects/{project_id}/locations/{location_id}/instances/{instance_id}` Note: Redis instances are managed and addressed at regional level so location_id here refers to a GCP region; however, users may choose which specific zone (or collection of zones for cross-zone instances) an instance should be provisioned in. Refer to [location_id] and [alternative_location_id] fields for more details.
-`host` | string | Hostname or IP address of the exposed Redis endpoint used by clients to connect to the service.
-`port` | int32 | The port number of the exposed Redis endpoint.
-`currentLocationId` | string | The current zone where the Redis endpoint is placed. For Basic Tier instances, this will always be the same as the [location_id] provided by the user at creation time. For Standard Tier instances, this can be either [location_id] or [alternative_location_id] and can change after a failover event.
-`createTime` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | The time the instance was created.
-`state` | string | The current state of this instance.
-`statusMessage` | string | Additional information about the current status of this instance, if available.
-`persistenceIamIdentity` | string | Cloud IAM identity used by import / export operations to transfer data to/from Cloud Storage. Format is "serviceAccount:<service_account_email>". The value may change over time for a given instance so should be checked before each import/export operation.
-
-
-
-## CloudMemorystoreInstanceParameters
-
-CloudMemorystoreInstanceParameters define the desired state of an Google Cloud Memorystore instance. Most fields map directly to an Instance: https://cloud.google.com/memorystore/docs/redis/reference/rest/v1/projects.locations.instances#Instance
-
-Appears in:
-
-* [CloudMemorystoreInstanceClassSpecTemplate](#CloudMemorystoreInstanceClassSpecTemplate)
-* [CloudMemorystoreInstanceSpec](#CloudMemorystoreInstanceSpec)
-
-
-Name | Type | Description
------|------|------------
-`region` | string | Region in which to create this Cloud Memorystore cluster.
-`tier` | string | Tier specifies the replication level of the Redis cluster. BASIC provides a single Redis instance with no high availability. STANDARD_HA provides a cluster of two Redis instances in distinct availability zones. https://cloud.google.com/memorystore/docs/redis/redis-tiers
-`memorySizeGb` | int32 | Redis memory size in GiB.
-`displayName` | Optional string | An arbitrary and optional user-provided name for the instance.
-`labels` | Optional map[string]string | Resource labels to represent user provided metadata
-`locationId` | Optional string | The zone where the instance will be provisioned. If not provided, the service will choose a zone for the instance. For STANDARD_HA tier, instances will be created across two zones for protection against zonal failures. If [alternative_location_id] is also provided, it must be different from [location_id].
-`alternativeLocationId` | Optional string | Only applicable to STANDARD_HA tier which protects the instance against zonal failures by provisioning it across two zones. If provided, it must be a different zone from the one provided in [location_id].
-`redisVersion` | Optional string | The version of Redis software. If not provided, latest supported version will be used. Updating the version will perform an upgrade/downgrade to the new version. Currently, the supported values are: * `REDIS_4_0` for Redis 4.0 compatibility (default) * `REDIS_3_2` for Redis 3.2 compatibility
-`reservedIpRange` | Optional string | The CIDR range of internal addresses that are reserved for this instance. If not provided, the service will choose an unused /29 block, for example, 10.0.0.0/29 or 192.168.0.0/29. Ranges must be unique and non-overlapping with existing subnets in an authorized network.
-`redisConfigs` | Optional map[string]string | Redis configuration parameters, according to http://redis.io/topics/config. Currently, the only supported parameters are: Redis 3.2 and above: * maxmemory-policy * notify-keyspace-events Redis 4.0 and above: * activedefrag * lfu-log-factor * lfu-decay-time
-`authorizedNetwork` | Optional string | The full name of the Google Compute Engine [network](/compute/docs/networks-and-firewalls#networks) to which the instance is connected. If left unspecified, the `default` network will be used.
-
-
-
-## CloudMemorystoreInstanceSpec
-
-A CloudMemorystoreInstanceSpec defines the desired state of a CloudMemorystoreInstance.
-
-Appears in:
-
-* [CloudMemorystoreInstance](#CloudMemorystoreInstance)
-
-
-Name | Type | Description
------|------|------------
-`forProvider` | [CloudMemorystoreInstanceParameters](#CloudMemorystoreInstanceParameters) | CloudMemorystoreInstanceParameters define the desired state of an Google Cloud Memorystore instance. Most fields map directly to an Instance: https://cloud.google.com/memorystore/docs/redis/reference/rest/v1/projects.locations.instances#Instance
-
-
-CloudMemorystoreInstanceSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## CloudMemorystoreInstanceStatus
-
-A CloudMemorystoreInstanceStatus represents the observed state of a CloudMemorystoreInstance.
-
-Appears in:
-
-* [CloudMemorystoreInstance](#CloudMemorystoreInstance)
-
-
-Name | Type | Description
------|------|------------
-`atProvider` | [CloudMemorystoreInstanceObservation](#CloudMemorystoreInstanceObservation) | CloudMemorystoreInstanceObservation is used to show the observed state of the CloudMemorystore resource on GCP.
-
-
-CloudMemorystoreInstanceStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-gcp/compute-gcp-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-gcp/compute-gcp-crossplane-io-v1alpha3.md
deleted file mode 100644
index 16c6d133..00000000
--- a/docs/v0.4/api/crossplaneio/stack-gcp/compute-gcp-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,554 +0,0 @@
-# compute.gcp.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains managed resources for GCP compute services such as GKE.
-
-This API group contains the following Crossplane resources:
-
-* [GKECluster](#GKECluster)
-* [GKEClusterClass](#GKEClusterClass)
-* [GlobalAddress](#GlobalAddress)
-* [Network](#Network)
-* [Subnetwork](#Subnetwork)
-
-## GKECluster
-
-A GKECluster is a managed resource that represents a Google Kubernetes Engine cluster.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.gcp.crossplane.io/v1alpha3`
-`kind` | string | `GKECluster`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [GKEClusterSpec](#GKEClusterSpec) | A GKEClusterSpec defines the desired state of a GKECluster.
-`status` | [GKEClusterStatus](#GKEClusterStatus) | A GKEClusterStatus represents the observed state of a GKECluster.
-
-
-
-## GKEClusterClass
-
-A GKEClusterClass is a resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.gcp.crossplane.io/v1alpha3`
-`kind` | string | `GKEClusterClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [GKEClusterClassSpecTemplate](#GKEClusterClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned GKECluster.
-
-
-
-## GlobalAddress
-
-A GlobalAddress is a managed resource that represents a Google Compute Engine Global Address.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.gcp.crossplane.io/v1alpha3`
-`kind` | string | `GlobalAddress`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [GlobalAddressSpec](#GlobalAddressSpec) | A GlobalAddressSpec defines the desired state of a GlobalAddress.
-`status` | [GlobalAddressStatus](#GlobalAddressStatus) | A GlobalAddressStatus reflects the observed state of a GlobalAddress.
-
-
-
-## Network
-
-A Network is a managed resource that represents a Google Compute Engine VPC Network.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.gcp.crossplane.io/v1alpha3`
-`kind` | string | `Network`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [NetworkSpec](#NetworkSpec) | A NetworkSpec defines the desired state of a Network.
-`status` | [NetworkStatus](#NetworkStatus) | A NetworkStatus represents the observed state of a Network.
-
-
-
-## Subnetwork
-
-A Subnetwork is a managed resource that represents a Google Compute Engine VPC Subnetwork.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `compute.gcp.crossplane.io/v1alpha3`
-`kind` | string | `Subnetwork`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [SubnetworkSpec](#SubnetworkSpec) | A SubnetworkSpec defines the desired state of a Subnetwork.
-`status` | [SubnetworkStatus](#SubnetworkStatus) | A SubnetworkStatus represents the observed state of a Subnetwork.
-
-
-
-## GCPNetworkPeering
-
-A GCPNetworkPeering represents the observed state of a Google Compute Engine VPC Network Peering.
-
-
-Name | Type | Description
------|------|------------
-`autoCreateRoutes` | bool | AutoCreateRoutes: This field will be deprecated soon. Use the exchange_subnet_routes field instead. Indicates whether full mesh connectivity is created and managed automatically between peered networks. Currently this field should always be true since Google Compute Engine will automatically create and manage subnetwork routes between two networks when peering state is ACTIVE.
-`exchangeSubnetRoutes` | bool | ExchangeSubnetRoutes: Indicates whether full mesh connectivity is created and managed automatically between peered networks. Currently this field should always be true since Google Compute Engine will automatically create and manage subnetwork routes between two networks when peering state is ACTIVE.
-`name` | string | Name: Name of this peering. Provided by the client when the peering is created. The name must comply with RFC1035. Specifically, the name must be 1-63 characters long and match regular expression `[a-z]([-a-z0-9]*[a-z0-9])?`. The first character must be a lowercase letter, and all the following characters must be a dash, lowercase letter, or digit, except the last character, which cannot be a dash.
-`network` | string | Network: The URL of the peer network. It can be either full URL or partial URL. The peer network may belong to a different project. If the partial URL does not contain project, it is assumed that the peer network is in the same project as the current network.
-`state` | string | State: State for the peering, either `ACTIVE` or `INACTIVE`. The peering is `ACTIVE` when there's a matching configuration in the peer network. Possible values: "ACTIVE" "INACTIVE"
-`stateDetails` | string | StateDetails: Details about the current state of the peering.
-
-
-
-## GCPNetworkRoutingConfig
-
-A GCPNetworkRoutingConfig specifies the desired state of a Google Compute Engine VPC Network Routing configuration.
-
-Appears in:
-
-* [GCPNetworkStatus](#GCPNetworkStatus)
-* [NetworkParameters](#NetworkParameters)
-
-
-Name | Type | Description
------|------|------------
-`routingMode` | string | RoutingMode: The network-wide routing mode to use. If set to REGIONAL, this network's Cloud Routers will only advertise routes with subnets of this network in the same region as the router. If set to GLOBAL, this network's Cloud Routers will advertise routes with all subnets of this network, across regions. Possible values: "GLOBAL" "REGIONAL"
-
-
-
-## GCPNetworkStatus
-
-A GCPNetworkStatus represents the observed state of a Google Compute Engine VPC Network.
-
-Appears in:
-
-* [NetworkStatus](#NetworkStatus)
-
-
-Name | Type | Description
------|------|------------
-`IPv4Range` | string | IPv4Range: Deprecated in favor of subnet mode networks. The range of internal addresses that are legal on this network. This range is a CIDR specification, for example: 192.168.0.0/16. Provided by the client when the network is created.
-`autoCreateSubnetworks` | bool | AutoCreateSubnetworks: When set to true, the VPC network is created in "auto" mode. When set to false, the VPC network is created in "custom" mode. An auto mode VPC network starts with one subnet per region. Each subnet has a predetermined range as described in Auto mode VPC network IP ranges.
-`creationTimestamp` | string | CreationTimestamp: Creation timestamp in RFC3339 text format.
-`description` | string | Description: An optional description of this resource. Provide this field when you create the resource.
-`gatewayIPv4` | string | GatewayIPv4: The gateway address for default routing out of the network, selected by GCP.
-`id` | uint64 | Id: The unique identifier for the resource. This identifier is defined by the server.
-`peerings` | [[]*github.com/crossplaneio/stack-gcp/apis/compute/v1alpha3.GCPNetworkPeering](#*github.com/crossplaneio/stack-gcp/apis/compute/v1alpha3.GCPNetworkPeering) | Peerings: A list of network peerings for the resource.
-`routingConfig` | [GCPNetworkRoutingConfig](#GCPNetworkRoutingConfig) | RoutingConfig: The network-level routing configuration for this network. Used by Cloud Router to determine what type of network-wide routing behavior to enforce.
-`selfLink` | string | SelfLink: Server-defined URL for the resource.
-`subnetworks` | []string | Subnetworks: Server-defined fully-qualified URLs for all subnetworks in this VPC network.
-
-
-
-## GCPSubnetworkSecondaryRange
-
-A GCPSubnetworkSecondaryRange defines the state of a Google Compute Engine VPC Subnetwork secondary range.
-
-
-Name | Type | Description
------|------|------------
-`ipCidrRange` | string | IPCIDRRange: The range of IP addresses belonging to this subnetwork secondary range. Provide this property when you create the subnetwork. Ranges must be unique and non-overlapping with all primary and secondary IP ranges within a network. Only IPv4 is supported.
-`rangeName` | string | RangeName: The name associated with this subnetwork secondary range, used when adding an alias IP range to a VM instance. The name must be 1-63 characters long, and comply with RFC1035. The name must be unique within the subnetwork.
-
-
-
-## GCPSubnetworkStatus
-
-A GCPSubnetworkStatus represents the observed state of a Google Compute Engine VPC Subnetwork.
-
-Appears in:
-
-* [SubnetworkStatus](#SubnetworkStatus)
-
-
-Name | Type | Description
------|------|------------
-`creationTimestamp` | string | CreationTimestamp: Creation timestamp in RFC3339 text format.
-`description` | string | Description: An optional description of this resource. Provide this property when you create the resource. This field can be set only at resource creation time.
-`enableFlowLogs` | bool | EnableFlowLogs: Whether to enable flow logging for this subnetwork. If this field is not explicitly set, it will not appear in get listings. If not set the default behavior is to disable flow logging.
-`fingerprint` | string | Fingerprint: Fingerprint of this resource. A hash of the contents stored in this object. This field is used in optimistic locking. This field will be ignored when inserting a Subnetwork. An up-to-date fingerprint must be provided in order to update the Subnetwork, otherwise the request will fail with error 412 conditionNotMet. To see the latest fingerprint, make a get() request to retrieve a Subnetwork.
-`gatewayAddress` | string | GatewayAddress: The gateway address for default routes to reach destination addresses outside this subnetwork.
-`id` | uint64 | Id: The unique identifier for the resource. This identifier is defined by the server.
-`ipCidrRange` | string | IPCIDRRange: The range of internal addresses that are owned by this subnetwork. Provide this property when you create the subnetwork. For example, 10.0.0.0/8 or 192.168.0.0/16. Ranges must be unique and non-overlapping within a network. Only IPv4 is supported. This field can be set only at resource creation time.
-`kind` | string | Kind: Type of the resource. Always compute#subnetwork for Subnetwork resources.
-`name` | string | Name: The name of the resource, provided by the client when initially creating the resource. The name must be 1-63 characters long, and comply with RFC1035. Specifically, the name must be 1-63 characters long and match the regular expression `[a-z]([-a-z0-9]*[a-z0-9])?` which means the first character must be a lowercase letter, and all following characters must be a dash, lowercase letter, or digit, except the last character, which cannot be a dash.
-`network` | string | Network: The URL of the network to which this subnetwork belongs, provided by the client when initially creating the subnetwork. Only networks that are in the distributed mode can have subnetworks. This field can be set only at resource creation time.
-`privateIpGoogleAccess` | bool | PrivateIPGoogleAccess: Whether the VMs in this subnet can access Google services without assigned external IP addresses. This field can be both set at resource creation time and updated using setPrivateIPGoogleAccess.
-`region` | string | Region: URL of the region where the Subnetwork resides. This field can be set only at resource creation time.
-`secondaryIpRanges` | [[]*github.com/crossplaneio/stack-gcp/apis/compute/v1alpha3.GCPSubnetworkSecondaryRange](#*github.com/crossplaneio/stack-gcp/apis/compute/v1alpha3.GCPSubnetworkSecondaryRange) | SecondaryIPRanges: An array of configurations for secondary IP ranges for VM instances contained in this subnetwork. The primary IP of such VM must belong to the primary ipCidrRange of the subnetwork. The alias IPs may belong to either primary or secondary ranges. This field can be updated with a patch request.
-`selfLink` | string | SelfLink: Server-defined URL for the resource.
-
-
-
-## GKEClusterClassSpecTemplate
-
-A GKEClusterClassSpecTemplate is a template for the spec of a dynamically provisioned GKECluster.
-
-Appears in:
-
-* [GKEClusterClass](#GKEClusterClass)
-
-
-
-
-GKEClusterClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-* [GKEClusterParameters](#GKEClusterParameters)
-
-
-## GKEClusterParameters
-
-GKEClusterParameters define the desired state of a Google Kubernetes Engine cluster.
-
-Appears in:
-
-* [GKEClusterClassSpecTemplate](#GKEClusterClassSpecTemplate)
-* [GKEClusterSpec](#GKEClusterSpec)
-
-
-Name | Type | Description
------|------|------------
-`clusterVersion` | Optional string | ClusterVersion is the initial Kubernetes version for this cluster. Users may specify either explicit versions offered by Kubernetes Engine or version aliases, for example "latest", "1.X", or "1.X.Y". Leave unset to use the default version.
-`labels` | Optional map[string]string | Labels for the cluster to use to annotate any related Google Compute Engine resources.
-`machineType` | Optional string | MachineType is the name of a Google Compute Engine machine type (e.g. n1-standard-1). If unspecified the default machine type is n1-standard-1.
-`numNodes` | int64 | NumNodes is the number of nodes to create in this cluster. You must ensure that your Compute Engine resource quota is sufficient for this number of instances. You must also have available firewall and routes quota.
-`zone` | Optional string | Zone specifies the name of the Google Compute Engine zone in which this cluster resides.
-`scopes` | Optional []string | Scopes are the set of Google API scopes to be made available on all of the node VMs under the "default" service account.
-`network` | Optional string | Network is the name of the Google Compute Engine network to which the cluster is connected. If left unspecified, the default network will be used.
-`networkRef` | [NetworkURIReferencerForGKECluster](#NetworkURIReferencerForGKECluster) | NetworkRef references to a Network and retrieves its URI
-`subnetwork` | Optional string | Subnetwork is the name of the Google Compute Engine subnetwork to which the cluster is connected.
-`subnetworkRef` | [SubnetworkURIReferencerForGKECluster](#SubnetworkURIReferencerForGKECluster) | SubnetworkRef references to a Subnetwork and retrieves its URI
-`enableIPAlias` | Optional bool | EnableIPAlias determines whether Alias IPs will be used for pod IPs in the cluster.
-`createSubnetwork` | Optional bool | CreateSubnetwork determines whether a new subnetwork will be created automatically for the cluster. Only applicable when EnableIPAlias is true.
-`nodeIPV4CIDR` | Optional string | NodeIPV4CIDR specifies the IP address range of the instance IPs in this cluster. This is applicable only if CreateSubnetwork is true. Omit this field to have a range chosen with the default size. Set it to a netmask (e.g. /24) to have a range chosen with a specific netmask.
-`clusterIPV4CIDR` | Optional string | ClusterIPV4CIDR specifies the IP address range of the pod IPs in this cluster. This is applicable only if EnableIPAlias is true. Omit this field to have a range chosen with the default size. Set it to a netmask (e.g. /24) to have a range chosen with a specific netmask.
-`clusterSecondaryRangeName` | Optional string | ClusterSecondaryRangeName specifies the name of the secondary range to be used for the cluster CIDR block. The secondary range will be used for pod IP addresses. This must be an existing secondary range associated with the cluster subnetwork.
-`serviceIPV4CIDR` | Optional string | ServiceIPV4CIDR specifies the IP address range of service IPs in this cluster. This is applicable only if EnableIPAlias is true. Omit this field to have a range chosen with the default size. Set it to a netmask (e.g. /24) to have a range chosen with a specific netmask.
-`servicesSecondaryRangeName` | string | ServicesSecondaryRangeName specifies the name of the secondary range to be used as for the services CIDR block. The secondary range will be used for service ClusterIPs. This must be an existing secondary range associated with the cluster subnetwork.
-
-
-
-## GKEClusterSpec
-
-A GKEClusterSpec defines the desired state of a GKECluster.
-
-Appears in:
-
-* [GKECluster](#GKECluster)
-
-
-
-
-GKEClusterSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [GKEClusterParameters](#GKEClusterParameters)
-
-
-## GKEClusterStatus
-
-A GKEClusterStatus represents the observed state of a GKECluster.
-
-Appears in:
-
-* [GKECluster](#GKECluster)
-
-
-Name | Type | Description
------|------|------------
-`clusterName` | string | ClusterName is the name of this GKE cluster. The name is automatically generated by Crossplane.
-`endpoint` | string | Endpoint of the GKE cluster used in connection strings.
-`state` | string | State of this GKE cluster.
-
-
-GKEClusterStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## GlobalAddressNameReferencer
-
-GlobalAddressNameReferencer retrieves a Name from a referenced GlobalAddress object
-
-
-
-
-GlobalAddressNameReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## GlobalAddressParameters
-
-GlobalAddressParameters define the desired state of a Google Compute Engine Global Address. Most fields map directly to an Address: https://cloud.google.com/compute/docs/reference/rest/v1/globalAddresses
-
-Appears in:
-
-* [GlobalAddressSpec](#GlobalAddressSpec)
-
-
-Name | Type | Description
------|------|------------
-`address` | Optional string | Address: The static IP address represented by this resource.
-`addressType` | Optional string | AddressType: The type of address to reserve, either INTERNAL or EXTERNAL. If unspecified, defaults to EXTERNAL. Possible values: "EXTERNAL" "INTERNAL" "UNSPECIFIED_TYPE"
-`description` | Optional string | Description: An optional description of this resource.
-`ipVersion` | Optional string | IPVersion: The IP version that will be used by this address. Valid options are IPV4 or IPV6. Possible values: "IPV4" "IPV6" "UNSPECIFIED_VERSION"
-`name` | string | Name of the resource. The name must be 1-63 characters long, and comply with RFC1035. Specifically, the name must be 1-63 characters long and match the regular expression `[a-z]([-a-z0-9]*[a-z0-9])?`. The first character must be a lowercase letter, and all following characters (except for the last character) must be a dash, lowercase letter, or digit. The last character must be a lowercase letter or digit.
-`network` | Optional string | Network: The URL of the network in which to reserve the address. This field can only be used with INTERNAL type with the VPC_PEERING purpose.
-`networkRef` | [NetworkURIReferencerForGlobalAddress](#NetworkURIReferencerForGlobalAddress) | NetworkRef references to a Network and retrieves its URI
-`prefixLength` | Optional int64 | PrefixLength: The prefix length if the resource represents an IP range.
-`purpose` | Optional string | Purpose: The purpose of this resource, which can be one of the following values: - `GCE_ENDPOINT` for addresses that are used by VM instances, alias IP ranges, internal load balancers, and similar resources. - `DNS_RESOLVER` for a DNS resolver address in a subnetwork - `VPC_PEERING` for addresses that are reserved for VPC peer networks. - `NAT_AUTO` for addresses that are external IP addresses automatically reserved for Cloud NAT. Possible values: "DNS_RESOLVER" "GCE_ENDPOINT" "NAT_AUTO" "VPC_PEERING"
-`subnetwork` | Optional string | Subnetwork: The URL of the subnetwork in which to reserve the address. If an IP address is specified, it must be within the subnetwork's IP range. This field can only be used with INTERNAL type with a GCE_ENDPOINT or DNS_RESOLVER purpose.
-
-
-
-## GlobalAddressSpec
-
-A GlobalAddressSpec defines the desired state of a GlobalAddress.
-
-Appears in:
-
-* [GlobalAddress](#GlobalAddress)
-
-
-
-
-GlobalAddressSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [GlobalAddressParameters](#GlobalAddressParameters)
-
-
-## GlobalAddressStatus
-
-A GlobalAddressStatus reflects the observed state of a GlobalAddress.
-
-Appears in:
-
-* [GlobalAddress](#GlobalAddress)
-
-
-Name | Type | Description
------|------|------------
-`creationTimestamp` | string | CreationTimestamp in RFC3339 text format.
-`id` | uint64 | ID for the resource. This identifier is defined by the server.
-`selfLink` | string | SelfLink: Server-defined URL for the resource.
-`status` | string | Status of the address, which can be one of RESERVING, RESERVED, or IN_USE. An address that is RESERVING is currently in the process of being reserved. A RESERVED address is currently reserved and available to use. An IN_USE address is currently being used by another resource and is not available. Possible values: "IN_USE" "RESERVED" "RESERVING"
-`users` | []string | Users that are using this address.
-
-
-GlobalAddressStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## NetworkParameters
-
-NetworkParameters define the desired state of a Google Compute Engine VPC Network. Most fields map directly to a Network: https://cloud.google.com/compute/docs/reference/rest/v1/networks
-
-Appears in:
-
-* [NetworkSpec](#NetworkSpec)
-
-
-Name | Type | Description
------|------|------------
-`IPv4Range` | string | IPv4Range: Deprecated in favor of subnet mode networks. The range of internal addresses that are legal on this network. This range is a CIDR specification, for example: 192.168.0.0/16. Provided by the client when the network is created.
-`autoCreateSubnetworks` | bool | AutoCreateSubnetworks: When set to true, the VPC network is created in "auto" mode. When set to false, the VPC network is created in "custom" mode. When set to nil, the VPC network is created in "legacy" mode which will be deprecated by GCP soon. An auto mode VPC network starts with one subnet per region. Each subnet has a predetermined range as described in Auto mode VPC network IP ranges.
-`description` | string | Description: An optional description of this resource. Provide this field when you create the resource.
-`name` | string | Name: Name of the resource. Provided by the client when the resource is created. The name must be 1-63 characters long, and comply with RFC1035. Specifically, the name must be 1-63 characters long and match the regular expression `[a-z]([-a-z0-9]*[a-z0-9])?. The first character must be a lowercase letter, and all following characters (except for the last character) must be a dash, lowercase letter, or digit. The last character must be a lowercase letter or digit.
-`routingConfig` | [GCPNetworkRoutingConfig](#GCPNetworkRoutingConfig) | RoutingConfig: The network-level routing configuration for this network. Used by Cloud Router to determine what type of network-wide routing behavior to enforce.
-
-
-
-## NetworkSpec
-
-A NetworkSpec defines the desired state of a Network.
-
-Appears in:
-
-* [Network](#Network)
-
-
-
-
-NetworkSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [NetworkParameters](#NetworkParameters)
-
-
-## NetworkStatus
-
-A NetworkStatus represents the observed state of a Network.
-
-Appears in:
-
-* [Network](#Network)
-
-
-
-
-NetworkStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [GCPNetworkStatus](#GCPNetworkStatus)
-
-
-## NetworkURIReferencer
-
-NetworkURIReferencer retrieves a NetworkURI from a referenced Network object
-
-Appears in:
-
-* [NetworkURIReferencerForGKECluster](#NetworkURIReferencerForGKECluster)
-* [NetworkURIReferencerForGlobalAddress](#NetworkURIReferencerForGlobalAddress)
-* [NetworkURIReferencerForSubnetwork](#NetworkURIReferencerForSubnetwork)
-
-
-
-
-NetworkURIReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## NetworkURIReferencerForGKECluster
-
-NetworkURIReferencerForGKECluster is an attribute referencer that resolves network uri from a referenced Network and assigns it to a GKECluster
-
-Appears in:
-
-* [GKEClusterParameters](#GKEClusterParameters)
-
-
-
-
-NetworkURIReferencerForGKECluster supports all fields of:
-
-* [NetworkURIReferencer](#NetworkURIReferencer)
-
-
-## NetworkURIReferencerForGlobalAddress
-
-NetworkURIReferencerForGlobalAddress is an attribute referencer that resolves network uri from a referenced Network and assigns it to a global address object
-
-Appears in:
-
-* [GlobalAddressParameters](#GlobalAddressParameters)
-
-
-
-
-NetworkURIReferencerForGlobalAddress supports all fields of:
-
-* [NetworkURIReferencer](#NetworkURIReferencer)
-
-
-## NetworkURIReferencerForSubnetwork
-
-NetworkURIReferencerForSubnetwork is an attribute referencer that resolves network uri from a referenced Network and assigns it to a subnetwork
-
-Appears in:
-
-* [SubnetworkParameters](#SubnetworkParameters)
-
-
-
-
-NetworkURIReferencerForSubnetwork supports all fields of:
-
-* [NetworkURIReferencer](#NetworkURIReferencer)
-
-
-## SubnetworkParameters
-
-SubnetworkParameters define the desired state of a Google Compute Engine VPC Subnetwork. Most fields map directly to a Subnetwork: https://cloud.google.com/compute/docs/reference/rest/v1/subnetworks
-
-Appears in:
-
-* [SubnetworkSpec](#SubnetworkSpec)
-
-
-Name | Type | Description
------|------|------------
-`description` | Optional string | Description: An optional description of this resource. Provide this property when you create the resource. This field can be set only at resource creation time.
-`enableFlowLogs` | Optional bool | EnableFlowLogs: Whether to enable flow logging for this subnetwork. If this field is not explicitly set, it will not appear in get listings. If not set the default behavior is to disable flow logging.
-`ipCidrRange` | string | IPCIDRRange: The range of internal addresses that are owned by this subnetwork. Provide this property when you create the subnetwork. For example, 10.0.0.0/8 or 192.168.0.0/16. Ranges must be unique and non-overlapping within a network. Only IPv4 is supported. This field can be set only at resource creation time.
-`name` | string | Name: The name of the resource, provided by the client when initially creating the resource. The name must be 1-63 characters long, and comply with RFC1035. Specifically, the name must be 1-63 characters long and match the regular expression `[a-z]([-a-z0-9]*[a-z0-9])?` which means the first character must be a lowercase letter, and all following characters must be a dash, lowercase letter, or digit, except the last character, which cannot be a dash.
-`network` | string | Network: The URL of the network to which this subnetwork belongs, provided by the client when initially creating the subnetwork. Only networks that are in the distributed mode can have subnetworks. This field can be set only at resource creation time.
-`networkRef` | [NetworkURIReferencerForSubnetwork](#NetworkURIReferencerForSubnetwork) | NetworkRef references to a Network and retrieves its URI
-`privateIpGoogleAccess` | Optional bool | PrivateIPGoogleAccess: Whether the VMs in this subnet can access Google services without assigned external IP addresses. This field can be both set at resource creation time and updated using setPrivateIPGoogleAccess.
-`region` | Optional string | Region: URL of the region where the Subnetwork resides. This field can be set only at resource creation time.
-`secondaryIpRanges` | Optional [[]*github.com/crossplaneio/stack-gcp/apis/compute/v1alpha3.GCPSubnetworkSecondaryRange](#*github.com/crossplaneio/stack-gcp/apis/compute/v1alpha3.GCPSubnetworkSecondaryRange) | SecondaryIPRanges: An array of configurations for secondary IP ranges for VM instances contained in this subnetwork. The primary IP of such VM must belong to the primary ipCidrRange of the subnetwork. The alias IPs may belong to either primary or secondary ranges. This field can be updated with a patch request.
-
-
-
-## SubnetworkSpec
-
-A SubnetworkSpec defines the desired state of a Subnetwork.
-
-Appears in:
-
-* [Subnetwork](#Subnetwork)
-
-
-
-
-SubnetworkSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [SubnetworkParameters](#SubnetworkParameters)
-
-
-## SubnetworkStatus
-
-A SubnetworkStatus represents the observed state of a Subnetwork.
-
-Appears in:
-
-* [Subnetwork](#Subnetwork)
-
-
-
-
-SubnetworkStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-* [GCPSubnetworkStatus](#GCPSubnetworkStatus)
-
-
-## SubnetworkURIReferencer
-
-SubnetworkURIReferencer retrieves a SubnetworkURI from a referenced Subnetwork object
-
-Appears in:
-
-* [SubnetworkURIReferencerForGKECluster](#SubnetworkURIReferencerForGKECluster)
-
-
-
-
-SubnetworkURIReferencer supports all fields of:
-
-* [core/v1.LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#localobjectreference-v1-core)
-
-
-## SubnetworkURIReferencerForGKECluster
-
-SubnetworkURIReferencerForGKECluster is an attribute referencer that resolves subnetwork uri from a referenced Subnetwork and assigns it to a GKECluster
-
-Appears in:
-
-* [GKEClusterParameters](#GKEClusterParameters)
-
-
-
-
-SubnetworkURIReferencerForGKECluster supports all fields of:
-
-* [SubnetworkURIReferencer](#SubnetworkURIReferencer)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-gcp/database-gcp-crossplane-io-v1beta1.md b/docs/v0.4/api/crossplaneio/stack-gcp/database-gcp-crossplane-io-v1beta1.md
deleted file mode 100644
index 5c16389d..00000000
--- a/docs/v0.4/api/crossplaneio/stack-gcp/database-gcp-crossplane-io-v1beta1.md
+++ /dev/null
@@ -1,382 +0,0 @@
-# database.gcp.crossplane.io/v1beta1 API Reference
-
-Package v1beta1 contains managed resources for GCP database services such as CloudSQL.
-
-This API group contains the following Crossplane resources:
-
-* [CloudSQLInstance](#CloudSQLInstance)
-* [CloudSQLInstanceClass](#CloudSQLInstanceClass)
-
-## CloudSQLInstance
-
-A CloudSQLInstance is a managed resource that represents a Google CloudSQL instance.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.gcp.crossplane.io/v1beta1`
-`kind` | string | `CloudSQLInstance`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [CloudSQLInstanceSpec](#CloudSQLInstanceSpec) | A CloudSQLInstanceSpec defines the desired state of a CloudSQLInstance.
-`status` | [CloudSQLInstanceStatus](#CloudSQLInstanceStatus) | A CloudSQLInstanceStatus represents the observed state of a CloudSQLInstance.
-
-
-
-## CloudSQLInstanceClass
-
-A CloudSQLInstanceClass is a resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.gcp.crossplane.io/v1beta1`
-`kind` | string | `CloudSQLInstanceClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [CloudSQLInstanceClassSpecTemplate](#CloudSQLInstanceClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned CloudSQLInstance.
-
-
-
-## ACLEntry
-
-ACLEntry is an entry for an Access Control list.
-
-
-Name | Type | Description
------|------|------------
-`expirationTime` | Optional string | ExpirationTime: The time when this access control entry expires in RFC 3339 format, for example 2012-11-15T16:19:00.094Z.
-`name` | Optional string | Name: An optional label to identify this entry.
-`value` | Optional string | Value: The whitelisted value for the access control list.
-
-
-
-## BackupConfiguration
-
-BackupConfiguration is database instance backup configuration.
-
-Appears in:
-
-* [Settings](#Settings)
-
-
-Name | Type | Description
------|------|------------
-`binaryLogEnabled` | Optional bool | BinaryLogEnabled: Whether binary log is enabled. If backup configuration is disabled, binary log must be disabled as well.
-`enabled` | Optional bool | Enabled: Whether this configuration is enabled.
-`location` | Optional string | Location: The location of the backup.
-`replicationLogArchivingEnabled` | Optional bool | ReplicationLogArchivingEnabled: Reserved for future use.
-`startTime` | Optional string | StartTime: Start time for the daily backup configuration in UTC timezone in the 24 hour format - HH:MM.
-
-
-
-## CloudSQLInstanceClassSpecTemplate
-
-A CloudSQLInstanceClassSpecTemplate is a template for the spec of a dynamically provisioned CloudSQLInstance.
-
-Appears in:
-
-* [CloudSQLInstanceClass](#CloudSQLInstanceClass)
-
-
-Name | Type | Description
------|------|------------
-`forProvider` | [CloudSQLInstanceParameters](#CloudSQLInstanceParameters) | CloudSQLInstanceParameters define the desired state of a Google CloudSQL instance.
-
-
-CloudSQLInstanceClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-
-
-## CloudSQLInstanceObservation
-
-CloudSQLInstanceObservation is used to show the observed state of the Cloud SQL resource on GCP.
-
-Appears in:
-
-* [CloudSQLInstanceStatus](#CloudSQLInstanceStatus)
-
-
-Name | Type | Description
------|------|------------
-`backendType` | string | BackendType: FIRST_GEN: First Generation instance. MySQL only. SECOND_GEN: Second Generation instance or PostgreSQL instance. EXTERNAL: A database server that is not managed by Google. This property is read-only; use the tier property in the settings object to determine the database type and Second or First Generation.
-`currentDiskSize` | int64 | CurrentDiskSize: The current disk usage of the instance in bytes. This property has been deprecated. Users should use the "cloudsql.googleapis.com/database/disk/bytes_used" metric in Cloud Monitoring API instead. Please see this announcement for details.
-`connectionName` | string | ConnectionName: Connection name of the Cloud SQL instance used in connection strings.
-`diskEncryptionStatus` | [DiskEncryptionStatus](#DiskEncryptionStatus) | DiskEncryptionStatus: Disk encryption status specific to an instance. Applies only to Second Generation instances.
-`failoverReplica` | [DatabaseInstanceFailoverReplicaStatus](#DatabaseInstanceFailoverReplicaStatus) | FailoverReplica: The name and status of the failover replica. This property is applicable only to Second Generation instances.
-`gceZone` | string | GceZone: The Compute Engine zone that the instance is currently serving from. This value could be different from the zone that was specified when the instance was created if the instance has failed over to its secondary zone.
-`ipAddresses` | [[]*github.com/crossplaneio/stack-gcp/apis/database/v1beta1.IPMapping](#*github.com/crossplaneio/stack-gcp/apis/database/v1beta1.IPMapping) | IPAddresses: The assigned IP addresses for the instance.
-`ipv6Address` | string | IPv6Address: The IPv6 address assigned to the instance. This property is applicable only to First Generation instances.
-`project` | string | Project: The project ID of the project containing the Cloud SQL instance. The Google apps domain is prefixed if applicable.
-`selfLink` | string | SelfLink: The URI of this resource.
-`serviceAccountEmailAddress` | string | ServiceAccountEmailAddress: The service account email address assigned to the instance. This property is applicable only to Second Generation instances.
-`state` | string | State: The current serving state of the Cloud SQL instance. This can be one of the following. RUNNABLE: The instance is running, or is ready to run when accessed. SUSPENDED: The instance is not available, for example due to problems with billing. PENDING_CREATE: The instance is being created. MAINTENANCE: The instance is down for maintenance. FAILED: The instance creation failed. UNKNOWN_STATE: The state of the instance is unknown.
-`settingsVersion` | int64 | SettingsVersion: The version of instance settings. This is a required field for update method to make sure concurrent updates are handled properly. During update, use the most recent settingsVersion value for this instance and do not try to update this value.
-
-
-
-## CloudSQLInstanceParameters
-
-CloudSQLInstanceParameters define the desired state of a Google CloudSQL instance.
-
-Appears in:
-
-* [CloudSQLInstanceClassSpecTemplate](#CloudSQLInstanceClassSpecTemplate)
-* [CloudSQLInstanceSpec](#CloudSQLInstanceSpec)
-
-
-Name | Type | Description
------|------|------------
-`region` | string | Region: The geographical region. Can be us-central (FIRST_GEN instances only), us-central1 (SECOND_GEN instances only), asia-east1 or europe-west1. Defaults to us-central or us-central1 depending on the instance type (First Generation or Second Generation). The region can not be changed after instance creation.
-`settings` | [Settings](#Settings) | Settings: The user settings.
-`databaseVersion` | Optional string | DatabaseVersion: The database engine type and version. The databaseVersion field can not be changed after instance creation. MySQL Second Generation instances: MYSQL_5_7 (default) or MYSQL_5_6. PostgreSQL instances: POSTGRES_9_6 (default) or POSTGRES_11 Beta. MySQL First Generation instances: MYSQL_5_6 (default) or MYSQL_5_5
-`masterInstanceName` | Optional string | MasterInstanceName: The name of the instance which will act as master in the replication setup.
-`diskEncryptionConfiguration` | Optional [DiskEncryptionConfiguration](#DiskEncryptionConfiguration) | DiskEncryptionConfiguration: Disk encryption configuration specific to an instance. Applies only to Second Generation instances.
-`failoverReplica` | Optional [DatabaseInstanceFailoverReplicaSpec](#DatabaseInstanceFailoverReplicaSpec) | FailoverReplica: The name and status of the failover replica. This property is applicable only to Second Generation instances.
-`gceZone` | Optional string | GceZone: The Compute Engine zone that the instance is currently serving from. This value could be different from the zone that was specified when the instance was created if the instance has failed over to its secondary zone.
-`instanceType` | Optional string | InstanceType: The instance type. This can be one of the following. CLOUD_SQL_INSTANCE: A Cloud SQL instance that is not replicating from a master. ON_PREMISES_INSTANCE: An instance running on the customer's premises. READ_REPLICA_INSTANCE: A Cloud SQL instance configured as a read-replica.
-`maxDiskSize` | Optional int64 | MaxDiskSize: The maximum disk size of the instance in bytes.
-`onPremisesConfiguration` | Optional [OnPremisesConfiguration](#OnPremisesConfiguration) | OnPremisesConfiguration: Configuration specific to on-premises instances.
-`replicaNames` | Optional []string | ReplicaNames: The replicas of the instance.
-`suspensionReason` | Optional []string | SuspensionReason: If the instance state is SUSPENDED, the reason for the suspension.
-
-
-
-## CloudSQLInstanceSpec
-
-A CloudSQLInstanceSpec defines the desired state of a CloudSQLInstance.
-
-Appears in:
-
-* [CloudSQLInstance](#CloudSQLInstance)
-
-
-Name | Type | Description
------|------|------------
-`forProvider` | [CloudSQLInstanceParameters](#CloudSQLInstanceParameters) | CloudSQLInstanceParameters define the desired state of a Google CloudSQL instance.
-
-
-CloudSQLInstanceSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## CloudSQLInstanceStatus
-
-A CloudSQLInstanceStatus represents the observed state of a CloudSQLInstance.
-
-Appears in:
-
-* [CloudSQLInstance](#CloudSQLInstance)
-
-
-Name | Type | Description
------|------|------------
-`atProvider` | [CloudSQLInstanceObservation](#CloudSQLInstanceObservation) | CloudSQLInstanceObservation is used to show the observed state of the Cloud SQL resource on GCP.
-
-
-CloudSQLInstanceStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## DatabaseFlags
-
-DatabaseFlags are database flags for Cloud SQL instances.
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name: The name of the flag. These flags are passed at instance startup, so include both server options and system variables for MySQL. Flags should be specified with underscores, not hyphens. For more information, see Configuring Database Flags in the Cloud SQL documentation.
-`value` | string | Value: The value of the flag. Booleans should be set to on for true and off for false. This field must be omitted if the flag doesn't take a value.
-
-
-
-## DatabaseInstanceFailoverReplicaSpec
-
-DatabaseInstanceFailoverReplicaSpec is where you can specify a name for the failover replica.
-
-Appears in:
-
-* [CloudSQLInstanceParameters](#CloudSQLInstanceParameters)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name: The name of the failover replica. If specified at instance creation, a failover replica is created for the instance. The name doesn't include the project ID. This property is applicable only to Second Generation instances.
-
-
-
-## DatabaseInstanceFailoverReplicaStatus
-
-DatabaseInstanceFailoverReplicaStatus is status of the failover replica.
-
-Appears in:
-
-* [CloudSQLInstanceObservation](#CloudSQLInstanceObservation)
-
-
-Name | Type | Description
------|------|------------
-`available` | bool | Available: The availability status of the failover replica. A false status indicates that the failover replica is out of sync. The master can only failover to the failover replica when the status is true.
-
-
-
-## DiskEncryptionConfiguration
-
-DiskEncryptionConfiguration is disk encryption configuration.
-
-Appears in:
-
-* [CloudSQLInstanceParameters](#CloudSQLInstanceParameters)
-
-
-Name | Type | Description
------|------|------------
-`kmsKeyName` | string | KmsKeyName: KMS key resource name
-
-
-
-## DiskEncryptionStatus
-
-DiskEncryptionStatus is disk encryption status.
-
-Appears in:
-
-* [CloudSQLInstanceObservation](#CloudSQLInstanceObservation)
-
-
-Name | Type | Description
------|------|------------
-`kmsKeyVersionName` | string | KmsKeyVersionName: KMS key version used to encrypt the Cloud SQL instance disk
-
-
-
-## IPConfiguration
-
-IPConfiguration is the IP Management configuration.
-
-Appears in:
-
-* [Settings](#Settings)
-
-
-Name | Type | Description
------|------|------------
-`authorizedNetworks` | Optional [[]*github.com/crossplaneio/stack-gcp/apis/database/v1beta1.ACLEntry](#*github.com/crossplaneio/stack-gcp/apis/database/v1beta1.ACLEntry) | AuthorizedNetworks: The list of external networks that are allowed to connect to the instance using the IP. In CIDR notation, also known as 'slash' notation (e.g. 192.168.100.0/24).
-`ipv4Enabled` | Optional bool | Ipv4Enabled: Whether the instance should be assigned an IP address or not.
-`privateNetwork` | Optional string | PrivateNetwork: The resource link for the VPC network from which the Cloud SQL instance is accessible for private IP. For example, /projects/myProject/global/networks/default. This setting can be updated, but it cannot be removed after it is set.
-`privateNetworkRef` | [NetworkURIReferencerForCloudSQLInstance](#NetworkURIReferencerForCloudSQLInstance) | PrivateNetworkRef references to a Network and retrieves its URI
-`requireSsl` | Optional bool | RequireSsl: Whether SSL connections over IP should be enforced or not.
-
-
-
-## IPMapping
-
-IPMapping is database instance IP Mapping.
-
-
-Name | Type | Description
------|------|------------
-`ipAddress` | string | IPAddress: The IP address assigned.
-`timeToRetire` | string | TimeToRetire: The due time for this IP to be retired in RFC 3339 format, for example 2012-11-15T16:19:00.094Z. This field is only available when the IP is scheduled to be retired.
-`type` | string | Type: The type of this IP address. A PRIMARY address is a public address that can accept incoming connections. A PRIVATE address is a private address that can accept incoming connections. An OUTGOING address is the source address of connections originating from the instance, if supported.
-
-
-
-## LocationPreference
-
-LocationPreference is preferred location. This specifies where a Cloud SQL instance should preferably be located, either in a specific Compute Engine zone, or co-located with an App Engine application. Note that if the preferred location is not available, the instance will be located as close as possible within the region. Only one location may be specified.
-
-Appears in:
-
-* [Settings](#Settings)
-
-
-Name | Type | Description
------|------|------------
-`followGaeApplication` | Optional string | FollowGaeApplication: The AppEngine application to follow, it must be in the same region as the Cloud SQL instance.
-`zone` | Optional string | Zone: The preferred Compute Engine zone (e.g. us-central1-a, us-central1-b, etc.).
-
-
-
-## MaintenanceWindow
-
-MaintenanceWindow specifies when a v2 Cloud SQL instance should preferably be restarted for system maintenance purposes.
-
-Appears in:
-
-* [Settings](#Settings)
-
-
-Name | Type | Description
------|------|------------
-`day` | Optional int64 | Day: day of week (1-7), starting on Monday.
-`hour` | Optional int64 | Hour: hour of day - 0 to 23.
-`updateTrack` | Optional string | UpdateTrack: Maintenance timing setting: canary (Earlier) or stable (Later).
-
-
-
-## NetworkURIReferencerForCloudSQLInstance
-
-NetworkURIReferencerForCloudSQLInstance is an attribute referencer that resolves network uri from a referenced Network and assigns it to a CloudSQLInstance
-
-Appears in:
-
-* [IPConfiguration](#IPConfiguration)
-
-
-
-
-NetworkURIReferencerForCloudSQLInstance supports all fields of:
-
-* github.com/crossplaneio/stack-gcp/apis/compute/v1alpha3.NetworkURIReferencer
-
-
-## OnPremisesConfiguration
-
-OnPremisesConfiguration is on-premises instance configuration.
-
-Appears in:
-
-* [CloudSQLInstanceParameters](#CloudSQLInstanceParameters)
-
-
-Name | Type | Description
------|------|------------
-`hostPort` | string | HostPort: The host and port of the on-premises instance in host:port format
-
-
-
-## Settings
-
-Settings is Cloud SQL database instance settings.
-
-Appears in:
-
-* [CloudSQLInstanceParameters](#CloudSQLInstanceParameters)
-
-
-Name | Type | Description
------|------|------------
-`tier` | string | Tier: The tier (or machine type) for this instance, for example db-n1-standard-1 (MySQL instances) or db-custom-1-3840 (PostgreSQL instances). For MySQL instances, this property determines whether the instance is First or Second Generation. For more information, see Instance Settings.
-`activationPolicy` | Optional string | ActivationPolicy: The activation policy specifies when the instance is activated; it is applicable only when the instance state is RUNNABLE. Valid values: ALWAYS: The instance is on, and remains so even in the absence of connection requests. NEVER: The instance is off; it is not activated, even if a connection request arrives. ON_DEMAND: First Generation instances only. The instance responds to incoming requests, and turns itself off when not in use. Instances with PER_USE pricing turn off after 15 minutes of inactivity. Instances with PER_PACKAGE pricing turn off after 12 hours of inactivity.
-`authorizedGaeApplications` | Optional []string | AuthorizedGaeApplications: The App Engine app IDs that can access this instance. First Generation instances only.
-`availabilityType` | Optional string | AvailabilityType: Availability type (PostgreSQL instances only). Potential values: ZONAL: The instance serves data from only one zone. Outages in that zone affect data accessibility. REGIONAL: The instance can serve data from more than one zone in a region (it is highly available). For more information, see Overview of the High Availability Configuration.
-`crashSafeReplicationEnabled` | Optional bool | CrashSafeReplicationEnabled: Configuration specific to read replica instances. Indicates whether database flags for crash-safe replication are enabled. This property is only applicable to First Generation instances.
-`storageAutoResize` | Optional bool | StorageAutoResize: Configuration to increase storage size automatically. The default value is true. Not used for First Generation instances.
-`dataDiskType` | Optional string | DataDiskType: The type of data disk: PD_SSD (default) or PD_HDD. Not used for First Generation instances.
-`pricingPlan` | Optional string | PricingPlan: The pricing plan for this instance. This can be either PER_USE or PACKAGE. Only PER_USE is supported for Second Generation instances.
-`replicationType` | Optional string | ReplicationType: The type of replication this instance uses. This can be either ASYNCHRONOUS or SYNCHRONOUS. This property is only applicable to First Generation instances.
-`userLabels` | Optional map[string]string | UserLabels: User-provided labels, represented as a dictionary where each label is a single key value pair.
-`databaseFlags` | Optional [[]*github.com/crossplaneio/stack-gcp/apis/database/v1beta1.DatabaseFlags](#*github.com/crossplaneio/stack-gcp/apis/database/v1beta1.DatabaseFlags) | DatabaseFlags is the array of database flags passed to the instance at startup.
-`backupConfiguration` | Optional [BackupConfiguration](#BackupConfiguration) | BackupConfiguration is the daily backup configuration for the instance.
-`ipConfiguration` | Optional [IPConfiguration](#IPConfiguration) | IPConfiguration: The settings for IP Management. This allows to enable or disable the instance IP and manage which external networks can connect to the instance. The IPv4 address cannot be disabled for Second Generation instances.
-`locationPreference` | Optional [LocationPreference](#LocationPreference) | LocationPreference is the location preference settings. This allows the instance to be located as near as possible to either an App Engine app or Compute Engine zone for better performance. App Engine co-location is only applicable to First Generation instances.
-`maintenanceWindow` | Optional [MaintenanceWindow](#MaintenanceWindow) | MaintenanceWindow: The maintenance window for this instance. This specifies when the instance can be restarted for maintenance purposes. Not used for First Generation instances.
-`dataDiskSizeGb` | Optional int64 | DataDiskSizeGb: The size of data disk, in GB. The data disk size minimum is 10GB. Not used for First Generation instances.
-`databaseReplicationEnabled` | Optional bool | DatabaseReplicationEnabled: Configuration specific to read replica instances. Indicates whether replication is enabled or not.
-`storageAutoResizeLimit` | Optional int64 | StorageAutoResizeLimit: The maximum size to which storage capacity can be automatically increased. The default value is 0, which specifies that there is no limit. Not used for First Generation instances.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-gcp/gcp-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-gcp/gcp-crossplane-io-v1alpha3.md
deleted file mode 100644
index d4ddfa0c..00000000
--- a/docs/v0.4/api/crossplaneio/stack-gcp/gcp-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# gcp.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains the core resources of the Google Cloud Platform.
-
-This API group contains the following Crossplane resources:
-
-* [Provider](#Provider)
-
-## Provider
-
-A Provider configures a GCP 'provider', i.e. a connection to a particular GCP project using a particular GCP service account
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `gcp.crossplane.io/v1alpha3`
-`kind` | string | `Provider`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ProviderSpec](#ProviderSpec) | A ProviderSpec defines the desired state of a Provider.
-
-
-
-## ProviderSpec
-
-A ProviderSpec defines the desired state of a Provider.
-
-Appears in:
-
-* [Provider](#Provider)
-
-
-Name | Type | Description
------|------|------------
-`credentialsSecretRef` | [v1alpha1.SecretKeySelector](../crossplane-runtime/core-crossplane-io-v1alpha1.md#secretkeyselector) | A Secret containing JSON encoded credentials for a Google Service Account that will be used to authenticate to this GCP Provider.
-`projectID` | string | ProjectID is the project name (not numerical ID) of this GCP Provider.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-gcp/servicenetworking-gcp-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-gcp/servicenetworking-gcp-crossplane-io-v1alpha3.md
deleted file mode 100644
index e2ab6e19..00000000
--- a/docs/v0.4/api/crossplaneio/stack-gcp/servicenetworking-gcp-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,108 +0,0 @@
-# servicenetworking.gcp.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains managed resources for GCP service networking services such as connections.
-
-This API group contains the following Crossplane resources:
-
-* [Connection](#Connection)
-
-## Connection
-
-A Connection is a managed resource that represents a Google Cloud Service Networking Connection.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `servicenetworking.gcp.crossplane.io/v1alpha3`
-`kind` | string | `Connection`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [ConnectionSpec](#ConnectionSpec) | A ConnectionSpec defines the desired state of a Connection.
-`status` | [ConnectionStatus](#ConnectionStatus) | A ConnectionStatus represents the observed state of a Connection.
-
-
-
-## ConnectionParameters
-
-ConnectionParameters define the desired state of a Google Cloud Service Networking Connection. Most fields map direct to a Connection: https://cloud.google.com/service-infrastructure/docs/service-networking/reference/rest/v1/services.connections#Connection
-
-Appears in:
-
-* [ConnectionSpec](#ConnectionSpec)
-
-
-Name | Type | Description
------|------|------------
-`parent` | string | Parent: The service that is managing peering connectivity for a service producer's organization. For Google services that support this functionality, this value is services/servicenetworking.googleapis.com.
-`network` | string | Network: The name of service consumer's VPC network that's connected with service producer network, in the following format: `projects/{project}/global/networks/{network}`. `{project}` is a project number, such as in `12345` that includes the VPC service consumer's VPC network. `{network}` is the name of the service consumer's VPC network.
-`networkRef` | [NetworkURIReferencerForConnection](#NetworkURIReferencerForConnection) | NetworkRef references to a Network and retrieves its URI
-`reservedPeeringRanges` | Optional []string | ReservedPeeringRanges: The name of one or more allocated IP address ranges for this service producer of type `PEERING`.
-`reservedPeeringRangeRefs` | [[]*github.com/crossplaneio/stack-gcp/apis/servicenetworking/v1alpha3.GlobalAddressNameReferencerForConnection](#*github.com/crossplaneio/stack-gcp/apis/servicenetworking/v1alpha3.GlobalAddressNameReferencerForConnection) | ReservedPeeringRangeRefs is a set of references to GlobalAddress objects
-
-
-
-## ConnectionSpec
-
-A ConnectionSpec defines the desired state of a Connection.
-
-Appears in:
-
-* [Connection](#Connection)
-
-
-
-
-ConnectionSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [ConnectionParameters](#ConnectionParameters)
-
-
-## ConnectionStatus
-
-A ConnectionStatus represents the observed state of a Connection.
-
-Appears in:
-
-* [Connection](#Connection)
-
-
-Name | Type | Description
------|------|------------
-`peering` | string | Peering: The name of the VPC Network Peering connection that was created by the service producer.
-`service` | string | Service: The name of the peering service that's associated with this connection, in the following format: `services/{service name}`.
-
-
-ConnectionStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## GlobalAddressNameReferencerForConnection
-
-GlobalAddressNameReferencerForConnection is an attribute referencer that resolves name from a referenced GlobalAddress and assigns it to a Connection
-
-
-
-
-GlobalAddressNameReferencerForConnection supports all fields of:
-
-* github.com/crossplaneio/stack-gcp/apis/compute/v1alpha3.GlobalAddressNameReferencer
-
-
-## NetworkURIReferencerForConnection
-
-NetworkURIReferencerForConnection is an attribute referencer that resolves network uri from a referenced Network and assigns it to a connection
-
-Appears in:
-
-* [ConnectionParameters](#ConnectionParameters)
-
-
-
-
-NetworkURIReferencerForConnection supports all fields of:
-
-* github.com/crossplaneio/stack-gcp/apis/compute/v1alpha3.NetworkURIReferencer
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-gcp/storage-gcp-crossplane-io-v1alpha3.md b/docs/v0.4/api/crossplaneio/stack-gcp/storage-gcp-crossplane-io-v1alpha3.md
deleted file mode 100644
index 750a2618..00000000
--- a/docs/v0.4/api/crossplaneio/stack-gcp/storage-gcp-crossplane-io-v1alpha3.md
+++ /dev/null
@@ -1,395 +0,0 @@
-# storage.gcp.crossplane.io/v1alpha3 API Reference
-
-Package v1alpha3 contains managed resources for GCP storage services such as GCS buckets.
-
-This API group contains the following Crossplane resources:
-
-* [Bucket](#Bucket)
-* [BucketClass](#BucketClass)
-
-## Bucket
-
-A Bucket is a managed resource that represents a Google Cloud Storage bucket.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.gcp.crossplane.io/v1alpha3`
-`kind` | string | `Bucket`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [BucketSpec](#BucketSpec) | A BucketSpec defines the desired state of a Bucket.
-`status` | [BucketStatus](#BucketStatus) | A BucketStatus represents the observed state of a Bucket.
-
-
-
-## BucketClass
-
-A BucketClass is a resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `storage.gcp.crossplane.io/v1alpha3`
-`kind` | string | `BucketClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [BucketClassSpecTemplate](#BucketClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned Bucket.
-
-
-
-## ACLRule
-
-ACLRule represents a grant for a role to an entity (user, group or team) for a Google Cloud Storage object or bucket.
-
-Appears in:
-
-* [BucketSpecAttrs](#BucketSpecAttrs)
-
-
-Name | Type | Description
------|------|------------
-`entity` | string |
-`entityId` | string |
-`role` | string |
-`domain` | string |
-`email` | string |
-`projectTeam` | [ProjectTeam](#ProjectTeam) |
-
-
-
-## BucketClassSpecTemplate
-
-A BucketClassSpecTemplate is a template for the spec of a dynamically provisioned Bucket.
-
-Appears in:
-
-* [BucketClass](#BucketClass)
-
-
-
-
-BucketClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-* [BucketParameters](#BucketParameters)
-
-
-## BucketEncryption
-
-BucketEncryption is a bucket's encryption configuration.
-
-Appears in:
-
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-Name | Type | Description
------|------|------------
-`defaultKmsKeyName` | string | A Cloud KMS key name, in the form projects/P/locations/L/keyRings/R/cryptoKeys/K, that will be used to encrypt objects inserted into this bucket, if no encryption method is specified. The key's location must be the same as the bucket's.
-
-
-
-## BucketLogging
-
-BucketLogging holds the bucket's logging configuration, which defines the destination bucket and optional name prefix for the current bucket's logs.
-
-Appears in:
-
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-Name | Type | Description
------|------|------------
-`logBucket` | string | The destination bucket where the current bucket's logs should be placed.
-`logObjectPrefix` | string | A prefix for log object names.
-
-
-
-## BucketOutputAttrs
-
-BucketOutputAttrs represent the subset of metadata for a Google Cloud Storage bucket limited to output (read-only) fields.
-
-Appears in:
-
-* [BucketStatus](#BucketStatus)
-
-
-Name | Type | Description
------|------|------------
-`bucketPolicyOnly` | [BucketPolicyOnly](#BucketPolicyOnly) | BucketPolicyOnly configures access checks to use only bucket-level IAM policies.
-`created` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | Created is the creation time of the bucket.
-`name` | string | Name is the name of the bucket.
-`retentionPolicy` | [RetentionPolicyStatus](#RetentionPolicyStatus) | Retention policy enforces a minimum retention time for all objects contained in the bucket. A RetentionPolicy of nil implies the bucket has no minimum data retention. This feature is in private alpha release. It is not currently available to most customers. It might be changed in backwards-incompatible ways and is not subject to any SLA or deprecation policy.
-
-
-
-## BucketParameters
-
-BucketParameters define the desired state of a Google Cloud Storage Bucket. Most fields map directly to a bucket resource: https://cloud.google.com/storage/docs/json_api/v1/buckets#resource
-
-Appears in:
-
-* [BucketClassSpecTemplate](#BucketClassSpecTemplate)
-* [BucketSpec](#BucketSpec)
-
-
-Name | Type | Description
------|------|------------
-`nameFormat` | string | NameFormat specifies the name of the external Bucket. The first instance of the string '%s' will be replaced with the Kubernetes UID of this Bucket.
-`serviceAccountSecretRef` | [v1alpha1.SecretReference](../crossplane-runtime/core-crossplane-io-v1alpha1.md#secretreference) | ServiceAccountSecretRef contains GCP ServiceAccount secret that will be used for bucket connection secret credentials
-
-
-BucketParameters supports all fields of:
-
-* [BucketSpecAttrs](#BucketSpecAttrs)
-
-
-## BucketPolicyOnly
-
-BucketPolicyOnly configures access checks to use only bucket-level IAM policies.
-
-Appears in:
-
-* [BucketOutputAttrs](#BucketOutputAttrs)
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-Name | Type | Description
------|------|------------
-`enabled` | bool | Enabled specifies whether access checks use only bucket-level IAM policies. Enabled may be disabled until the locked time.
-`lockedTime` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | LockedTime specifies the deadline for changing Enabled from true to false.
-
-
-
-## BucketSpec
-
-A BucketSpec defines the desired state of a Bucket.
-
-Appears in:
-
-* [Bucket](#Bucket)
-
-
-
-
-BucketSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-* [BucketParameters](#BucketParameters)
-
-
-## BucketSpecAttrs
-
-BucketSpecAttrs represents the full set of metadata for a Google Cloud Storage bucket limited to all input attributes
-
-Appears in:
-
-* [BucketParameters](#BucketParameters)
-
-
-Name | Type | Description
------|------|------------
-`acl` | [[]ACLRule](#ACLRule) | ACL is the list of access control rules on the bucket.
-`defaultObjectAcl` | [[]ACLRule](#ACLRule) | DefaultObjectACL is the list of access controls to apply to new objects when no object ACL is provided.
-`location` | string | Location is the location of the bucket. It defaults to "US".
-`storageClass` | string | StorageClass is the default storage class of the bucket. This defines how objects in the bucket are stored and determines the SLA and the cost of storage. Typical values are "MULTI_REGIONAL", "REGIONAL", "NEARLINE", "COLDLINE", "STANDARD" and "DURABLE_REDUCED_AVAILABILITY". Defaults to "STANDARD", which is equivalent to "MULTI_REGIONAL" or "REGIONAL" depending on the bucket's location settings.
-
-
-BucketSpecAttrs supports all fields of:
-
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-## BucketStatus
-
-A BucketStatus represents the observed state of a Bucket.
-
-Appears in:
-
-* [Bucket](#Bucket)
-
-
-Name | Type | Description
------|------|------------
-`attributes` | [BucketOutputAttrs](#BucketOutputAttrs) | BucketOutputAttrs represent the subset of metadata for a Google Cloud Storage bucket limited to output (read-only) fields.
-
-
-BucketStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## BucketUpdatableAttrs
-
-BucketUpdatableAttrs represents the subset of parameters of a Google Cloud Storage bucket that may be updated.
-
-Appears in:
-
-* [BucketSpecAttrs](#BucketSpecAttrs)
-
-
-Name | Type | Description
------|------|------------
-`bucketPolicyOnly` | [BucketPolicyOnly](#BucketPolicyOnly) | BucketPolicyOnly configures access checks to use only bucket-level IAM policies.
-`cors` | [[]CORS](#CORS) | The bucket's Cross-Origin Resource Sharing (CORS) configuration.
-`defaultEventBasedHold` | bool | DefaultEventBasedHold is the default value for event-based hold on newly created objects in this bucket. It defaults to false.
-`encryption` | [BucketEncryption](#BucketEncryption) | The encryption configuration used by default for newly inserted objects.
-`labels` | map[string]string | Labels are the bucket's labels.
-`lifecycle` | [Lifecycle](#Lifecycle) | Lifecycle is the lifecycle configuration for objects in the bucket.
-`logging` | [BucketLogging](#BucketLogging) | The logging configuration.
-`predefinedAcl` | string | If not empty, applies a predefined set of access controls. It should be set only when creating a bucket. It is always empty for BucketAttrs returned from the service. See https://cloud.google.com/storage/docs/json_api/v1/buckets/insert for valid values.
-`predefinedCefaultObjectAcl` | string | If not empty, applies a predefined set of default object access controls. It should be set only when creating a bucket. It is always empty for BucketAttrs returned from the service. See https://cloud.google.com/storage/docs/json_api/v1/buckets/insert for valid values.
-`requesterPays` | bool | RequesterPays reports whether the bucket is a Requester Pays bucket. Clients performing operations on Requester Pays buckets must provide a user project (see BucketHandle.UserProject), which will be billed for the operations.
-`retentionPolicy` | [RetentionPolicy](#RetentionPolicy) | Retention policy enforces a minimum retention time for all objects contained in the bucket. A RetentionPolicy of nil implies the bucket has no minimum data retention. This feature is in private alpha release. It is not currently available to most customers. It might be changed in backwards-incompatible ways and is not subject to any SLA or deprecation policy.
-`versioningEnabled` | bool | VersioningEnabled reports whether this bucket has versioning enabled.
-`website` | [BucketWebsite](#BucketWebsite) | The website configuration.
-
-
-
-## BucketWebsite
-
-BucketWebsite holds the bucket's website configuration, controlling how the service behaves when accessing bucket contents as a web site. See https://cloud.google.com/storage/docs/static-website for more information.
-
-Appears in:
-
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-Name | Type | Description
------|------|------------
-`mainPageSuffix` | string | If the requested object path is missing, the service will ensure the path has a trailing '/', append this suffix, and attempt to retrieve the resulting object. This allows the creation of index.html objects to represent directory pages.
-`notFundPage` | string | If the requested object path is missing, and any mainPageSuffix object is missing, if applicable, the service will return the named object from this bucket as the content for a 404 Not Found result.
-
-
-
-## CORS
-
-CORS is the bucket's Cross-Origin Resource Sharing (CORS) configuration.
-
-Appears in:
-
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-Name | Type | Description
------|------|------------
-`maxAge` | [meta/v1.Duration](https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration) | MaxAge is the value to return in the Access-Control-Max-Age header used in preflight responses.
-`methods` | []string | Methods is the list of HTTP methods on which to include CORS response headers, (GET, OPTIONS, POST, etc) Note: "*" is permitted in the list of methods, and means "any method".
-`origins` | []string | Origins is the list of Origins eligible to receive CORS response headers. Note: "*" is permitted in the list of origins, and means "any Origin".
-`responseHeaders` | []string | ResponseHeaders is the list of HTTP headers other than the simple response headers to give permission for the user-agent to share across domains.
-
-
-
-## Lifecycle
-
-Lifecycle is the lifecycle configuration for objects in the bucket.
-
-Appears in:
-
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-Name | Type | Description
------|------|------------
-`rules` | [[]LifecycleRule](#LifecycleRule) |
-
-
-
-## LifecycleAction
-
-LifecycleAction is a lifecycle configuration action.
-
-Appears in:
-
-* [LifecycleRule](#LifecycleRule)
-
-
-Name | Type | Description
------|------|------------
-`storageClass` | string | StorageClass is the storage class to set on matching objects if the Action is "SetStorageClass".
-`type` | string | Type is the type of action to take on matching objects. Acceptable values are "Delete" to delete matching objects and "SetStorageClass" to set the storage class defined in StorageClass on matching objects.
-
-
-
-## LifecycleCondition
-
-LifecycleCondition is a set of conditions used to match objects and take an action automatically. All configured conditions must be met for the associated action to be taken.
-
-Appears in:
-
-* [LifecycleRule](#LifecycleRule)
-
-
-Name | Type | Description
------|------|------------
-`ageInDays` | int64 | AgeInDays is the age of the object in days.
-`createdBefore` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | CreatedBefore is the time the object was created. This condition is satisfied when an object is created before midnight of the specified date in UTC.
-`liveness` | [storage.Liveness](https://godoc.org/cloud.google.com/go/storage#Liveness) | Liveness specifies the object's liveness. Relevant only for versioned objects
-`matchesStorageClasses` | []string | MatchesStorageClasses is the condition matching the object's storage class. Values include "MULTI_REGIONAL", "REGIONAL", "NEARLINE", "COLDLINE", "STANDARD", and "DURABLE_REDUCED_AVAILABILITY".
-`numNewerVersions` | int64 | NumNewerVersions is the condition matching objects with a number of newer versions. If the value is N, this condition is satisfied when there are at least N versions (including the live version) newer than this version of the object.
-
-
-
-## LifecycleRule
-
-LifecycleRule is a lifecycle configuration rule. When all the configured conditions are met by an object in the bucket, the configured action will automatically be taken on that object.
-
-Appears in:
-
-* [Lifecycle](#Lifecycle)
-
-
-Name | Type | Description
------|------|------------
-`action` | [LifecycleAction](#LifecycleAction) | Action is the action to take when all of the associated conditions are met.
-`condition` | [LifecycleCondition](#LifecycleCondition) | Condition is the set of conditions that must be met for the associated action to be taken.
-
-
-
-## ProjectTeam
-
-ProjectTeam is the project team associated with the entity, if any.
-
-Appears in:
-
-* [ACLRule](#ACLRule)
-
-
-Name | Type | Description
------|------|------------
-`projectNumber` | string |
-`team` | string |
-
-
-
-## RetentionPolicy
-
-RetentionPolicy enforces a minimum retention time for all objects contained in the bucket. Any attempt to overwrite or delete objects younger than the retention period will result in an error. An unlocked retention policy can be modified or removed from the bucket via the Update method. A locked retention policy cannot be removed or shortened in duration for the lifetime of the bucket. This feature is in private alpha release. It is not currently available to most customers. It might be changed in backwards-incompatible ways and is not subject to any SLA or deprecation policy.
-
-Appears in:
-
-* [BucketUpdatableAttrs](#BucketUpdatableAttrs)
-
-
-Name | Type | Description
------|------|------------
-`retentionPeriodSeconds` | int | RetentionPeriod specifies the duration value in seconds that objects need to be retained. Retention duration must be greater than zero and less than 100 years. Note that enforcement of retention periods less than a day is not guaranteed. Such periods should only be used for testing purposes.
-
-
-
-## RetentionPolicyStatus
-
-RetentionPolicyStatus output component of storage.RetentionPolicy
-
-Appears in:
-
-* [BucketOutputAttrs](#BucketOutputAttrs)
-
-
-Name | Type | Description
------|------|------------
-`effectiveTime` | [meta/v1.Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#time-v1-meta) | EffectiveTime is the time from which the policy was enforced and effective.
-`isLocked` | bool | IsLocked describes whether the bucket is locked. Once locked, an object retention policy cannot be modified.
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-rook/database-rook-crossplane-io-v1alpha1.md b/docs/v0.4/api/crossplaneio/stack-rook/database-rook-crossplane-io-v1alpha1.md
deleted file mode 100644
index ba44f5ed..00000000
--- a/docs/v0.4/api/crossplaneio/stack-rook/database-rook-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,270 +0,0 @@
-# database.rook.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains database service resources for Rook
-
-This API group contains the following Crossplane resources:
-
-* [CockroachCluster](#CockroachCluster)
-* [CockroachClusterClass](#CockroachClusterClass)
-* [YugabyteCluster](#YugabyteCluster)
-* [YugabyteClusterClass](#YugabyteClusterClass)
-
-## CockroachCluster
-
-A CockroachCluster configures a Rook 'clusters.cockroachdb.rook.io'
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.rook.crossplane.io/v1alpha1`
-`kind` | string | `CockroachCluster`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [CockroachClusterSpec](#CockroachClusterSpec) | A CockroachClusterSpec defines the desired state of a CockroachCluster.
-`status` | [CockroachClusterStatus](#CockroachClusterStatus) | A CockroachClusterStatus defines the current state of a CockroachCluster.
-
-
-
-## CockroachClusterClass
-
-A CockroachClusterClass is a resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.rook.crossplane.io/v1alpha1`
-`kind` | string | `CockroachClusterClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [CockroachClusterClassSpecTemplate](#CockroachClusterClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned CockroachCluster.
-
-
-
-## YugabyteCluster
-
-A YugabyteCluster configures a Rook 'ybclusters.yugabytedb.rook.io'
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.rook.crossplane.io/v1alpha1`
-`kind` | string | `YugabyteCluster`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`spec` | [YugabyteClusterSpec](#YugabyteClusterSpec) | A YugabyteClusterSpec defines the desired state of a YugabyteCluster.
-`status` | [YugabyteClusterStatus](#YugabyteClusterStatus) | A YugabyteClusterStatus defines the current state of a YugabyteCluster.
-
-
-
-## YugabyteClusterClass
-
-A YugabyteClusterClass is a resource class. It defines the desired spec of resource claims that use it to dynamically provision a managed resource.
-
-
-Name | Type | Description
------|------|------------
-`apiVersion` | string | `database.rook.crossplane.io/v1alpha1`
-`kind` | string | `YugabyteClusterClass`
-`metadata` | [meta/v1.ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#objectmeta-v1-meta) | Kubernetes object metadata.
-`specTemplate` | [YugabyteClusterClassSpecTemplate](#YugabyteClusterClassSpecTemplate) | SpecTemplate is a template for the spec of a dynamically provisioned YugabyteCluster.
-
-
-
-## CockroachClusterClassSpecTemplate
-
-A CockroachClusterClassSpecTemplate is a template for the spec of a dynamically provisioned CockroachCluster.
-
-Appears in:
-
-* [CockroachClusterClass](#CockroachClusterClass)
-
-
-Name | Type | Description
------|------|------------
-`forProvider` | [CockroachClusterParameters](#CockroachClusterParameters) | A CockroachClusterParameters defines the desired state of a CockroachCluster.
-
-
-CockroachClusterClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-
-
-## CockroachClusterParameters
-
-A CockroachClusterParameters defines the desired state of a CockroachCluster.
-
-Appears in:
-
-* [CockroachClusterClassSpecTemplate](#CockroachClusterClassSpecTemplate)
-* [CockroachClusterSpec](#CockroachClusterSpec)
-
-
-Name | Type | Description
------|------|------------
-`name` | string |
-`namespace` | string |
-`annotations` | [v1alpha1.Annotations](../stack-rook/rook-crossplane-io-v1alpha1.md#annotations) | The annotations-related configuration to add/set on each Pod related object.
-`scope` | [v1alpha1.StorageScopeSpec](../stack-rook/rook-crossplane-io-v1alpha1.md#storagescopespec) |
-`network` | [NetworkSpec](#NetworkSpec) | NetworkSpec describes network related settings of the cluster
-`secure` | bool |
-`cachePercent` | int |
-`maxSQLMemoryPercent` | int |
-
-
-
-## CockroachClusterSpec
-
-A CockroachClusterSpec defines the desired state of a CockroachCluster.
-
-Appears in:
-
-* [CockroachCluster](#CockroachCluster)
-
-
-Name | Type | Description
------|------|------------
-`forProvider` | [CockroachClusterParameters](#CockroachClusterParameters) | A CockroachClusterParameters defines the desired state of a CockroachCluster.
-
-
-CockroachClusterSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## CockroachClusterStatus
-
-A CockroachClusterStatus defines the current state of a CockroachCluster.
-
-Appears in:
-
-* [CockroachCluster](#CockroachCluster)
-
-
-
-
-CockroachClusterStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-## NetworkSpec
-
-NetworkSpec describes network related settings of the cluster
-
-Appears in:
-
-* [CockroachClusterParameters](#CockroachClusterParameters)
-* [ServerSpec](#ServerSpec)
-
-
-Name | Type | Description
------|------|------------
-`ports` | [[]PortSpec](#PortSpec) | Set of named ports that can be configured for this resource
-
-
-
-## PortSpec
-
-PortSpec is named port
-
-Appears in:
-
-* [NetworkSpec](#NetworkSpec)
-
-
-Name | Type | Description
------|------|------------
-`name` | string | Name of port
-`port` | int32 | Port number
-
-
-
-## ServerSpec
-
-ServerSpec describes server related settings of the cluster
-
-Appears in:
-
-* [YugabyteClusterParameters](#YugabyteClusterParameters)
-
-
-Name | Type | Description
------|------|------------
-`replicas` | int32 |
-`network` | [NetworkSpec](#NetworkSpec) | NetworkSpec describes network related settings of the cluster
-`volumeClaimTemplate` | [core/v1.PersistentVolumeClaim](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#persistentvolumeclaim-v1-core) |
-
-
-
-## YugabyteClusterClassSpecTemplate
-
-A YugabyteClusterClassSpecTemplate is a template for the spec of a dynamically provisioned YugabyteCluster.
-
-Appears in:
-
-* [YugabyteClusterClass](#YugabyteClusterClass)
-
-
-Name | Type | Description
------|------|------------
-`forProvider` | [YugabyteClusterParameters](#YugabyteClusterParameters) | A YugabyteClusterParameters defines the desired state of a YugabyteCluster.
-
-
-YugabyteClusterClassSpecTemplate supports all fields of:
-
-* [v1alpha1.ClassSpecTemplate](../crossplane-runtime/core-crossplane-io-v1alpha1.md#classspectemplate)
-
-
-## YugabyteClusterParameters
-
-A YugabyteClusterParameters defines the desired state of a YugabyteCluster.
-
-Appears in:
-
-* [YugabyteClusterClassSpecTemplate](#YugabyteClusterClassSpecTemplate)
-* [YugabyteClusterSpec](#YugabyteClusterSpec)
-
-
-Name | Type | Description
------|------|------------
-`name` | string |
-`namespace` | string |
-`annotations` | [v1alpha1.Annotations](../stack-rook/rook-crossplane-io-v1alpha1.md#annotations) |
-`master` | [ServerSpec](#ServerSpec) | ServerSpec describes server related settings of the cluster
-`tserver` | [ServerSpec](#ServerSpec) | ServerSpec describes server related settings of the cluster
-
-
-
-## YugabyteClusterSpec
-
-A YugabyteClusterSpec defines the desired state of a YugabyteCluster.
-
-Appears in:
-
-* [YugabyteCluster](#YugabyteCluster)
-
-
-Name | Type | Description
------|------|------------
-`forProvider` | [YugabyteClusterParameters](#YugabyteClusterParameters) | A YugabyteClusterParameters defines the desired state of a YugabyteCluster.
-
-
-YugabyteClusterSpec supports all fields of:
-
-* [v1alpha1.ResourceSpec](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcespec)
-
-
-## YugabyteClusterStatus
-
-A YugabyteClusterStatus defines the current state of a YugabyteCluster.
-
-Appears in:
-
-* [YugabyteCluster](#YugabyteCluster)
-
-
-
-
-YugabyteClusterStatus supports all fields of:
-
-* [v1alpha1.ResourceStatus](../crossplane-runtime/core-crossplane-io-v1alpha1.md#resourcestatus)
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/api/crossplaneio/stack-rook/rook-crossplane-io-v1alpha1.md b/docs/v0.4/api/crossplaneio/stack-rook/rook-crossplane-io-v1alpha1.md
deleted file mode 100644
index 834ed8d5..00000000
--- a/docs/v0.4/api/crossplaneio/stack-rook/rook-crossplane-io-v1alpha1.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# rook.crossplane.io/v1alpha1 API Reference
-
-Package v1alpha1 contains database service resources for Rook
-
-This API group contains the following Crossplane resources:
-
-
-## Annotations
-
-Annotations are a Crossplane representation of Rook Annotations. Alias of map[string]string.
-
-
-## StorageScopeSpec
-
-StorageScopeSpec defines scope or boundaries of storage that the cluster will use for its underlying storage.
-
-
-Name | Type | Description
------|------|------------
-`nodeCount` | int |
-`volumeClaimTemplates` | [[]core/v1.PersistentVolumeClaim](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#persistentvolumeclaim-v1-core) | PersistentVolumeClaims to use as storage
-
-
-
-This API documentation was generated by `crossdocs`.
\ No newline at end of file
diff --git a/docs/v0.4/cloud-providers.md b/docs/v0.4/cloud-providers.md
deleted file mode 100644
index 5e3326ab..00000000
--- a/docs/v0.4/cloud-providers.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Configure Your Cloud Provider Account
-toc: true
-weight: 230
-indent: true
----
-
-# Configure Your Cloud Provider Account
-
-In order for Crossplane to be able to manage resources in a specific cloud
-provider, you will need to create an account for Crossplane to use. Use the
-links below for cloud-specific instructions to create an account that can be
-used throughout the guides:
-
-* [Google Cloud Platform (GCP) Service Account](cloud-providers/gcp/gcp-provider.md)
-* [Microsoft Azure Service Principal](cloud-providers/azure/azure-provider.md)
-* [Amazon Web Services (AWS) IAM User](cloud-providers/aws/aws-provider.md)
diff --git a/docs/v0.4/cloud-providers/aws/aws-provider.md b/docs/v0.4/cloud-providers/aws/aws-provider.md
deleted file mode 100644
index f3f2a400..00000000
--- a/docs/v0.4/cloud-providers/aws/aws-provider.md
+++ /dev/null
@@ -1,134 +0,0 @@
-
-# Adding Amazon Web Services (AWS) to Crossplane
-
-In this guide, we will walk through the steps necessary to configure your AWS account to be ready for integration with Crossplane. This will be done by adding a [`aw provider`] resource type, which enables Crossplane to communicate with an AWS account.
-
-## Requirements
-
-Prior to adding AWS to Crossplane, following steps need to be taken
-
-- Crossplane is installed in a k8s cluster
-- AWS Stack is installed in the same cluster
-- `kubectl` is configured to communicate with the same cluster
-
-## Step 1: Configure `aws` CLI
-
-Crossplane uses [AWS security credentials], and stores them as a [secret] which is managed by an [`aw provider`] instance. In addition, the AWS default region is also used for targeting a specific region.
-Crossplane requires to have [`aws` command line tool] [installed] and [configured]. Once installed, the credentials and configuration will reside in `~/.aws/credentials` and `~/.aws/config` respectively.
-
-## Step 2: Setup `aws` Provider
-
-Run [setup.sh] script to read `aws` credentials and region, and create an [`aw provider`] instance in Crossplane:
-
-```bash
-./cluster/examples/setup-aws-provider/setup.sh [--profile aws_profile]
-```
-
-The `--profile` switch is optional and specifies the [aws named profile] that was set in Step 1. If not provided, the `default` profile will be selected.
-
-Once the script is successfully executed, Crossplane will use the specified aws account and region in the given named profile to create subsequent AWS managed resources.
-
-You can confirm the existense of the [`aws provider`] by running:
-
-```bash
-kubectl -n crossplane-system get provider/aws-provider
-```
-
-## Optional: Setup AWS Provider Manually
-
-An AWS [user][aws user] with `Administrative` privileges is needed to enable
-Crossplane to create the required resources. Once the user is provisioned, an
-[Access Key][] needs to be created so the user can have API access.
-
-Using the set of [access key credentials][AWS security credentials] for the user
-with the right access, we need to [install][install-aws] [`aws cli`][aws command
-line tool], and then [configure][aws-cli-configure] it.
-
-When the AWS cli is configured, the credentials and configuration will be in
-`~/.aws/credentials` and `~/.aws/config` respectively. These will be consumed in
-the next step.
-
-When configuring the AWS cli, the user credentials could be configured under a
-specific [AWS named profile][], or under `default`. Without loss of generality,
-in this guide let's assume that the credentials are configured under the
-`aws_profile` profile (which could also be `default`). We'll use this profile to
-setup cloud provider in the next section.
-
-Crossplane uses the AWS user credentials that were configured in the previous
-step to create resources in AWS. These credentials will be stored as a
-[secret][kubernetes secret] in Kubernetes, and will be used by an [AWS
-provider][aws provider] instance. The default AWS region is also pulled from the
-cli configuration, and added to the AWS provider.
-
-To store the credentials as a secret, run:
-
-```bash
-# retrieve profile's credentials, save it under 'default' profile, and base64 encode it
-BASE64ENCODED_AWS_ACCOUNT_CREDS=$(echo -e "[default]\naws_access_key_id = $(aws configure get aws_access_key_id --profile $aws_profile)\naws_secret_access_key = $(aws configure get aws_secret_access_key --profile $aws_profile)" | base64 | tr -d "\n")
-# retrieve the profile's region from config
-AWS_REGION=$(aws configure get region --profile ${aws_profile})
-```
-
-At this point, the region and the encoded credentials are stored in respective
-variables. Next, we'll need to create an instance of AWS [provider][aws
-provider]:
-
-```bash
-cat > provider.yaml < crossplane-azure-provider-key.json
-```
-
-Take note of the `clientID` value from the JSON file that we just created, and save it to an environment variable:
-
-```console
-export AZURE_CLIENT_ID=
-```
-
-Now add the required permissions to the service principal that will allow it to manage the necessary resources in Azure:
-
-```console
-# add required Azure Active Directory permissions
-az ad app permission add --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --api-permissions 1cda74f2-2616-4834-b122-5cb1b07f8a59=Role 78c8a3c8-a07e-4b9e-af1b-b5ccab50a175=Role
-
-# grant (activate) the permissions
-az ad app permission grant --id ${AZURE_CLIENT_ID} --api 00000002-0000-0000-c000-000000000000 --expires never
-```
-
-You might see an error similar to the following, but that is OK, the permissions should have gone through still:
-
-```console
-Operation failed with status: 'Conflict'. Details: 409 Client Error: Conflict for url: https://graph.windows.net/e7985bc4-a3b3-4f37-b9d2-fa256023b1ae/oauth2PermissionGrants?api-version=1.6
-```
-
-After these steps are completed, you should have the following file on your local filesystem:
-
-* `crossplane-azure-provider-key.json`
-
-## Grant Consent to Application Permissions
-
-One more step is required to fully grant the permissions to the new service principal.
-From the Azure Portal, you need to grant consent for the permissions using an admin account.
-The steps to perform this action are listed below:
-
-1. `echo ${AZURE_CLIENT_ID}` and note this ID value
-1. Navigate to the Azure Portal: https://portal.azure.com
-1. Click `Azure Active Directory`, or find it in the `All services` list
-1. Click `App registrations (Preview)`
-1. Click on the application from the list where the application (client) ID matches the value from step 1
-1. Click `API permissions`
-1. Click `Grant admin consent for Default Directory`
-1. Click `Yes`
-
-## Setup Azure Provider
-
-Before creating any resources, we need to create and configure an Azure cloud
-provider resource in Crossplane, which stores the cloud account information in
-it. All the requests from Crossplane to Azure Cloud will use the credentials
-attached to this provider resource. The following command assumes that you have
-a `crossplane-azure-provider-key.json` file that belongs to the account you’d
-like Crossplane to use.
-
-```bash
-BASE64ENCODED_AZURE_ACCOUNT_CREDS=$(base64 crossplane-azure-provider-key.json | tr -d "\n")
-```
-
-Now we’ll create our `Secret` that contains the credential and `Provider`
-resource that refers to that secret:
-
-```bash
-cat > provider.yaml < provider.yaml <
-[services-user-guide]: services-guide.md
-[stack-user-guide]: stacks-guide.md
-[stack-registry]: https://hub.docker.com/search?q=crossplane&type=image
-[crossplane-cli-usage]: https://github.com/crossplaneio/crossplane-cli#usage
-[stack-install-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#installation-flow
-[stack-gcp]: https://github.com/crossplaneio/stack-gcp
-[stack-aws]: https://github.com/crossplaneio/stack-aws
-[stack-azure]: https://github.com/crossplaneio/stack-azure
-[stack-wordpress]: https://github.com/crossplaneio/sample-stack-wordpress
-[stack-wordpress-registry]: https://hub.docker.com/r/crossplane/sample-stack-wordpress
-[stack-manager]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#terminology
-[services-developer-guide]: services-developer-guide.md
-[stack-quick-start]: https://github.com/crossplaneio/crossplane-cli#quick-start-stacks
-[kubernetes-controller]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-controllers
-[join-crossplane-slack]: https://slack.crossplane.io
-[contact-us]: https://github.com/crossplaneio/crossplane#contact
-[learn-more]: learn-more.md
diff --git a/docs/v0.4/faqs.md b/docs/v0.4/faqs.md
deleted file mode 100644
index f4538258..00000000
--- a/docs/v0.4/faqs.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-title: FAQs
-toc: true
-weight: 840
-indent: true
----
-# Frequently Asked Questions (FAQs)
-
-### Where did the name Crossplane come from?
-
-Crossplane is the fusing of cross-cloud control plane. We wanted to use a noun that refers to the entity responsible for connecting different cloud providers and acts as control plane across them. Cross implies “cross-cloud” and “plane” brings in “control plane”.
-
-### What's up with popsicle?
-
-We believe in a multi-flavor cloud.
-
-### Why is Upbound open sourcing this project? What are Upbound’s monetization plans?
-
-Upbound’s mission is to create a more open cloud-computing platform, with more choice and less lock-in. We believe the Crossplane as an important step towards this vision and that it’s going to take a village to solve this problem. We believe that multicloud control plane is a new category of open source software, and it will ultimately disrupt closed source and proprietary models. Upbound aspires to be a commercial provider of a more open cloud-computing platform.
-
-### What kind of governance model will be used for Crossplane?
-
-Crossplane will be an independent project and we plan on making a community driven project and not a vendor driven project. It will have an independent brand, github organization, and an open governance model. It will not be tied to single organization or individual.
-
-### Will Crossplane be donated to an open source foundation?
-
-We don’t know yet. We are open to doing so but we’d like to revisit this after the project has gotten some end-user community traction.
-
-### Does using multicloud mean you will use the lowest common denominator across clouds?
-
-Not necessarily. There are numerous best of breed cloud offerings that run on multiple clouds. For example, CockroachDB and ElasticSearch are world class implementations of platform software and run well on cloud providers. They compete with managed services offered by a cloud provider. We believe that by having an open control plane for them to integrate with, and providing a common API, CLI and UI for all of these services, that more of these offerings will exist and get first-class experience in the cloud.
-
-### How are resources and claims related to PersistentVolumes in Kubernetes?
-
-We modeled resource claims and classes after PersistentVolumes and PersistentVolumeClaims in Kubernetes. We believe many of the lessons learned from managing volumes in Kubernetes apply to managing resources within cloud providers. One notable exception is that we avoided creating a plugin model within Crossplane.
-
-### How is workload scheduling related to pod scheduling in Kubernetes?
-
-We modeled workload scheduling after the Pod scheduler in Kubernetes. We believe many of the lessons learned from Pod scheduling apply to scheduling workloads across cloud providers.
-
-### Can I use Crossplane to consistently provision and manage multiple Kubernetes clusters?
-
-Crossplane includes a portable API for Kubernetes clusters that will include common configuration including node pools, auto-scalers, taints, admission controllers, etc. These will be applied to the specific implementations within the cloud providers like EKS, GKE and AKS. We see the Kubernetes Cluster API to be something that will be used by administrators and not developers.
-
-### Other attempts at building a higher level API on-top of a multitude of inconsistent lower level APIs have not been successful, will Crossplane not have the same issues?
-
-We agree that building a consistent higher level API on top of multitudes of inconsistent lower level API's is well known to be fraught with peril (e.g. dumbing down to lowest common denominator, or resulting in so loosely defined an API as to be impossible to practically develop real portable applications on top of it).
-
-Crossplane follows a different approach here. The portable API extracts the pieces that are common across all implementations, and from the perspective of the workload. The rest of the implementation details are captured in full fidelity by the admin in resource classes. The combination of the two is what results in full configuration that can be deployed. We believe this to be a reasonable tradeoff that avoids the dumbing down to lowest common denominator problem, while still enabling portability.
diff --git a/docs/v0.4/gitlab/gitlab-aws.md b/docs/v0.4/gitlab/gitlab-aws.md
deleted file mode 100644
index 6364f965..00000000
--- a/docs/v0.4/gitlab/gitlab-aws.md
+++ /dev/null
@@ -1,427 +0,0 @@
-# Deploying GitLab in AWS
-
-This user guide will walk you through GitLab application deployment using Crossplane managed resources and
-the official GitLab Helm chart.
-
-The following components are dynamically provisioned and configured during this guide:
-
-* An RDS Postgres database
-* A Redis cluster
-* A sample Gitlab application
-
-
-
-
-## Pre-requisites
-
-* Before starting this guide, you should have already [configured your AWS account](../../cloud-providers/aws/aws-provider.md) for use with Crossplane.
-* You should also have an AWS credentials file at `~/.aws/credentials` already on your local filesystem.
-* [Helm](https://docs.helm.sh/using_helm/), minimum version `v2.10.0+`.
-* [jq](https://stedolan.github.io/jq/) - commandline JSON processor `v1.5+`
-* [AWS cli](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)
-
-## Preparation
-
-### EKS Cluster
-Follow [GitLab instruction](https://docs.gitlab.com/charts/installation/cloud/eks.html#scripted-cluster-creation) to create and bootstrap EKS Kubernetes cluster
-
-### Crossplane
-
-Using the newly provisioned cluster:
-
-- Install Crossplane from master channel using the [Crossplane Installation Guide](../install-crossplane.md#master)
-- Install the AWS stack into Crossplane using the [AWS stack section](../install-crossplane.md#aws-stack) of the install guide.
-- Obtain [Cloud Provider Credentials](../cloud-providers.md)
-
-#### Region
-- Export the region of the EKS cluster you're provisioned for this demo
-```
-export REGION=region-of-eks-west-1
-```
-
-#### EKS kubeconfig
-- Obtain EKS Cluster credentials and set as your current context
-```bash
-aws eks --region $REGION update-kubeconfig --name [your-CLUSTER_NAME]
-```
-
-#### AWS provider
-
-Create provider:
-```console
-sed -e "s|REGION|$REGION|g;s|BASE64ENCODED_AWS_PROVIDER_CREDS|`base64 ~/.aws/credentials | tr -d '\n'`|g;" cluster/examples/gitlab/aws/provider.yaml | kubectl create -f -
-```
-
-- Verify AWS provider was successfully registered by the crossplane
- ```bash
- kubectl get providers.aws.crossplane.io -n crossplane-system
- kubectl get secrets -n crossplane-system
- ```
-
- - You should see output similar to:
-
- ```bash
- NAME PROJECT-ID AGE
- demo-aws your-project-123456 11m
- NAME TYPE DATA AGE
- default-token-974db kubernetes.io/service-account-token 3 2d16h
- demo-aws-creds Opaque 1 103s
- ```
-
-#### Create an RDS subnet group
-1. Navigate to the aws console in same region as the EKS cluster
-1. Navigate to `RDS` service
-1. Navigate to `Subnet groups` in left hand pane
-1. Click `Create DB Subnet Group`
-1. Name your subnet i.e. `eks-db-subnets`
-1. Select the VPC created in the EKS VPC step
-1. Click `Add all subnets related to this VPC`
-1. Click Create
-1. Export the db subnet group name
- ```console
- export RDS_SUBNET_GROUP_NAME=replace-with-DBSubnetgroup-name
- ```
-#### Create an RDS/Redis Security Group (example only)
-
-> Note: This will make your RDS and Redis instance visible from anywhere on the internet.
-This is for **EXAMPLE PURPOSES ONLY** and is **NOT RECOMMENDED** for production system.
-
-1. Navigate to ec2 in the same region as the EKS cluster
-1. Click: security groups
-1. Click `Create Security Group`
-1. Name it, ex. `bad-idea-public-visibility`
-1. Give it a description
-1. Select the same VPC as the EKS cluster.
-1. On the Inbound Rules tab, choose `Add Rule`.
- - For Type, choose `Custom TCP Rule`
- - For Port Range, type `6379`
- - For Source, choose `Anywhere` from drop down or type: `0.0.0.0/0`
- - Click `Add Rule` again
- - For Type, choose `PostgreSQL`
- - For Source, choose `Anywhere` from drop down or type: `0.0.0.0/0`
-1. Choose Add another rule if you need to add more IP addresses or different port ranges.
-1. Click: Create
-1. Export the security group id
- ```console
- export REDIS_SECURITY_GROUP=replace-with-security-group-id
- export RDS_SECURITY_GROUP=replace-with-security-group-id
- ```
-
-#### Create an Elasticache Subnet Group
-1. Navigate to the aws console in same region as the EKS cluster
-1. Navigate to `Elasticache` service
-1. Navigate to `Subnet groups` in left hand pane
-1. Click `Create Subnet Group`
-1. Name your subnet i.e. `redis-subnets`
-1. Select the VPC created in the EKS VPC step
-1. Click `Add all subnets related to this VPC`
-1. Click Create
-1. Export the db subnet group name
-
-```console
-export REDIS_SUBNET_GROUP=replace-me-with-redis-subnet-group
-```
-
-
-#### Resource Classes
-Create Crossplane Resource Class needed to provision managed resources for GitLab applications
-
-```bash
-sed -e "s|REDIS_SECURITY_GROUP|$REDIS_SECURITY_GROUP|g;s|REDIS_SUBNET_GROUP|$REDIS_SUBNET_GROUP|g;s|REGION|$REGION|g;s|RDS_SUBNET_GROUP_NAME|$RDS_SUBNET_GROUP_NAME|g;s|RDS_SECURITY_GROUP|$RDS_SECURITY_GROUP|g" cluster/examples/gitlab/aws/resource-classes/* | kubectl create -f -
-```
-
-```
-resourceclass.core.crossplane.io/standard-aws-bucket created
-resourceclass.core.crossplane.io/standard-aws-postgres created
-resourceclass.core.crossplane.io/standard-aws-redis created
-```
-
-Verify
-
-```bash
-kubectl get resourceclasses -n crossplane-system
-```
-
-```
-NAME PROVISIONER PROVIDER-REF RECLAIM-POLICY AGE
-standard-aws-bucket s3buckets.storage.aws.crossplane.io/v1alpha1 demo-aws Delete 17s
-standard-aws-postgres rdsinstance.database.aws.crossplane.io/v1alpha1 demo-aws Delete 17s
-standard-aws-redis replicationgroup.cache.aws.crossplane.io/v1alpha1 demo-aws Delete 17s
-```
-
-#### Resource Claims
-Provision Managed Resources required by GitLab application using Crossplane Resource Claims.
-
-Note: you can use a separate command for each claim file, or create all claims in one command, like so:
-
-```bash
-kubectl create -Rf cluster/examples/gitlab/aws/resource-claims/
-```
-```
-postgresqlinstance.database.crossplane.io/gitlab-postgresql created
-rediscluster.cache.crossplane.io/gitlab-redis created
-bucket.storage.crossplane.io/gitlab-artifacts created
-bucket.storage.crossplane.io/gitlab-backups-tmp created
-bucket.storage.crossplane.io/gitlab-backups created
-bucket.storage.crossplane.io/gitlab-externaldiffs created
-bucket.storage.crossplane.io/gitlab-lfs created
-bucket.storage.crossplane.io/gitlab-packages created
-bucket.storage.crossplane.io/gitlab-pseudonymizer created
-bucket.storage.crossplane.io/gitlab-registry created
-bucket.storage.crossplane.io/gitlab-uploads created
-```
-
-Verify that the resource claims were successfully provisioned.
-```bash
-kubectl get -f cluster/examples/gitlab/aws/resource-claims/postgres.yaml
-kubectl get -f cluster/examples/gitlab/aws/resource-claims/redis.yaml
-```
-
-```
-NAME STATUS CLASS VERSION AGE
-gitlab-postgresql Bound standard-aws-postgres 9.6 5m27s
----
-NAME STATUS CLASS VERSION AGE
-gitlab-redis Bound standard-aws-redis 3.2 7m10s
-```
-
-```bash
-# check all bucket claims
-kubectl get -f cluster/examples/gitlab/aws/resource-claims/buckets/
-```
-```text
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-artifacts Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-backups-tmp Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-backups Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-externaldiffs Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-lfs Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-packages Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-pseudonymizer Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-registry Bound standard-aws-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-uploads Bound standard-aws-bucket 4m49s
-```
-
-What we are looking for is for `STATUS` value to become `Bound` which indicates the managed resource was successfully provisioned and is ready for consumption
-
-##### Resource Claims Connection Secrets
-Verify that every resource has created a connection secret
-```bash
-kubectl get secrets -n default
-```
-```
-NAME TYPE DATA AGE
-default-token-mzsgg kubernetes.io/service-account-token 3 5h42m
-gitlab-artifacts Opaque 4 6m41s
-gitlab-backups Opaque 4 7m6s
-gitlab-backups-tmp Opaque 4 7m7s
-gitlab-externaldiffs Opaque 4 7m5s
-gitlab-lfs Opaque 4 7m4s
-gitlab-packages Opaque 4 2m28s
-gitlab-postgresql Opaque 3 30m
-gitlab-pseudonymizer Opaque 4 7m2s
-gitlab-redis Opaque 1 28m
-gitlab-registry Opaque 4 7m1s
-gitlab-uploads Opaque 4 7m1s
-```
-
-Note: Kubernetes cluster claim is created in "privileged" mode; thus the kubernetes cluster resource secret is located in `crossplane-system` namespace, however, you will not need to use this secret for our GitLab demo deployment.
-
-At this point, all GitLab managed resources should be ready to consume and this completes the Crossplane resource provisioning phase.
-
-#### Managed Resource Secrets
-
-##### Convert Secrets and Export Valuess
-GitLab requires to provide connection information in the specific format per cloud provider.
-In addition, we need to extract endpoints and additional managed resource properties and add them to helm values.
-
-There is an [ongoing effort](https://github.com/crossplaneio/crossplane/issues/489) to improve secret consumption from GitLab such that secrets produced by Crossplane controllers are directly consumed without transformation.
-
-We will use a convenience script for this purpose.
-Note: your output may be different
-```bash
-./cluster/examples/gitlab/aws/secrets.sh
-```
-```
-Current cluster kubectl context: eks_you-project-123456_us-central1-a_eks-a2345dfb1-asdf-11e9-ac37-9cb6d08bde99
----
-Source cluster secrets:
-NAME TYPE DATA AGE
-default-token-mzsgg kubernetes.io/service-account-token 3 2d7h
-gitlab-artifacts Opaque 4 34h
-gitlab-backups Opaque 4 34h
-gitlab-backups-tmp Opaque 4 34h
-gitlab-externaldiffs Opaque 4 34h
-gitlab-lfs Opaque 4 34h
-gitlab-packages Opaque 4 34h
-gitlab-postgresql Opaque 3 2d2h
-gitlab-pseudonymizer Opaque 4 34h
-gitlab-redis Opaque 1 2d2h
-gitlab-registry Opaque 4 34h
-gitlab-uploads Opaque 4 34h
----
-Generate PostgreSQL secret and values file
-secret/gitlab-postgresql created
----
-Generate Redis values file
----
-Generate Buckets secrets
-secret/bucket-artifacts created
-secret/bucket-backups-tmp created
-secret/bucket-backups created
-secret/bucket-externaldiffs created
-secret/bucket-lfs created
-secret/bucket-packages created
-secret/bucket-pseudonymizer created
-secret/bucket-registry created
-secret/bucket-uploads created
-
-```
-
-## Install
-Render the official GitLab Helm chart with the generated values files, and your settings into a `gitlab-aws.yaml` file.
-See [GitLab Helm Documentation](https://docs.gitlab.com/charts/installation/deployment.html) for the additional details
-
-```bash
-helm repo add gitlab https://charts.gitlab.io/
-helm repo update
-helm fetch gitlab/gitlab --version v1.7.1
-helm template gitlab-1.7.1.tgz --name gitlab-demo --namespace default \
- -f cluster/examples/gitlab/aws/values-buckets.yaml \
- -f cluster/examples/gitlab/aws/values-redis.yaml \
- -f cluster/examples/gitlab/aws/values-psql.yaml \
- --set global.hosts.domain=[your.domain] \
- --set global.hosts.hostSuffix=demo \
- --set certmanager-issuer.email=email@account.io > gitlab-aws.yaml
-```
-
-Examine `gitlab-aws.yaml` to familiarize yourself with all GitLab components.
-
-Install GitLab
-Note: your output may look different:
-```bash
-kubectl create -f gitlab-aws.yaml
-```
-
-Validate GitLab components:
-
-```bash
-kubectl get jobs,deployments,statefulsets
-```
-
-It usually takes few minutes for all GitLab components to get initialized and be ready.
-
-Note: During the initialization "wait", some pods could automatically restart, but this should stabilize once all the
-dependent components become available.
-
-Note: There also could be intermittent `ImagePullBackOff`, but those, similar to above should clear up by themselves.
-
-Note: It appears the `gitlab-demo-unicorn-test-runner-*` (job/pod) will Error and will not re-run, unless the pod is resubmitted.
-
-After few minutes your output for:
-```bash
-kubectl get pod
-```
-Should look similar to:
-```bash
-NAME READY STATUS RESTARTS AGE
-gitlab-demo-certmanager-59f887dc9-jppl7 1/1 Running 0 9m
-gitlab-demo-gitaly-0 1/1 Running 0 9m
-gitlab-demo-gitlab-runner-fcc9cc7cf-c7pzz 0/1 Init:0/1 0 9m
-gitlab-demo-gitlab-shell-57b887755c-kqm89 1/1 Running 0 8m
-gitlab-demo-gitlab-shell-57b887755c-vzqkf 1/1 Running 0 9m
-gitlab-demo-issuer.0-ddzwp 0/1 Completed 0 9m
-gitlab-demo-migrations.0-2h5px 1/1 Running 2 9m
-gitlab-demo-nginx-ingress-controller-7bf4f7574d-cznfl 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-controller-7bf4f7574d-f5wjz 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-controller-7bf4f7574d-mxqpz 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-default-backend-5886cb59c7-bjnrt 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-default-backend-5886cb59c7-gchhp 1/1 Running 0 9m
-gitlab-demo-prometheus-server-64897864cf-p4sd7 2/2 Running 0 9m
-gitlab-demo-registry-746bbb488f-xjlhp 1/1 Running 0 8m
-gitlab-demo-registry-746bbb488f-xxpcr 1/1 Running 0 9m
-gitlab-demo-shared-secrets.0-mr7-2v5cf 0/1 Completed 0 9m
-gitlab-demo-sidekiq-all-in-1-5dd8b5b9d-58p72 1/1 Running 0 9m
-gitlab-demo-task-runner-7c477b48dc-d5nf6 1/1 Running 0 9m
-gitlab-demo-unicorn-6dd757db97-4vqgc 1/2 ImagePullBackOff 0 9m
-gitlab-demo-unicorn-6dd757db97-nmglt 2/2 Running 0 8m
-gitlab-demo-unicorn-test-runner-f2ttk 0/1 Error 0 9m
-```
-
-Note: if `ImagePullBackOff` error Pod does not get auto-cleared, consider deleting the pod.
-A new pod should come up with "Running" STATUS.
-
-## Use
-Retrieve the DNS name using GitLab ingress componenet:
-```bash
-kubectl get ingress
-```
-You should see following ingress configurations:
-```
-NAME HOSTS ADDRESS PORTS AGE
-gitlab-demo-registry registry-demo.upbound.app 35.222.163.203 80, 443 14m
-gitlab-demo-unicorn gitlab-demo.upbound.app 35.222.163.203 80, 443 14m
-```
-
-Navigate your browser to https://gitlab-demo.[your-domain], and if everything ran successfully, you should see:
-
-
-
-## Uninstall
-
-### GitLab
-To remove the GitLab application: run:
-```bash
-kubectl delete -f gitlab-aws.yaml
-```
-
-### Crossplane
-
-Delete all managed resources by running:
-```bash
-kubectl delete -Rf cluster/examples/gitlab/aws/resource-claims
-```
-```
-bucket.storage.crossplane.io "gitlab-artifacts" deleted
-bucket.storage.crossplane.io "gitlab-backups-tmp" deleted
-bucket.storage.crossplane.io "gitlab-backups" deleted
-bucket.storage.crossplane.io "gitlab-externaldiffs" deleted
-bucket.storage.crossplane.io "gitlab-lfs" deleted
-bucket.storage.crossplane.io "gitlab-packages" deleted
-bucket.storage.crossplane.io "gitlab-pseudonymizer" deleted
-bucket.storage.crossplane.io "gitlab-registry" deleted
-bucket.storage.crossplane.io "gitlab-uploads" deleted
-postgresqlinstance.database.crossplane.io "gitlab-postgresql" deleted
-rediscluster.cache.crossplane.io "gitlab-redis" deleted
-```
-
-Verify that all resource claims have been removed:
-```bash
-kubectl get -Rf cluster/examples/gitlab/aws/resource-claims
-```
-Note: typically it may take few seconds for Crossplane to process the request.
-By running resource and provider removal in the same command or back-to-back, we are running the risk of having orphaned resource.
-I.E., a resource that could not be cleaned up because the provider is no longer available.
-
-Delete all resource classes:
-```bash
-kubectl delete -Rf cluster/examples/gitlab/aws/resource-classes/
-```
-```
-resourceclass.core.crossplane.io "standard-aws-bucket" deleted
-resourceclass.core.crossplane.io "standard-aws-postgres" deleted
-resourceclass.core.crossplane.io "standard-aws-redis" deleted
-```
-
-Delete aws-provider and secrets
-```bash
-kubectl delete -f cluster/examples/gitlab/aws/provider.yaml
-```
diff --git a/docs/v0.4/gitlab/gitlab-gcp.md b/docs/v0.4/gitlab/gitlab-gcp.md
deleted file mode 100644
index 0f3ba3c8..00000000
--- a/docs/v0.4/gitlab/gitlab-gcp.md
+++ /dev/null
@@ -1,402 +0,0 @@
-# Deploying GitLab in GCP
-
-This user guide will walk you through GitLab application deployment using Crossplane managed resources and
-the official GitLab Helm chart.
-
-## Pre-requisites
-
-* [Helm](https://docs.helm.sh/using_helm/), minimum version `v2.10.0+`.
-* [jq](https://stedolan.github.io/jq/) - commandline JSON processor `v1.5+`
-
-
-## Preparation
-
-### GKE Cluster
-Follow [GitLab instruction](https://docs.gitlab.com/charts/installation/cloud/gke.html#scripted-cluster-creation) to create and bootstrap GKE Kubernetes cluster
-
-- Obtain GKE cluster credentials
-```bash
-gcloud container clusters get-credentials [your-gke-cluster] --zone [your-cluster-zone] --project [your-gcp-project]
-```
-
-- Configure `kubectl` current context to point to your GKE cluster where you want to deploy GitLab application.
-
-Note: this step is optional since: `gcloud container clusters get-credentials` will automatically set the current context to newly connected cluster
-```bash
-kubectl config get-contexts
-kubectl config set-context [your-cluster-context]
-```
-
-### Crossplane
-
-Using the newly provisioned cluster:
-
-- Install Crossplane from master channel using the [Crossplane Installation Guide](../install-crossplane.md#master)
-- Install the GCP stack into Crossplane using the [GCP stack section](../install-crossplane.md#gcp-stack) of the install guide.
-- Obtain [Cloud Provider Credentials](../cloud-providers.md)
-
-#### GCP Provider
-It is essential to make sure that the GCP Service Account used by the Crossplane GCP Provider has the following Roles:
-
- Cloud SQL Admin
- Kubernetes Engine Admin
- Service Account User
- Cloud Memorystore Redis Admin
- Storage Admin
-
-Using GCP Service Account `gcp-credentials.json`:
-- Generate BASE64ENCODED_GCP_PROVIDER_CREDS encoded value:
-```bash
-base64 gcp-credentials.json | tr -d "\n"
-```
-
-- Update [provider.yaml](../../cluster/examples/gitlab/gcp/provider.yaml) replacing `BASE64ENCODED_GCP_PROVIDER_CREDS`
-- Update [provider.yaml](../../cluster/examples/gitlab/gcp/provider.yaml) replacing `PROJECT_ID` with `project_id` from the credentials.json
-
-#### GCS
-It is recommended to create a separate GCP Service Account dedicated to storage operations only, i.e. with a reduced IAM role set, for example: `StorageAdmin` only.
-
-Follow the same step as for GCP credentials to create and obtain `gcs-credentials.json`
-- Generate BASE64ENCODED_GCS_PROVIDER_CREDS encoded value:
-```bash
-base64 gcs-credentials.json | tr -d "\n"
-```
-
-Otherwise, you can use `BASE64ENCODED_GCP_PROVIDER_CREDS` in place of `BASE64ENCODED_GCS_PROVIDER_CREDS`
-
-- Update [provider.yaml](../../cluster/examples/gitlab/gcp/provider.yaml) replacing `BASE64ENCODED_GCS_PROVIDER_CREDS`
-
-##### GCS Interoperability
-- Navigate to: https://console.cloud.google.com/storage/settings in your GCP project
-- Click on `Interoperability` Tab
-- Using `Interoperable storage access keys` generate `BASE64ENCODED` values
- - `BASE64ENCODED_GCS_INTEROP_ACCESS_KEY`
- - `BASE64ENCODED_GCS_INTEROP_SECRET`
-- Update [provider.yaml](../../cluster/examples/gitlab/gcp/provider.yaml) replacing:
- - `BASE64ENCODED_GCS_INTEROP_ACCESS_KEY`
- - `BASE64ENCODED_GCS_INTEROP_SECRET`
-
-#### Create
-- Create GCP provider:
- ```bash
- kubectl create -f cluster/examples/gitlab/gcp/provider.yaml
- ```
-- Verify GCP provider was successfully registered by the crossplane
- ```bash
- kubectl get providers.gcp.crossplane.io -n crossplane-system
- kubectl get secrets -n crossplane-system
- ```
-
- - You should see output similar to:
-
- ```bash
- NAME PROJECT-ID AGE
- demo-gcp your-project-123456 11m
- NAME TYPE DATA AGE
- default-token-974db kubernetes.io/service-account-token 3 2d16h
- demo-gcp-creds Opaque 1 103s
- demo-gcs-creds Opaque 3 2d11h
- ```
-
-#### Resource Classes
-Create Crossplane Resource Class needed to provision managed resources for GitLab applications
-
-```bash
-kubectl create -f cluster/examples/gitlab/gcp/resource-classes/
-```
-```
-resourceclass.core.crossplane.io/standard-gcp-bucket created
-resourceclass.core.crossplane.io/standard-gcp-cluster created
-resourceclass.core.crossplane.io/standard-gcp-postgres created
-resourceclass.core.crossplane.io/standard-gcp-redis created
-```
-
-Verify
-```bash
-kubectl get resourceclasses -n crossplane-system
-```
-```
-NAME PROVISIONER PROVIDER-REF RECLAIM-POLICY AGE
-standard-gcp-bucket bucket.storage.gcp.crossplane.io/v1alpha1 demo-gcp Delete 17s
-standard-gcp-cluster gkecluster.compute.gcp.crossplane.io/v1alpha1 demo-gcp Delete 17s
-standard-gcp-postgres cloudsqlinstance.database.gcp.crossplane.io/v1alpha1 demo-gcp Delete 17s
-standard-gcp-redis cloudmemorystoreinstance.cache.gcp.crossplane.io/v1alpha1 demo-gcp Delete 17s
-```
-
-#### Resource Claims
-Provision Managed Resources required by GitLab application using Crossplane Resource Claims.
-
-Note: you can use a separate command for each claim file, or create all claims in one command, like so:
-
-```bash
-kubectl create -Rf cluster/examples/gitlab/gcp/resource-claims/
-```
-```
-bucket.storage.crossplane.io/gitlab-artifacts created
-bucket.storage.crossplane.io/gitlab-backups-tmp created
-bucket.storage.crossplane.io/gitlab-backups created
-bucket.storage.crossplane.io/gitlab-externaldiffs created
-bucket.storage.crossplane.io/gitlab-lfs created
-bucket.storage.crossplane.io/gitlab-packages created
-bucket.storage.crossplane.io/gitlab-pseudonymizer created
-bucket.storage.crossplane.io/gitlab-registry created
-bucket.storage.crossplane.io/gitlab-uploads created
-postgresqlinstance.database.crossplane.io/gitlab-postgresql created
-rediscluster.cache.crossplane.io/gitlab-redis created
-```
-
-Verify that the resource claims were successfully provisioned.
-```bash
-kubectl get -f cluster/examples/gitlab/gcp/resource-claims/postgres.yaml
-kubectl get -f cluster/examples/gitlab/gcp/resource-claims/redis.yaml
-```
-
-```
-NAME STATUS CLUSTER-CLASS CLUSTER-REF AGE
-gitlab-gke Bound standard-gcp-cluster gke-af012df6-6e2a-11e9-ac37-9cb6d08bde99 4m7s
----
-NAME STATUS CLASS VERSION AGE
-gitlab-postgresql Bound standard-gcp-postgres 9.6 5m27s
----
-NAME STATUS CLASS VERSION AGE
-gitlab-redis Bound standard-gcp-redis 3.2 7m10s
-```
-
-```bash
-# check all bucket claims
-kubectl get -f cluster/examples/gitlab/gcp/resource-claims/buckets/
-```
-```text
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-artifacts Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-backups-tmp Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-backups Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-externaldiffs Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-lfs Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-packages Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-pseudonymizer Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-registry Bound standard-gcp-bucket 4m49s
-NAME STATUS CLASS PREDEFINED-ACL LOCAL-PERMISSION AGE
-gitlab-uploads Bound standard-gcp-bucket 4m49s
-```
-
-What we are looking for is for `STATUS` value to become `Bound` which indicates the managed resource was successfully provisioned and is ready for consumption
-
-##### Resource Claims Connection Secrets
-Verify that every resource has created a connection secret
-```bash
-kubectl get secrets -n default
-```
-```
-NAME TYPE DATA AGE
-default-token-mzsgg kubernetes.io/service-account-token 3 5h42m
-gitlab-artifacts Opaque 4 6m41s
-gitlab-backups Opaque 4 7m6s
-gitlab-backups-tmp Opaque 4 7m7s
-gitlab-externaldiffs Opaque 4 7m5s
-gitlab-lfs Opaque 4 7m4s
-gitlab-packages Opaque 4 2m28s
-gitlab-postgresql Opaque 3 30m
-gitlab-pseudonymizer Opaque 4 7m2s
-gitlab-redis Opaque 1 28m
-gitlab-registry Opaque 4 7m1s
-gitlab-uploads Opaque 4 7m1s
-```
-
-At this point, all GitLab managed resources should be ready to consume and this completes the Crossplane resource provisioning phase.
-
-#### Managed Resource Secrets
-
-##### Convert Secrets and Export Values
-GitLab requires to provide connection information in the specific format per cloud provider.
-In addition, we need to extract endpoints and additional managed resource properties and add them to helm values.
-
-There is an [ongoing effort](https://github.com/crossplaneio/crossplane/issues/489) to improve secret consumption from GitLab such that secrets produced by Crossplane controllers are directly consumed without transformation.
-
-We will use a convenience script for this purpose.
-Note: your output may be different
-```bash
-./cluster/examples/gitlab/gcp/secrets.sh
-```
-```
-Current cluster kubectl context: gke_you-project-123456_us-central1-a_gke-a2345dfb1-asdf-11e9-ac37-9cb6d08bde99
----
-Source cluster secrets:
-NAME TYPE DATA AGE
-default-token-mzsgg kubernetes.io/service-account-token 3 2d7h
-gitlab-artifacts Opaque 4 34h
-gitlab-backups Opaque 4 34h
-gitlab-backups-tmp Opaque 4 34h
-gitlab-externaldiffs Opaque 4 34h
-gitlab-lfs Opaque 4 34h
-gitlab-packages Opaque 4 34h
-gitlab-postgresql Opaque 3 2d2h
-gitlab-pseudonymizer Opaque 4 34h
-gitlab-redis Opaque 1 2d2h
-gitlab-registry Opaque 4 34h
-gitlab-uploads Opaque 4 34h
----
-Generate PostgreSQL secret and values file
-secret/gitlab-postgresql created
----
-Generate Redis values file
----
-Generate Buckets secrets
-secret/bucket-artifacts created
-secret/bucket-backups-tmp created
-secret/bucket-backups created
-secret/bucket-externaldiffs created
-secret/bucket-lfs created
-secret/bucket-packages created
-secret/bucket-pseudonymizer created
-secret/bucket-registry created
-secret/bucket-uploads created
-
-```
-
-## Install
-Render the official GitLab Helm chart with the generated values files, and your settings into a `gitlab-gcp.yaml` file.
-See [GitLab Helm Documentation](https://docs.gitlab.com/charts/installation/deployment.html) for the additional details
-
-```bash
-helm repo add gitlab https://charts.gitlab.io/
-helm repo update
-helm fetch gitlab/gitlab --version v1.7.1
-helm template gitlab-1.7.1.tgz --name gitlab-demo --namespace default \
- -f cluster/examples/gitlab/gcp/values-buckets.yaml \
- -f cluster/examples/gitlab/gcp/values-redis.yaml \
- -f cluster/examples/gitlab/gcp/values-psql.yaml \
- --set global.hosts.domain=your.domain \
- --set global.hosts.hostSuffix=demo \
- --set certmanager-issuer.email=email@account.io > gitlab-gcp.yaml
-```
-
-Examine `gitlab-gcp.yaml` to familiarize yourself with all GitLab components.
-
-Install GitLab
-Note: your output may look different:
-```bash
-kubectl create -f gitlab-gcp.yaml
-```
-
-Validate GitLab components:
-
-```bash
-kubectl get jobs,deployments,statefulsets
-```
-
-It usually takes few minutes for all GitLab components to get initialized and be ready.
-
-Note: During the initialization "wait", some pods could automatically restart, but this should stabilize once all the
-dependent components become available.
-
-Note: There also could be intermittent `ImagePullBackOff`, but those, similar to above should clear up by themselves.
-
-Note: It appears the `gitlab-demo-unicorn-test-runner-*` (job/pod) will Error and will not re-run, unless the pod is resubmitted.
-
-After few minutes your output for:
-```bash
-kubectl get pod
-```
-Should look similar to:
-```bash
-NAME READY STATUS RESTARTS AGE
-gitlab-demo-certmanager-59f887dc9-jppl7 1/1 Running 0 9m
-gitlab-demo-gitaly-0 1/1 Running 0 9m
-gitlab-demo-gitlab-runner-fcc9cc7cf-c7pzz 0/1 Init:0/1 0 9m
-gitlab-demo-gitlab-shell-57b887755c-kqm89 1/1 Running 0 8m
-gitlab-demo-gitlab-shell-57b887755c-vzqkf 1/1 Running 0 9m
-gitlab-demo-issuer.0-ddzwp 0/1 Completed 0 9m
-gitlab-demo-migrations.0-2h5px 1/1 Running 2 9m
-gitlab-demo-nginx-ingress-controller-7bf4f7574d-cznfl 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-controller-7bf4f7574d-f5wjz 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-controller-7bf4f7574d-mxqpz 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-default-backend-5886cb59c7-bjnrt 1/1 Running 0 9m
-gitlab-demo-nginx-ingress-default-backend-5886cb59c7-gchhp 1/1 Running 0 9m
-gitlab-demo-prometheus-server-64897864cf-p4sd7 2/2 Running 0 9m
-gitlab-demo-registry-746bbb488f-xjlhp 1/1 Running 0 8m
-gitlab-demo-registry-746bbb488f-xxpcr 1/1 Running 0 9m
-gitlab-demo-shared-secrets.0-mr7-2v5cf 0/1 Completed 0 9m
-gitlab-demo-sidekiq-all-in-1-5dd8b5b9d-58p72 1/1 Running 0 9m
-gitlab-demo-task-runner-7c477b48dc-d5nf6 1/1 Running 0 9m
-gitlab-demo-unicorn-6dd757db97-4vqgc 1/2 ImagePullBackOff 0 9m
-gitlab-demo-unicorn-6dd757db97-nmglt 2/2 Running 0 8m
-gitlab-demo-unicorn-test-runner-f2ttk 0/1 Error 0 9m
-```
-
-Note: if `ImagePullBackOff` error Pod does not get auto-cleared, consider deleting the pod.
-A new pod should come up with "Running" STATUS.
-
-## Use
-Retrieve the DNS name using GitLab ingress componenet:
-```bash
-kubectl get ingress
-```
-You should see following ingress configurations:
-```
-NAME HOSTS ADDRESS PORTS AGE
-gitlab-demo-registry registry-demo.upbound.app 35.222.163.203 80, 443 14m
-gitlab-demo-unicorn gitlab-demo.upbound.app 35.222.163.203 80, 443 14m
-```
-
-Navigate your browser to https://gitlab-demo.upbound.app, and if everything ran successfully, you should see:
-
-
-
-## Uninstall
-
-### GitLab
-To remove the GitLab application run:
-```bash
-kubectl delete -f gitlab-gcp.yaml
-```
-
-### Crossplane
-
-Delete all managed resources by running:
-```bash
-kubectl delete -Rf cluster/examples/gitlab/gcp/resource-claims
-```
-```
-bucket.storage.crossplane.io "gitlab-artifacts" deleted
-bucket.storage.crossplane.io "gitlab-backups-tmp" deleted
-bucket.storage.crossplane.io "gitlab-backups" deleted
-bucket.storage.crossplane.io "gitlab-externaldiffs" deleted
-bucket.storage.crossplane.io "gitlab-lfs" deleted
-bucket.storage.crossplane.io "gitlab-packages" deleted
-bucket.storage.crossplane.io "gitlab-pseudonymizer" deleted
-bucket.storage.crossplane.io "gitlab-registry" deleted
-bucket.storage.crossplane.io "gitlab-uploads" deleted
-postgresqlinstance.database.crossplane.io "gitlab-postgresql" deleted
-rediscluster.cache.crossplane.io "gitlab-redis" deleted
-```
-
-Verify that all resource claims have been removed:
-```bash
-kubectl get -Rf cluster/examples/gitlab/gcp/resource-claims
-```
-Note: typically it may take few seconds for Crossplane to process the request.
-By running resource and provider removal in the same command or back-to-back, we are running the risk of having orphaned resource.
-I.E., a resource that could not be cleaned up because the provider is no longer available.
-
-Delete all resource classes:
-```bash
-kubectl delete -Rf cluster/examples/gitlab/gcp/resource-classes/
-```
-```
-resourceclass.core.crossplane.io "standard-gcp-bucket" deleted
-resourceclass.core.crossplane.io "standard-gcp-postgres" deleted
-resourceclass.core.crossplane.io "standard-gcp-redis" deleted
-```
-
-Delete gcp-provider and secrets
-```bash
-kubectl delete -f cluster/examples/gitlab/gcp/provider.yaml
-```
diff --git a/docs/v0.4/gitlab/gitlab-login.png b/docs/v0.4/gitlab/gitlab-login.png
deleted file mode 100644
index 44c0ad1a..00000000
Binary files a/docs/v0.4/gitlab/gitlab-login.png and /dev/null differ
diff --git a/docs/v0.4/install-crossplane.md b/docs/v0.4/install-crossplane.md
deleted file mode 100644
index 10ef36a6..00000000
--- a/docs/v0.4/install-crossplane.md
+++ /dev/null
@@ -1,276 +0,0 @@
----
-title: Install Crossplane
-toc: true
-weight: 220
-indent: true
----
-# Install Crossplane
-
-Crossplane can be easily installed into any existing Kubernetes cluster using the regularly published Helm chart.
-The Helm chart contains all the custom resources and controllers needed to deploy and configure Crossplane.
-
-## Pre-requisites
-
-* [Kubernetes cluster](https://kubernetes.io/docs/setup/)
- * For example [Minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/), minimum version `v0.28+`
-* [Helm](https://docs.helm.sh/using_helm/), minimum version `v2.12.0+`.
- * For Helm 2, make sure Tiller is initialized with sufficient permissions to work on `crossplane-system` namespace.
-
-## Installation
-
-Helm charts for Crossplane are currently published to the `alpha` and `master` channels.
-In the future, `beta` and `stable` will also be available.
-
-> If you're using Helm 3, make sure you create the `crossplane-system` namespace (or the namespace you'd like to install
-crossplane) beforehand since Helm 3 does not create that for you automatically anymore.
-
-### Alpha
-
-The alpha channel is the most recent release of Crossplane that is considered ready for testing by the community.
-
-```console
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-### Master
-
-The `master` channel contains the latest commits, with all automated tests passing.
-`master` is subject to instability, incompatibility, and features may be added or removed without much prior notice.
-It is recommended to use one of the more stable channels, but if you want the absolute newest Crossplane installed, then you can use the `master` channel.
-
-To install the Helm chart from master, you will need to pass the specific version returned by the `search` command:
-
-```console
-helm repo add crossplane-master https://charts.crossplane.io/master/
-helm search crossplane
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version
-```
-
-For example:
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --version 0.0.0-249.637ccf9
-```
-
-## Installing Cloud Provider Stacks
-
-You can add additional functionality to Crossplane's control plane by installing Crossplane Stacks. For example, each
-supported cloud provider has its own corresponding stack that contains all the functionality for that particular cloud.
-After a cloud provider's stack is installed, you will be able to provision and manage resources within that cloud
-from Crossplane.
-
-### Installation with Helm
-
-> This method is not supported with Helm 3, please see [Manual Installation](#manual-installation) if you're using Helm 3.
-
-You can include deployment of additional infrastructure stacks into your helm installation by setting `clusterStacks..deploy` to `true`.
-
-For example, the following will install `master` version of the GCP stack:
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-master/crossplane --set clusterStacks.gcp.deploy=true --set clusterStacks.gcp.version=master
-```
-
-See [helm configuration parameters](#configuration) for supported stacks and parameters.
-
-### Manual Installation
-
-After Crossplane has been installed, it is possible to extend Crossplane's functionality by installing Crossplane stacks.
-
-#### GCP Stack
-
-To get started with Google Cloud Platform (GCP), create a file named `stack-gcp.yaml` with the following content:
-
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
- name: gcp
----
-apiVersion: stacks.crossplane.io/v1alpha1
-kind: ClusterStackInstall
-metadata:
- name: stack-gcp
- namespace: gcp
-spec:
- package: "crossplane/stack-gcp:v0.2.1"
-```
-
-Then you can install the GCP stack into Crossplane in the `gcp` namespace with the following command:
-
-```console
-kubectl apply -f stack-gcp.yaml
-```
-
-#### AWS Stack
-
-To get started with Amazon Web Services (AWS), create a file named `stack-aws.yaml` with the following content:
-
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
- name: aws
----
-apiVersion: stacks.crossplane.io/v1alpha1
-kind: ClusterStackInstall
-metadata:
- name: stack-aws
- namespace: aws
-spec:
- package: "crossplane/stack-aws:v0.2.1"
-```
-
-Then you can install the AWS stack into Crossplane in the `aws` namespace with the following command:
-
-```console
-kubectl apply -f stack-aws.yaml
-```
-
-#### Azure Stack
-
-To get started with Microsoft Azure, create a file named `stack-azure.yaml` with the following content:
-
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
- name: azure
----
-apiVersion: stacks.crossplane.io/v1alpha1
-kind: ClusterStackInstall
-metadata:
- name: stack-azure
- namespace: azure
-spec:
- package: "crossplane/stack-azure:v0.2.1"
-```
-
-Then you can install the Azure stack into Crossplane in the `azure` namespace with the following command:
-
-```console
-kubectl apply -f stack-azure.yaml
-```
-
-#### Rook Stack
-
-To get started with Rook, create a file named `stack-rook.yaml` with the following content:
-
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
- name: rook
----
-apiVersion: stacks.crossplane.io/v1alpha1
-kind: ClusterStackInstall
-metadata:
- name: stack-rook
- namespace: rook
-spec:
- package: "crossplane/stack-rook:v0.1.1"
-```
-
-Then you can install the Rook stack into Crossplane in the `rook` namespace with the following command:
-
-```console
-kubectl apply -f stack-rook.yaml
-```
-
-### Uninstalling Cloud Provider Stacks
-
-The cloud provider stacks can be uninstalled simply by deleting the stack resources from the cluster with a command similar to what's shown below.
-**Note** that this will also **delete** any resources that Crossplane has provisioned in the cloud provider if their `ReclaimPolicy` is set to `Delete`.
-
-After you have ensured that you are completely done with all your cloud provider resources, you can then run one of the commands below,
-depending on which cloud provider you are removing, to remove its stack from Crossplane:
-
-#### Uninstalling GCP
-
-```console
-kubectl delete -f stack-gcp.yaml
-```
-
-#### Uninstalling AWS
-
-```console
-kubectl delete -f stack-aws.yaml
-```
-
-#### Uninstalling Azure
-
-```console
-kubectl delete -f stack-azure.yaml
-```
-
-#### Uninstalling Rook
-
-```console
-kubectl delete -f stack-rook.yaml
-```
-
-## Uninstalling the Chart
-
-To uninstall/delete the `crossplane` deployment:
-
-```console
-helm delete --purge crossplane
-```
-
-That command removes all Kubernetes components associated with Crossplane, including all the custom resources and controllers.
-
-## Configuration
-
-The following tables lists the configurable parameters of the Crossplane chart and their default values.
-
-| Parameter | Description | Default |
-| -------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------ |
-| `image.repository` | Image | `crossplane/crossplane` |
-| `image.tag` | Image tag | `master` |
-| `image.pullPolicy` | Image pull policy | `Always` |
-| `imagePullSecrets` | Names of image pull secrets to use | `dockerhub` |
-| `replicas` | The number of replicas to run for the Crossplane operator | `1` |
-| `deploymentStrategy` | The deployment strategy for the Crossplane operator | `RollingUpdate` |
-| `clusterStacks.aws.deploy` | Deploy AWS stack | `false`
-| `clusterStacks.aws.version` | AWS stack version to deploy | ``
-| `clusterStacks.gcp.deploy` | Deploy GCP stack | `false`
-| `clusterStacks.gcp.version` | GCP stack version to deploy | ``
-| `clusterStacks.azure.deploy` | Deploy Azure stack | `false`
-| `clusterStacks.azure.version` | Azure stack version to deploy | ``
-| `clusterStacks.rook.deploy` | Deploy Rook stack | `false`
-| `clusterStacks.rook.version` | Rook stack version to deploy | ``
-
-### Command Line
-
-You can pass the settings with helm command line parameters.
-Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`.
-For example, the following command will install Crossplane with an image pull policy of `IfNotPresent`.
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane --set image.pullPolicy=IfNotPresent
-```
-
-### Settings File
-
-Alternatively, a yaml file that specifies the values for the above parameters (`values.yaml`) can be provided while installing the chart.
-
-```console
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane -f values.yaml
-```
-
-Here are the sample settings to get you started.
-
-```yaml
-replicas: 1
-
-deploymentStrategy: RollingUpdate
-
-image:
- repository: crossplane/crossplane
- tag: master
- pullPolicy: Always
-
-imagePullSecrets:
-- dockerhub
-```
diff --git a/docs/v0.4/learn-more.md b/docs/v0.4/learn-more.md
deleted file mode 100644
index c4f978b6..00000000
--- a/docs/v0.4/learn-more.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Learn More
-toc: true
-weight: 810
----
-# Learn More
-
-If you have any questions, please drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us]!
-
-***Learn more about using Crossplane***
- - [GitLab deploys into multiple clouds from kubectl using Crossplane](https://about.gitlab.com/2019/05/20/gitlab-first-deployed-kubernetes-api-to-multiple-clouds/)
- - [CNCF Talks & Community Presentations](https://www.youtube.com/playlist?list=PL510POnNVaaZJj9OG6PbgsZvgYbhwJRyE)
- - [Software Engineering Daily - Intro Podcast](https://softwareengineeringdaily.com/2019/01/02/crossplane-multicloud-control-plane-with-bassam-tabbara/)
- - [Crossplane Architecture](https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit?usp=sharing)
- - [Latest Design Docs](https://github.com/crossplaneio/crossplane/tree/master/design)
- - [Roadmap](https://github.com/crossplaneio/crossplane/blob/master/ROADMAP.md)
-
-***Writing Kubernetes controllers to extend Crossplane***
- - [Keep the Space Shuttle Flying: Writing Robust Operators](https://www.youtube.com/watch?v=uf97lOApOv8)
- - [Best practices for building Kubernetes Operators](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)
- - [Programming Kubernetes Book](https://www.oreilly.com/library/view/programming-kubernetes/9781492047094/)
- - [Crossplane Reconciler Patterns](https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-reconciler-patterns.md)
- - [Contributor Guide](https://github.com/crossplaneio/crossplane/blob/master/CONTRIBUTING.md)
-
-***Join the growing Crossplane community and get involved!***
-- Join our [Community Slack](https://slack.crossplane.io/)!
-- Submit an issue on [GitHub](https://github.com/crossplaneio/crossplane)
-- Attend our bi-weekly [Community Meeting](https://github.com/crossplaneio/crossplane#community-meeting)
-- Join our bi-weekly live stream: [The Binding Status](https://github.com/crossplaneio/tbs)
-- Subscribe to our [YouTube Channel](https://www.youtube.com/channel/UC19FgzMBMqBro361HbE46Fw)
-- Drop us a note on Twitter: [@crossplane_io](https://twitter.com/crossplane_io)
-- Email us: [info@crossplane.io](mailto:info@crossplane.io)
-
-
-[join-crossplane-slack]: https://slack.crossplane.io
-[contact-us]: https://github.com/crossplaneio/crossplane#contact
diff --git a/docs/v0.4/media/arch.png b/docs/v0.4/media/arch.png
deleted file mode 100644
index 8205e62e..00000000
Binary files a/docs/v0.4/media/arch.png and /dev/null differ
diff --git a/docs/v0.4/media/banner.png b/docs/v0.4/media/banner.png
deleted file mode 100644
index 0a495e1d..00000000
Binary files a/docs/v0.4/media/banner.png and /dev/null differ
diff --git a/docs/v0.4/media/crossplane-overview.png b/docs/v0.4/media/crossplane-overview.png
deleted file mode 100644
index 87c25a89..00000000
Binary files a/docs/v0.4/media/crossplane-overview.png and /dev/null differ
diff --git a/docs/v0.4/media/logo.svg b/docs/v0.4/media/logo.svg
deleted file mode 100644
index 3af90369..00000000
--- a/docs/v0.4/media/logo.svg
+++ /dev/null
@@ -1,310 +0,0 @@
-
-
-
diff --git a/docs/v0.4/postgresql.md b/docs/v0.4/postgresql.md
deleted file mode 100644
index 3964587d..00000000
--- a/docs/v0.4/postgresql.md
+++ /dev/null
@@ -1,133 +0,0 @@
-# Deploying PostgreSQL Databases
-
-This user guide will walk you through how to deploy a PostgreSQL database across many different environments with a focus on portability and reusability.
-The database will be dynamically provisioned in the cloud provider of your choice at the request of the application developer via a `ResourceClaim` and created with the environment specific information that the administrator providers in a `ResourceClass`.
-The commands in this guide assume you are running from a terminal/shell at the root of the [Crossplane repo](https://github.com/crossplaneio/crossplane/).
-
-## Install Crossplane
-
-The first step will be to install Crossplane and any desired cloud provider stacks by following the steps in the [Crossplane install guide](install-crossplane.md).
-
-## Add Cloud Provider
-
-Next you'll need to add your cloud provider credentials to Crossplane using [these provider specific steps](cloud-providers.md).
-
-After those steps are completed, you should have the cloud provider credentials saved in a file on your local filesystem, for which the path will be stored in the environment variable `PROVIDER_KEY_FILE` in the next section.
-
-## Set Environment Variables
-
-After your cloud provider credentials have been created/added, let's set the following environment variables that have different values for each provider,
-but will allow the rest of the steps to be consistent across all of them.
-You only need to set the variables for your chosen cloud provider, you can ignore the other ones.
-
-### Google Cloud Platform (GCP)
-
-```console
-export PROVIDER=GCP
-export provider=gcp
-export PROVIDER_KEY_FILE=crossplane-${provider}-provider-key.json
-export DATABASE_TYPE=cloudsqlinstances
-export versionfield=databaseVersion
-```
-
-### Microsoft Azure
-
-```console
-export PROVIDER=AZURE
-export provider=azure
-export PROVIDER_KEY_FILE=crossplane-${provider}-provider-key.json
-export DATABASE_TYPE=postgresqlservers
-export versionfield=version
-```
-
-### Amazon Web Services (AWS)
-
-```console
-export PROVIDER=AWS
-export provider=aws
-export PROVIDER_KEY_FILE=~/.aws/credentials
-export DATABASE_TYPE=rdsinstances
-export versionfield=engineVersion
-```
-
-## Create a PostgreSQL Resource Class
-
-Let's create a `ResourceClass` that acts as a "blueprint" that contains the environment specific details of how a general request from the application to create a PostgreSQL database should be fulfilled.
-This is a task that the administrator should complete, since they will have the knowledge and privileges for the specific environment details.
-
-```console
-sed "s/BASE64ENCODED_${PROVIDER}_PROVIDER_CREDS/`base64 ${PROVIDER_KEY_FILE} | tr -d '\n'`/g;" cluster/examples/database/${provider}/postgresql/provider.yaml | kubectl create -f -
-kubectl create -f cluster/examples/database/${provider}/postgresql/resource-class.yaml
-```
-
-## Create a PostgreSQL Resource Claim
-
-After the administrator has created the PostgreSQL `ResourceClass` "blueprint", the application developer is now free to create a PostgreSQL `ResourceClaim`.
-This is a general request for a PostgreSQL database to be used by their application and it requires no environment specific information, allowing our applications to express their need for a database in a very portable way.
-
-```console
-kubectl create namespace demo
-kubectl -n demo create -f cluster/examples/database/${provider}/postgresql/resource-claim.yaml
-```
-
-## Check Status of PostgreSQL Provisioning
-
-We can follow along with the status of the provisioning of the database resource with the below commands.
-Note that the first command gives us the status of the `ResourceClaim` (general request for a database by the application),
-and the second command gives the status of the environment specific database resource that Crossplane is provisioning using the `ResourceClass` "blueprint".
-
-```console
-kubectl -n demo get postgresqlinstance -o custom-columns=NAME:.metadata.name,STATUS:.status.bindingPhase,CLASS:.spec.classRef.name,VERSION:.spec.engineVersion,AGE:.metadata.creationTimestamp
-kubectl -n crossplane-system get ${DATABASE_TYPE} -o custom-columns=NAME:.metadata.name,STATUS:.status.bindingPhase,STATE:.status.state,CLASS:.spec.classRef.name,VERSION:.spec.${versionfield},AGE:.metadata.creationTimestamp
-```
-
-## Access the PostgreSQL Database
-
-Once the dynamic provisioning process has finished creating and preparing the database, the status output will look similar to the following:
-
-```console
-> kubectl -n demo get postgresqlinstance -o custom-columns=NAME:.metadata.name,STATUS:.status.bindingPhase,CLASS:.spec.classRef.name,VERSION:.spec.engineVersion,AGE:.metadata.creationTimestamp
-NAME STATUS CLASS VERSION AGE
-cloud-postgresql-claim Bound cloud-postgresql 9.6 2018-12-23T04:00:11Z
-
-> kubectl -n crossplane-system get ${DATABASE_TYPE} -o custom-columns=NAME:.metadata.name,STATUS:.status.bindingPhase,STATE:.status.state,CLASS:.spec.classRef.name,VERSION:.spec.${versionfield},AGE:.metadata.creationTimestamp
-NAME STATUS STATE CLASS VERSION AGE
-postgresql-3ef70bf9-0667-11e9-99e1-080027cf2340 Bound Ready cloud-postgresql 9.6 2018-12-23T04:00:12Z
-```
-
-Note that both the general `postgresqlinstance` `ResourceClaim` and the cloud provider specific PostgreSQL database have the `Bound` status, meaning the dynamic provisioning is done and the resource is ready for consumption.
-
-The connection information will be stored in a secret specified via the `writeConnectionSecretTo` field.
-Since the secret is base64 encoded, we'll need to decode its fields to view them in plain-text.
-To view all the connection information in plain-text, run the following command:
-
-```console
-for r in endpoint username password; do echo -n "${r}: "; kubectl -n demo get secret cloud-postgresql-claim -o jsonpath='{.data.'"${r}"'}' | base64 -D; echo; done
-```
-
-A workload or pod manifest will usually reference this connection information through injecting the secret contents into environment variables in the manifest.
-You can see this in action as an example in the [Azure Workload example](https://github.com/crossplaneio/crossplane/blob/release-0.1/cluster/examples/workloads/wordpress-azure/workload.yaml#L47-L62).
-
-More information about consuming secrets from manifests can be found in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/secret/#use-cases).
-
-## Clean-up
-
-When you are finished with the PostgreSQL instance from this guide, you can clean up all the resources by running the below commands.
-
-First, delete the resource claim, which will start the operation of deleting the PostgreSQL database from your cloud provider.
-
-```console
-kubectl -n demo delete -f cluster/examples/database/${provider}/postgresql/resource-claim.yaml
-```
-
-Next. delete the `ResourceClass` "blueprint":
-
-```console
-kubectl delete -f cluster/examples/database/${provider}/postgresql/resource-class.yaml
-```
-
-Finally, delete the cloud provider credentials from your local environment:
-
-```console
-kubectl delete -f cluster/examples/database/${provider}/postgresql/provider.yaml
-```
diff --git a/docs/v0.4/quick-start.md b/docs/v0.4/quick-start.md
deleted file mode 100644
index 91605873..00000000
--- a/docs/v0.4/quick-start.md
+++ /dev/null
@@ -1,382 +0,0 @@
----
-title: Getting Started
-toc: true
-weight: 210
----
-# Getting Started
-
-This guide will demonstrate using Crossplane to deploy a portable MySQL database
-on the Google Cloud Platform (GCP). It serves as an initial introduction to
-Crossplane, but only displays a small set of its features.
-
-In this guide we will:
-
-1. [Install Crossplane](#install-crossplane)
-1. [Add your GCP project to Crossplane](#add-your-gcp-project-to-crossplane)
-1. [Provision a MySQL instance using CloudSQL](#provision-a-mysql-instance)
-1. [Define a class of CloudSQL instance for dynamic provisioning](#define-a-class-of-cloudsql-instance)
-
-## Install Crossplane
-
-We'll start by installing Crossplane using [Helm]. You'll need a working
-Kubernetes cluster ([minikube] or [kind] will do just fine). Crossplane is
-currently in alpha, so we'll use the `alpha` channel:
-
-```bash
-# Crossplane lives in the crossplane-system namespace by convention.
-kubectl create namespace crossplane-system
-
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-Once Crossplane is installed we'll need to install the a [stack] for our cloud
-provider - in this case GCP. Installing the GCP stack teaches Crossplane how to
-provision and maanage things in GCP. You install it by creating a
-`ClusterStackInstall`:
-
-```yaml
-apiVersion: stacks.crossplane.io/v1alpha1
-kind: ClusterStackInstall
-metadata:
- name: stack-gcp
- namespace: crossplane-system
-spec:
- package: "crossplane/stack-gcp:v0.2.1"
-```
-
-Save the above as `stack.yaml`, and apply it by running:
-
-```bash
-kubectl apply -f stack.yaml
-```
-
-We've now installed Crossplane with GCP support! Take a look at the [Crossplane
-installation guide] for more installation options, and to learn how to install
-support for other cloud providers such as Amazon Web Services and Microsoft
-Azure.
-
-## Add Your GCP Project to Crossplane
-
-We've taught Crossplane how to work with GCP - now we must tell it how to
-connect to your GCP project. We'll do this by creating a Crossplane `Provider`
-that specifies the project name and some GCP service account credentials to use:
-
-```yaml
-apiVersion: gcp.crossplane.io/v1alpha3
-kind: Provider
-metadata:
- name: example-provider
-spec:
- # Make sure to update your project's name here.
- projectID: my-cool-gcp-project
- credentialsSecretRef:
- name: example-gcp-credentials
- namespace: crossplane-system
- key: credentials.json
-```
-
-Save the above `Provider` as `provider.yaml`, save your Google Application
-Credentials as `credentials.json`, then run:
-
-```bash
-kubectl -n crossplane-system create secret example-gcp-credentials --from-file=credentials.json
-kubectl apply -f provider.yaml
-```
-
-Crossplane can now manage your GCP project! Your service account will need the
-CloudSQL Admin role for this guide. Check out GCP's [Getting Started With
-Authentication] guide if you need help creating a service account and
-downloading its `credentials.json` file, and Crossplane's [GCP provider
-documentation] for detailed instructions on setting up your project and service
-account permissions.
-
-## Provision a MySQL Instance
-
-GCP provides MySQL databases using [CloudSQL] instances. Crossplane uses a
-resource and claim pattern to provision and manage cloud resources like CloudSQL
-instances - if you've ever used [persistent volumes in Kubernetes] you've seen
-this pattern before. The simplest way to start using a new MySQL instance on GCP
-is to provision a `CloudSQLInstance`, then claim it via a `MySQLInstance`. We
-call this process _static provisioning_.
-
-
-```yaml
-apiVersion: database.gcp.crossplane.io/v1beta1
-kind: CloudSQLInstance
-metadata:
- name: example-cloudsql-instance
-spec:
- providerRef:
- name: example-provider
- writeConnectionSecretToRef:
- name: example-cloudsql-connection-details
- namespace: crossplane-system
- forProvider:
- databaseVersion: MYSQL_5_6
- region: us-west2
- settings:
- tier: db-n1-standard-1
- dataDiskType: PD_SSD
- dataDiskSizeGb: 10
- ipConfiguration:
- ipv4Enabled: true
-```
-
-First we create a CloudSQL instance. Save the above as `cloudsql.yaml`, then
-apply it:
-
-```bash
-kubectl apply -f cloudsql.yaml
-```
-
-Crossplane is now creating the `CloudSQLInstance`! Before we can use it, we need
-to claim it.
-
-```yaml
-apiVersion: database.crossplane.io/v1alpha1
-kind: MySQLInstance
-metadata:
- name: example-mysql-claim
-spec:
- resourceRef:
- apiVersion: database.gcp.crossplane.io/v1beta1
- kind: CloudSQLInstance
- name: example-cloudsql-instance
- writeConnectionSecretToRef:
- name: example-mysql-connection-details
-```
-
-Save the above as `mysql.yaml`, and once again apply it:
-
-```bash
-kubectl --namespace default apply -f mysql.yaml
-```
-
-In Crossplane cloud provider specific resources like the `CloudSQLInstance` we
-created above are called _managed resources_. They're considered infrastructure,
-like a Kubernetes `Node` or `PersistentVolume`. Managed resources exist at the
-cluster scope (they're not namespaced) and let you specify nitty-gritty provider
-specific configuration details. Managed resources that have reached `v1beta1`
-are a high fidelity representation of their underlying cloud provider resource,
-and can be updated to change their configuration after provisioning. We _claim_
-these resources by submitting a _resource claim_ like the `MySQLInstance` above.
-Resource claims are namespaced, and indicate that the managed resource they
-claim is in use by _binding_ to it. You can also use resource claims to
-_dynamically provision_ managed resources on-demand - we'll discuss that in the
-next section of this guide.
-
-Soon your new `MySQLInstance` should be online. You can use `kubectl` to
-inspect its status. If you see `Bound` under the `STATUS` column, it's ready to
-use!
-
-```bash
-$ kubectl --namespace default get mysqlinstance example-mysql-claim
-NAME STATUS CLASS-KIND CLASS-NAME RESOURCE-KIND RESOURCE-NAME AGE
-example-mysql-claim Bound CloudSQLInstance example-cloudsql-instance 4m
-```
-
-You'll find all the details you need to connect to your new MySQL instance saved
-in the Kubernetes `Secret` you specified via `writeConnectionSecretToRef`, ready
-to [use with your Kubernetes pods].
-
-```bash
-$ kubectl --namespace default describe secret example-mysql-connection-details
-Name: example-mysql-connection-details
-Namespace: default
-Type: Opaque
-
-Data
-====
-serverCACertificateCommonName: 98 bytes
-serverCACertificateInstance: 25 bytes
-username: 4 bytes
-password: 27 bytes
-publicIP: 13 bytes
-serverCACertificateCertSerialNumber: 1 bytes
-serverCACertificateCreateTime: 24 bytes
-serverCACertificateExpirationTime: 24 bytes
-serverCACertificateSha1Fingerprint: 40 bytes
-endpoint: 13 bytes
-serverCACertificateCert: 1272 bytes
-```
-
-That's all there is to static provisioning with Crossplane! We've created a
-`CloudSQLInstance` as cluster scoped infrastructure, then claimed it as a
-`MySQLInstance`. You can use `kubectl describe` to view the detailed
-configuration and status of your `CloudSqlInstance`.
-
-```bash
-$ kubectl describe example-cloudsql-instance
-Name: example-cloudsql-instance
-Annotations: crossplane.io/external-name: example-cloudsql-instance
-API Version: database.gcp.crossplane.io/v1beta1
-Kind: CloudSQLInstance
-Spec:
- For Provider:
- Database Version: MYSQL_5_6
- Gce Zone: us-west2-b
- Instance Type: CLOUD_SQL_INSTANCE
- Region: us-west2
- Settings:
- Activation Policy: ALWAYS
- Backup Configuration:
- Start Time: 17:00
- Data Disk Size Gb: 10
- Data Disk Type: PD_SSD
- Ip Configuration:
- ipv4Enabled: true
- Location Preference:
- Zone: us-west2-b
- Pricing Plan: PER_USE
- Replication Type: SYNCHRONOUS
- Storage Auto Resize: true
- Tier: db-n1-standard-1
- Provider Ref:
- Name: example-provider
- Write Connection Secret To Ref:
- Name: example-cloudsql-connection-details
- Namespace: crossplane-system
-Status:
- At Provider:
- Backend Type: SECOND_GEN
- Connection Name: my-cool-gcp-project:us-west2:example-cloudsql-instance
- Gce Zone: us-west2-b
- Ip Addresses:
- Ip Address: 8.8.8.8
- Type: PRIMARY
- Project: my-cool-gcp-project
- Self Link: https://www.googleapis.com/sql/v1beta4/projects/my-cool-gcp-project/instances/example-cloudsql-instance
- Service Account Email Address: REDACTED@gcp-sa-cloud-sql.iam.gserviceaccount.com
- State: RUNNABLE
- Binding Phase: Bound
- Conditions:
- Last Transition Time: 2019-10-25T08:09:16Z
- Reason: Successfully reconciled managed resource
- Status: True
- Type: Synced
- Last Transition Time: 2019-10-25T08:09:12Z
- Reason: Successfully resolved managed resource references to other resources
- Status: True
- Type: ReferencesResolved
- Last Transition Time: 2019-10-25T08:09:16Z
- Reason: Managed resource is available for use
- Status: True
- Type: Ready
-```
-
-Pay attention to the `Ready` and `Synced` conditions above. `Ready` represents
-the availability of the CloudSQL instance while `Synced` reflects whether
-Crossplane is successfully applying your specified CloudSQL configuration.
-
-## Define a Class of CloudSQL Instance
-
-Now that we've learned how to statically provision and claim managed resources
-it's time to try out _dynamic provisioning_. Dynamic provisioning allows us to
-define a class of managed resource - a _resource class_ - that will be used to
-automatically satisfy resource claims when they are created.
-
-Here's a resource class that will dynamically provision Cloud SQL instances with
-the same settings as the `CloudSqlInstance` we provisioned earlier in the guide:
-
-```yaml
-apiVersion: database.gcp.crossplane.io/v1beta1
-kind: CloudSQLInstanceClass
-metadata:
- name: example-cloudsql-class
- annotations:
- resourceclass.crossplane.io/is-default-class: "true"
- labels:
- guide: getting-started
-specTemplate:
- providerRef:
- name: example
- writeConnectionSecretsToNamespace: crossplane-system
- forProvider:
- databaseVersion: MYSQL_5_6
- region: us-west2
- settings:
- tier: db-n1-standard-1
- dataDiskType: PD_SSD
- dataDiskSizeGb: 10
- ipConfiguration:
- ipv4Enabled: true
-```
-
-Save the above as `cloudsql-class.yaml` and apply it to enable dynamic
-provisioning of `CloudSqlInstance` managed resources:
-
-```bash
-kubectl apply -f cloudsql-class.yaml
-```
-
-Now you can omit the `resourceRef` when you create resource claims. Save the
-below resource claim as `mysql-dynamic-claim.yaml`:
-
-```yaml
-apiVersion: database.crossplane.io/v1alpha1
-kind: MySQLInstance
-metadata:
- name: example-mysql-dynamic-claim
-spec:
- classSelector:
- matchLabels:
- guide: getting-started
- writeConnectionSecretToRef:
- name: example-mysql-dynamic-connection-details
-```
-
-When you apply this `MySQLInstance` claim you'll see that it dynamically
-provisions a new `CloudSQLInstance` to satisfy the resource claim:
-
-```bash
-$ kubectl --namespace default apply -f mysql-dynamic-claim.yaml
-mysqlinstance.database.crossplane.io/example-mysql-dynamic-claim created
-
-$ kubectl get mysqlinstance example-mysql-dynamic-claim
-NAME STATUS CLASS-KIND CLASS-NAME RESOURCE-KIND RESOURCE-NAME AGE
-example-mysql-dynamic-claim CloudSQLInstanceClass example-cloudsql-class CloudSQLInstance default-example-mysql-dynamic-claim-bwpzd 47s
-```
-
-You just dynamically provisioned a `CloudSQLInstance`! You can find the name of
-your new `CloudSQLInstance` under the `RESOURCE-NAME` column when you run
-`kubectl describe mysqlinstance`. Reuse the resource class as many times as you
-like; simply submit more `MySQLInstance` resource claims to create more CloudSQL
-instances.
-
-You may have noticed that your resource claim included a `classSelector`. The
-class selector lets you select which resource class to use by [matching its
-labels]. Resource claims like `MySQLInstance` can match different kinds of
-resource class using label selectors, so you could just as easily use the
-exact same `MySQLInstance` to create an Amazon Relational Database Service (RDS)
-instance by creating an `RDSInstanceClass` labelled as `guide: getting-started`.
-When multiple resource classes match the class selector, a matching class is
-chosen at random. Claims can be matched to classes by either:
-
-* Specifying a `classRef` to a specific resource class.
-* Specifying a `classSelector` that matches one or more resource classes.
-* Omitting both of the above and defaulting to a resource class [annotated] as
- `resourceclass.crossplane.io/is-default-class: "true"`.
-
-## Next Steps
-
-* Add additional [cloud provider stacks](cloud-providers.md) to Crossplane.
-* Explore the [Services Guide](services-guide.md) and the [Stacks Guide](stacks-guide.md).
-* Learn more about [Crossplane concepts](concepts.md).
-* See what managed resources are [currently supported](api.md) for each provider.
-* Build [your own stacks](developer-guide.md)!
-
-
-
-[Helm]: https://helm.sh
-[minikube]: https://kubernetes.io/docs/tasks/tools/install-minikube/
-[kind]: https://github.com/kubernetes-sigs/kind
-[stack]: concepts.md#stacks
-[Crossplane installation guide]: install-crossplane.md
-[Getting Started With Authentication]: https://cloud.google.com/docs/authentication/getting-started
-[GCP provider documentation]: gcp-provider.md
-[CloudSQL]: https://cloud.google.com/sql/docs/mysql/
-[Persistent volumes in Kubernetes]: https://kubernetes.io/docs/concepts/storage/persistent-volumes/
-[use with your Kubernetes pods]: https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets
-[matching its labels]: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
-[annotated]: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
diff --git a/docs/v0.4/related-projects.md b/docs/v0.4/related-projects.md
deleted file mode 100644
index 33974f49..00000000
--- a/docs/v0.4/related-projects.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Related Projects
-toc: true
-weight: 850
-indent: true
----
-# Related Projects
-
-While there are many projects that address similar issues, none of them encapsulate the full use case that Crossplane addresses. This list is not exhaustive and is not meant to provide a deep analysis of the following projects, but instead to motivate why Crossplane was created.
-
-## Open Service Broker and Service Catalog
-
-The [Open Service Broker](https://www.openservicebrokerapi.org/) and the [Kubernetes Service Catalog](https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/) are able to dynamically provision managed services in multiple cloud providers from Kubernetes. As a result it shares similar goals with Crossplane. However, service broker is not designed for workload portability, does not have a good separation of concern, and does not offer any integration with workload and resource scheduling. Service brokers can not span multiple cloud providers at once.
-
-## Kubernetes Federation
-
-The [federation-v2](https://github.com/kubernetes-sigs/federation-v2) project offers a single control plane that can span multiple Kubernetes clusters. It’s being incubated in SIG-multicluster. Crossplane shares some of the goals of managing multiple Kubernetes clusters and also the core principles of creating a higher level control plane, scheduler and controllers that span clusters. While the federation-v2 project is scoped to just Kubernetes clusters, Crossplane supports non-container workloads, and orchestrating resources that run as managed services including databases, message queues, buckets, and others. The federation effort focuses on defining Kubernetes objects that can be templatized, and propagated to other Kubernetes clusters. Crossplane focuses on defining portable workload abstractions across cloud providers and offerings. We have considered taking a dependency on the federation-v2 work within Crossplane, although it’s not clear at this point if this would accelerate the Crossplane effort.
-
-## AWS Service Operator
-
-The [AWS Service Operator](https://github.com/awslabs/aws-service-operator) is a recent project that implements a set of Kubernetes controllers that are able to provision managed services in AWS. It defines a set of CRDs for managed services like DynamoDB, and controllers that can provision them via AWS CloudFormation. It is similar to Crossplane in that it can provision managed services in AWS. Crossplane goes a lot further by offering workload portability across cloud multiple cloud providers, separation of concern, and a scheduler for workload and resources.
-
-## AWS CloudFormation, GCP Deployment Manager, and Others
-
-These products offer a declarative model for deploying and provisioning infrastructure in each of the respective cloud providers. They only work for one cloud provider and do not solve the problem of workload portability. These products are generally closed source, and offer little or no extensibility points. We have considered using some of these products as a way to implement resource controllers in Crossplane.
-
-## Terraform
-
-[Terraform](https://www.terraform.io/) is a popular tool for provisioning infrastructure across cloud providers. It offers a declarative configuration language with support for templating, composability, referential integrity and dependency management. Terraform can dynamically provision infrastructure and perform changes when the tool is run by a human. Unlike Crossplane, Terraform does not support workload portability across cloud providers, and does not have any active controllers that can react to failures, or make changes to running infrastructure without human intervention. Terraform attempts to solve multicloud at the tool level, while Crossplane is at the API and control plane level. Terraform is open source under a MPL license, and follows an open core business model, with a number of its features closed source. We are evaluating whether we can use Terraform to accelerate the development of resource controllers in Crossplane.
-
-## Pulumi
-
-[Pulumi](https://www.pulumi.com/) is a product that is based on terraform and uses most of its providers. Instead of using a configuration language, Pulumi uses popular programming languages like Typescript to capture the configuration. At runtime, Pulumi generates a DAG of resources just like terraform and applies it to cloud providers. Pulumi has an early model for workload portability that is implemented using language abstractions. Unlike Crossplane, it does not have any active controllers that can react to failures, or make changes to running infrastructure without human intervention, nor does it support workload scheduling. Pulumi attempts to solve multicloud scenarios at the language level, while Crossplane is at the API and control plane level. Pulumi is open source under a APL2 license but a number of features require using their SaaS offering.
diff --git a/docs/v0.4/services-developer-guide.md b/docs/v0.4/services-developer-guide.md
deleted file mode 100644
index b266d7aa..00000000
--- a/docs/v0.4/services-developer-guide.md
+++ /dev/null
@@ -1,1119 +0,0 @@
----
-title: Services Developer Guide
-toc: true
-weight: 720
-indent: true
----
-# Services Developer Guide
-
-Crossplane Services supports managed service provisioning using `kubectl`. It
-applies the Kubernetes pattern for Persistent Volume (PV) claims and classes to
-managed service provisioning with support for a strong separation of concern
-between app teams and cluster administrators. This guide will walk through the
-process of adding support for a new managed service.
-
-## What Makes a Crossplane Managed Service?
-
-Crossplane builds atop Kubernetes's powerful architecture in which declarative
-configuration, known as resources, are continually 'reconciled' with reality by
-one or more controllers. A controller is an endless loop that:
-
-1. Observes the desired state (the declarative configuration resource).
-1. Observes the actual state (the thing said configuration resource represents).
-1. Tries to make the actual state match the desired state.
-
-A typical Crossplane managed service consists of five configuration resources
-and five controllers. The GCP Stack's support for Google Cloud Memorystore
-illustrates this. First, the configuration resources:
-
-1. A [managed resource]. Managed resources are cluster scoped, high-fidelity
- representations of a resource in an external system such as a cloud
- provider's API. Managed resources are _non-portable_ across external systems
- (i.e. cloud providers); they're tightly coupled to the implementation details
- of the external resource they represent. Managed resources are defined by a
- Stack. The GCP Stack's [`CloudMemorystoreInstance`] resource is an example of
- a managed resource.
-1. A [resource claim]. Resource claims are namespaced abstract declarations of a
- need for a service. Resource claims are frequently portable across external
- systems. Crossplane defines a series of common resource claim kinds,
- including [`RedisCluster`]. A resource claim is satisfied by _binding_ to a
- managed resource.
-1. A [resource class]. Resource classes represent a class of a specific kind of
- managed resource. They are the template used to create a new managed resource
- in order to satisfy a resource claim during [dynamic provisioning]. Resource
- classes are cluster scoped, and tightly coupled to the managed resources they
- template. [`CloudMemorystoreInstanceClass`] is an example of a resource
- class.
-1. A provider. Providers enable access to an external system, typically by
- indicating a Kubernetes Secret containing any credentials required to
- authenticate to the system, as well as any other metadata required to
- connect. Providers are cluster scoped, like managed resources and classes.
- The GCP [`Provider`] is an example of a provider.
-
-These resources are powered by:
-
-1. The managed resource controller. This controller is responsible for taking
- instances of the aforementioned high-fidelity managed resource kind and
- reconciling them with an external system. Managed resource controllers are
- unaware of resource claims or classes. The `CloudMemorystoreInstance`
- controller watches for changes to `CloudMemorystoreInstance` resources and
- calls Google's Cloud Memorystore API to create, update, or delete an instance
- as necessary.
-1. The resource claim scheduling controller. A claim scheduling controller
- exists for each kind of resource class that could satisfy a resource claim.
- This controller is unaware of any external system - it simply schedules
- resource claims to resource classes that match their class selector labels,
- so that they may be handled by the resource claim controller.
-1. The resource claim defaulting controller. A claim defaulting controller
- exists for each kind of resource class that could satisfy a resource claim.
- This controller is unaware of any external system - it allocates resource
- claims that do not specify a class selector to a resource class annotated as
- the default, if any, so that they may be handled by the claim controller.
-1. The resource claim controller. A resource claim controller exists for each
- kind of managed resource that could satisfy a resource claim. This controller
- is unaware of any external system - it responsible only for taking resource
- claims and binding them to a managed resource. The
- `CloudMemorystoreInstance` resource claim controller watches for
- `RedisCluster` resource claims that should be satisfied by a
- `CloudMemorystoreInstance`. It either binds to an explicitly referenced
- `CloudMemorystoreInstance` (static provisioning) or creates a new one and
- then binds to it (dynamic provisioning).
-1. The secret propagation controller. Like the resource claim controller, a
- secret propagation controller exists for each kind of managed resource that
- could satisfy a resource claim. Its job is simply to ensure that changes to
- the connection secret of a managed resource are always propagated to the
- connection secret of the resource claim it is bound to. The secret
- propagation controller is optional - managed resources that only write to
- their connection secret at creation time may omit this controller.
-
-Crossplane does not require controllers to be written in any particular
-language. The Kubernetes API server is our API boundary, so any process capable
-of [watching the API server] and updating resources can be a Crossplane
-controller.
-
-## Getting Started
-
-At the time of writing all Crossplane Services controllers are written in Go,
-and built using [kubebuilder] v0.2.x and [crossplane-runtime]. Per [What Makes
-a Crossplane Managed Service] it is possible to write a controller using any
-language and tooling with a Kubernetes client, but this set of tools are the
-"[golden path]". They're well supported, broadly used, and provide a shared
-language with the Crossplane maintainers.
-
-This guide assumes the reader is familiar with the Kubernetes [API Conventions]
-and the [kubebuilder book]. If you're not adding a new managed service to an
-existing Crossplane Stack you should start by working through the [Stacks quick
-start] to scaffold a new Stack in which the new types and controllers will live.
-
-## Defining Resource Kinds
-
-Let's assume we want to add Crossplane support for your favourite cloud's
-database-as-a-service. Your favourite cloud brands these instances as "Favourite
-DB instances". Under the hood they're powered by the open source FancySQL
-engine. We'll name the new managed resource kind `FavouriteDBInstance` and the
-new resource claim `FancySQLInstance`.
-
-The first step toward implementing a new managed service is to define the code
-level schema of its configuration resources. These are referred to as
-[resources], (resource) [kinds], and [objects] interchangeably. The kubebuilder
-scaffolding is a good starting point for any new Crossplane API kind, whether
-they'll be a managed resource, resource class, or resource claim:
-
-```console
-# The resource claim.
-kubebuilder create api \
- --group example --version v1alpha1 --kind FancySQLInstance \
- --resource=true --controller=false
-```
-
-The above command should produce a scaffold similar to the below
-example:
-
-```go
-type FancySQLInstanceSpec struct {
- // INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
- // Important: Run "make" to regenerate code after modifying this file
-}
-
-// FancySQLInstanceStatus defines the observed state of FancySQLInstance
-type FancySQLInstanceStatus struct {
- // INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
- // Important: Run "make" to regenerate code after modifying this file
-}
-
-// +kubebuilder:object:root=true
-
-// FancySQLInstance is the Schema for the fancysqlinstances API
-type FancySQLInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FancySQLInstanceSpec `json:"spec,omitempty"`
- Status FancySQLInstanceStatus `json:"status,omitempty"`
-}
-```
-
-Crossplane requires that these newly generated API type scaffolds be extended
-with a set of struct fields, getters, and setters that are standard to all
-Crossplane resource kinds. The fields and setters differ depending on whether
-the new resource kind is a managed resource, resource claim, or resource class.
-The getters and setter methods required to satisfy the various
-crossplane-runtime interfaces are omitted from the below examples for brevity.
-They can be added by hand, but new services are encouraged to use [`angryjet`]
-to generate them automatically using `go generate` per the `angryjet`
-documentation.
-
-Note that in many cases a suitable provider and resource claim will already
-exist. Frequently adding support for a new managed service requires only the
-definition of a new managed resource and resource class.
-
-### Managed Resource Kinds
-
-Managed resources must:
-
-* Satisfy crossplane-runtime's [`resource.Managed`] interface.
-* Embed a [`ResourceStatus`] struct in their `Status` struct.
-* Embed a [`ResourceSpec`] struct in their `Spec` struct.
-* Embed a `Parameters` struct in their `Spec` struct.
-* Use the `+kubebuilder:subresource:status` [comment marker].
-* Use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-The `Parameters` struct should be a _high fidelity_ representation of the
-writeable fields of the external resource's API. Put otherwise, if your
-favourite cloud represents Favourite DB instances as a JSON object then
-`FavouriteDBParameters` should marshal to a something as close to that JSON
-object as possible while still complying with Kubernetes API conventions.
-
-For example, assume the external API object for Favourite DB instance was:
-
-```json
-{
- "id": 42,
- "name": "mycoolinstance",
- "fanciness_level": 100,
- "version": "2.3",
- "status": "ONLINE",
- "hostname": "cool.fcp.example.org"
-}
-```
-
-Further assume the `id`, `status`, and `hostname` fields were output only, and
-the `version` field was optional. The `FavouriteDBInstance` managed resource
-should look as follows:
-
-```go
-// FavouriteDBInstanceParameters define the desired state of an FavouriteDB
-// instance. Most fields map directly to an Instance:
-// https://favourite.example.org/api/v1/db#Instance
-type FavouriteDBInstanceParameters struct {
-
- // We're still working on a standard for naming external resources. See
- // https://github.com/crossplaneio/crossplane/issues/624 for context.
-
- // Name of this instance.
- Name string `json:"name"`
-
- // Note that fanciness_level becomes fancinessLevel below. Kubernetes API
- // conventions trump cloud provider fidelity.
-
- // FancinessLevel specifies exactly how fancy this instance is.
- FancinessLevel int `json:"fancinessLevel"`
-
- // Version specifies what version of FancySQL this instance will run.
- // +optional
- Version *string `json:"version,omitempty"`
-}
-
-// A FavouriteDBInstanceSpec defines the desired state of a FavouriteDBInstance.
-type FavouriteDBInstanceSpec struct {
- runtimev1alpha1.ResourceSpec `json:",inline"`
- FavouriteDBInstanceParameters `json:",forProvider"`
-}
-
-// A FavouriteDBInstanceStatus represents the observed state of a
-// FavouriteDBInstance.
-type FavouriteDBInstanceStatus struct {
- runtimev1alpha1.ResourceStatus `json:",inline"`
-
- // Note that we add the three "output only" fields here in the status,
- // instead of the parameters. We want this representation to be high
- // fidelity just like the parameters.
-
- // ID of this instance.
- ID int `json:"id,omitempty"`
-
- // Status of this instance.
- Status string `json:"status,omitempty"`
-
- // Hostname of this instance.
- Hostname string `json:"hostname,omitempty"`
-}
-
-// A FavouriteDBInstance is a managed resource that represents a Favourite DB
-// instance.
-// +kubebuilder:subresource:status
-type FavouriteDBInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FavouriteDBInstanceSpec `json:"spec,omitempty"`
- Status FavouriteDBInstanceStatus `json:"status,omitempty"`
-}
-```
-
-Note that Crossplane uses the GoDoc strings of API kinds to generate user facing
-API documentation. __Document all fields__ and prefer GoDoc that assumes the
-reader is running `kubectl explain`, or reading an API reference, not reading
-the code. Refer to the [Managed Resource API Patterns] one pager for more detail
-on authoring high fidelity managed resources.
-
-### Resource Class Kinds
-
-The resource class kind for a particular managed resource kind are typically
-defined in the same file as their the managed resource. Resource classes must:
-
-* Satisfy crossplane-runtime's [`resource.Class`] interface.
-* Have a `SpecTemplate` struct field instead of a `Spec`.
-* Embed a [`ClassSpecTemplate`] struct in their `SpecTemplate` struct.
-* Embed their managed resource's `Parameters` struct in their `SpecTemplate`
- struct.
-* Not have a `Status` struct.
-* Use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-A resource class for the above `FavouriteDBInstance` would look as
-follows:
-
-```go
-// A FavouriteDBInstanceClassSpecTemplate is a template for the spec of a
-// dynamically provisioned FavouriteDBInstance.
-type FavouriteDBInstanceClassSpecTemplate struct {
- runtimev1alpha1.ClassSpecTemplate `json:",inline"`
- FavouriteDBInstanceParameters `json:",forProvider"`
-}
-
-// A FavouriteDBInstanceClass is a resource class. It defines the desired spec
-// of resource claims that use it to dynamically provision a managed resource.
-type FavouriteDBInstanceClass struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- // SpecTemplate is a template for the spec of a dynamically provisioned
- // FavouriteDBInstance.
- SpecTemplate FavouriteDBInstanceSpecTemplate `json:"specTemplate,omitempty"`
-}
-```
-
-### Resource Claim Kinds
-
-Once the underlying managed resource and its resource class have been defined
-the next step is to define the resource claim. Resource claim controllers
-typically live alongside their managed resource controllers (i.e. in an
-infrastructure stack), but at the time of writing all resource claim kinds are
-defined in Crossplane core. This is because resource claims can frequently be
-satisfied by binding to managed resources from more than one cloud. Consider
-[opening a Crossplane issue] to propose adding your new resource claim kind to
-Crossplane if it could be satisfied by managed resources from more than one
-infrastructure stack.
-
-Resource claims must:
-
-* Satisfy crossplane-runtime's [`resource.Claim`] interface.
-* Use (not embed) a [`ResourceClaimStatus`] struct as their `Status` field.
-* Embed a [`ResourceClaimSpec`] struct in their `Spec` struct.
-* Use the `+kubebuilder:subresource:status` [comment marker].
-* **Not** use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-The `FancySQLInstance` resource claim would look as follows:
-
-```go
-// A FancySQLInstanceSpec defines the desired state of a FancySQLInstance.
-type FancySQLInstanceSpec struct {
- runtimev1alpha1.ResourceClaimSpec `json:",inline"`
-
- // Resource claims typically expose few to no spec fields, instead
- // leveraging resource classes to specify detailed configuration. A resource
- // claim should only support a very small set of fields that:
- //
- // * Are applicable to every conceivable managed resource kind that might
- // ever satisfy the claim kind.
- // * Are more likely than average to be interesting to resource claim
- // authors, who frequently want to be concerned with as few configuration
- // details as possible.
-
- // Version specifies what version of FancySQL this instance will run.
- // +optional
- Version *string `json:"version,omitempty"`
-}
-
-// A FancySQLInstance is a portable resource claim that may be satisfied by
-// binding to FancySQL managed resources such as a Favourite Cloud FavouriteDB
-// instance or an Other Cloud AmbivalentDB instance.
-// +kubebuilder:subresource:status
-type FancySQLInstance struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec FancySQLInstanceSpec `json:"spec,omitempty"`
- Status runtimev1alpha1.ResourceClaimStatus `json:"status,omitempty"`
-}
-
-// SetBindingPhase of this FancySQLInstance.
-func (i *FancySQLInstance) SetBindingPhase(p runtimev1alpha1.BindingPhase) {
- i.Status.SetBindingPhase(p)
-}
-```
-
-### Provider Kinds
-
-You'll typically only need to add a new Provider kind if you're creating an
-infrastructure stack that adds support for a new infrastructure provider.
-
-Providers must:
-
-* Be named exactly `Provider`.
-* Have a `Spec` struct with a `Secret` field indicating where to find
- credentials for this provider.
-* Use the `+kubebuilder:resource:scope=Cluster` [comment marker].
-
-The Favourite Cloud `Provider` would look as follows. Note that the cloud to
-which it belongs should be indicated by its API group, i.e. its API Version
-would be `favouritecloud.crossplane.io/v1alpha1` or similar.
-
-```go
-// A ProviderSpec defines the desired state of a Provider.
-type ProviderSpec struct {
-
- // A Secret containing credentials for a Favourite Cloud Service Account
- // that will be used to authenticate to this Provider.
- Secret runtimev1alpha1.SecretKeySelector `json:"credentialsSecretRef"`
-}
-
-// A Provider configures a Favourite Cloud 'provider', i.e. a connection to a
-// particular Favourite Cloud project using a particular Favourite Cloud service
-// account.
-type Provider struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
-
- Spec ProviderSpec `json:"spec,omitempty"`
-}
-```
-
-### Finishing Touches
-
-At this point we've defined all of the resource kinds necessary to start
-building controllers - a managed resource, a resource class, and a resource
-claim. Before moving on to the controllers:
-
-* Add any kubebuilder [comment markers] that may be useful for your resource.
- Comment markers can be used to validate input, or add additional columns to
- the standard `kubectl get` output, among other things.
-* Run `make generate && make manifests` (or `make reviewable` if you're working
- in one of the projects in the [crossplaneio org]) to generate Custom Resource
- Definitions and additional helper methods for your new resource kinds.
-* Make sure any package documentation (i.e. `// Package v1alpha1...` GoDoc,
- including package level comment markers) are in a file named `doc.go`.
- kubebuilder adds them to `groupversion_info.go`, but several code generation
- tools only check `doc.go`.
-
-Finally, add convenience [`GroupVersionKind`] variables for each new resource
-kind. These are typically added to either `register.go` or
-`groupversion_info.go` depending on which version of kubebuilder scaffolded the
-API type:
-
-```go
-// FancySQLInstance type metadata.
-var (
- FancySQLInstanceKind = reflect.TypeOf(FancySQLInstance{}).Name()
- FancySQLInstanceKindAPIVersion = FancySQLInstanceKind + "." + GroupVersion.String()
- FancySQLInstanceGroupVersionKind = GroupVersion.WithKind(FancySQLInstanceKind)
-)
-```
-
-Consider opening a draft pull request and asking a Crossplane maintainer for
-review before you start work on the controller!
-
-## Adding Controllers
-
-Crossplane controllers, like those scaffolded by kubebuilder, are built around
-the [controller-runtime] library. controller-runtime flavoured controllers
-encapsulate most of their domain-specific logic in a [`reconcile.Reconciler`]
-implementation. Most Crossplane controllers are one of the three kinds mentioned
-under [What Makes a Crossplane Managed Service]. Each of these controller kinds
-are similar enough across implementations that [crossplane-runtime] provides
-'default' reconcilers. These reconcilers encode what the Crossplane community
-has learned about managing external systems and narrow the problem space from
-reconciling a Kubernetes resource kind with an arbitrary system down to
-Crossplane-specific tasks.
-
-crossplane-runtime provides the following `reconcile.Reconcilers`:
-
-* The [`resource.ManagedReconciler`] reconciles managed resources with external
- systems by instantiating a client of the external API and using it to create,
- update, or delete the external resource as necessary.
-* [`resource.ClaimSchedulingReconciler`] reconciles resource claims by
- scheduling them to a resource class that matches their class selector labels
- (if any).
-* [`resource.ClaimDefaultingReconciler`] reconciles resource claims that omit
- their class selector by defaulting them to a resource class annotated as the
- default (if any).
-* [`resource.ClaimReconciler`] reconciles resource claims with managed resources
- by either binding or dynamically provisioning and then binding them.
-* [`resource.SecretPropagatingReconciler`] reconciles secrets by propagating
- their data to another secret. This controller is typically used to ensure
- resource claim connection secrets remain in sync with the connection secrets
- of their bound managed resources.
-
-Crossplane controllers typically differ sufficiently from those scaffolded by
-kubebuilder that there is little value in using kubebuilder to generate a
-controller scaffold.
-
-### Managed Resource Controllers
-
-Managed resource controllers should use [`resource.NewManagedReconciler`] to
-wrap a managed-resource specific implementation of
-[`resource.ExternalConnecter`]. Parts of `resource.ManagedReconciler`'s
-behaviour is customisable; refer to the [`resource.NewManagedReconciler`] GoDoc
-for a list of options. The following is an example controller for the
-`FavouriteDBInstance` managed resource we defined earlier:
-
-```go
-import (
- "context"
- "fmt"
- "strings"
-
- "github.com/pkg/errors"
- corev1 "k8s.io/api/core/v1"
- "k8s.io/apimachinery/pkg/types"
- ctrl "sigs.k8s.io/controller-runtime"
- "sigs.k8s.io/controller-runtime/pkg/client"
-
- // An API client of the hypothetical FavouriteDB service.
- "github.com/fcp-sdk/v1/services/database"
-
- runtimev1alpha1 "github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1"
- "github.com/crossplaneio/crossplane-runtime/pkg/meta"
- "github.com/crossplaneio/crossplane-runtime/pkg/resource"
-
- "github.com/crossplaneio/stack-fcp/apis/database/v1alpha3"
- fcpv1alpha3 "github.com/crossplaneio/stack-fcp/apis/v1alpha3"
-)
-
-type FavouriteDBInstanceController struct{}
-
-// SetupWithManager instantiates a new controller using a resource.ManagedReconciler
-// configured to reconcile FavouriteDBInstances using an ExternalClient produced by
-// connecter, which satisfies the ExternalConnecter interface.
-func (c *FavouriteDBInstanceController) SetupWithManager(mgr ctrl.Manager) error {
- return ctrl.NewControllerManagedBy(mgr).
- Named(strings.ToLower(fmt.Sprintf("%s.%s", v1alpha3.FavouriteDBInstanceKind, v1alpha3.Group))).
- For(&v1alpha3.FavouriteDBInstance{}).
- Complete(resource.NewManagedReconciler(mgr,
- resource.ManagedKind(v1alpha3.FavouriteDBInstanceGroupVersionKind),
- resource.WithExternalConnecter(&connecter{client: mgr.GetClient()})))
-}
-
-// Connecter satisfies the resource.ExternalConnecter interface.
-type connecter struct{ client client.Client }
-
-// Connect to the supplied resource.Managed (presumed to be a
-// FavouriteDBInstance) by using the Provider it references to create a new
-// database client.
-func (c *connecter) Connect(ctx context.Context, mg resource.Managed) (resource.ExternalClient, error) {
- // Assert that resource.Managed we were passed in fact contains a
- // FavouriteDBInstance. We told NewControllerManagedBy that this was a
- // controller For FavouriteDBInstance, so something would have to go
- // horribly wrong for us to encounter another type.
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return nil, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Get the Provider referenced by the FavouriteDBInstance.
- p := &fcpv1alpha3.Provider{}
- if err := c.client.Get(ctx, meta.NamespacedNameOf(i.Spec.ProviderReference), p); err != nil {
- return nil, errors.Wrap(err, "cannot get Provider")
- }
-
- // Get the Secret referenced by the Provider.
- s := &corev1.Secret{}
- n := types.NamespacedName{Namespace: p.Namespace, Name: p.Spec.Secret.Name}
- if err := c.client.Get(ctx, n, s); err != nil {
- return nil, errors.Wrap(err, "cannot get Provider secret")
- }
-
- // Create and return a new database client using the credentials read from
- // our Provider's Secret.
- client, err := database.NewClient(ctx, s.Data[p.Spec.Secret.Key])
- return &external{client: client}, errors.Wrap(err, "cannot create client")
-}
-
-// External satisfies the resource.ExternalClient interface.
-type external struct{ client database.Client }
-
-// Observe the existing external resource, if any. The resource.ManagedReconciler
-// calls Observe in order to determine whether an external resource needs to be
-// created, updated, or deleted.
-func (e *external) Observe(ctx context.Context, mg resource.Managed) (resource.ExternalObservation, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return resource.ExternalObservation{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Use our FavouriteDB API client to get an up to date view of the external
- // resource.
- existing, err := e.client.GetInstance(ctx, i.Spec.Name)
-
- // If we encounter an error indicating the external resource does not exist
- // we want to let the resource.ManagedReconciler know so it can create it.
- if database.IsNotFound(err) {
- return resource.ExternalObservation{ResourceExists: false}, nil
- }
-
- // Any other errors are wrapped (as is good Go practice) and returned to the
- // resource.ManagedReconciler. It will update the "Synced" status condition
- // of the managed resource to reflect that the most recent reconcile failed
- // and ensure the reconcile is reattempted after a brief wait.
- if err != nil {
- return resource.ExternalObservation{}, errors.Wrap(err, "cannot get instance")
- }
-
- // The external resource exists. Copy any output-only fields to their
- // corresponding entries in our status field.
- i.Status.Status = existing.GetStatus()
- i.Status.Hostname = existing.GetHostname()
- i.Status.ID = existing.GetID()
-
- // Update our "Ready" status condition to reflect the status of the external
- // resource. Most managed resources use the below well known reasons that
- // the "Ready" status may be true or false, but managed resource authors
- // are welcome to define and use their own.
- switch i.Status.Status {
- case database.StatusOnline:
- // If the resource is available we also want to mark it as bindable to
- // resource claims.
- resource.SetBindable(i)
- i.SetConditions(runtimev1alpha1.Available())
- case database.StatusCreating:
- i.SetConditions(runtimev1alpha1.Creating())
- case database.StatusDeleting:
- i.SetConditions(runtimev1alpha1.Deleting())
- }
-
- // Finally, we report what we know about the external resource. In this
- // hypothetical case FancinessLevel is the only field that can be updated
- // after creation time, so the resource does not need to be updated if
- // the actual fanciness level matches our desired fanciness level. Any
- // ConnectionDetails we return will be published to the managed resource's
- // connection secret if it specified one.
- o := resource.ExternalObservation{
- ResourceExists: true,
- ResourceUpToDate: existing.GetFancinessLevel == i.Spec.FancinessLevel,
- ConnectionDetails: resource.ConnectionDetails{
- runtimev1alpha1.ResourceCredentialsSecretUserKey: []byte(existing.GetUsername()),
- runtimev1alpha1.ResourceCredentialsSecretEndpointKey: []byte(existing.GetHostname()),
- },
- }
-
- return o, nil
-}
-
-// Create a new external resource based on the specification of our managed
-// resource. resource.ManagedReconciler only calls Create if Observe reported
-// that the external resource did not exist.
-func (e *external) Create(ctx context.Context, mg resource.Managed) (resource.ExternalCreation, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return resource.ExternalCreation{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
- // Indicate that we're about to create the instance. Remember ExternalClient
- // authors can use a bespoke condition reason here in cases where Creating
- // doesn't make sense.
- i.SetConditions(runtimev1alpha1.Creating())
-
- // Create must return any connection details that are set or returned only
- // at creation time. The resource.ManagedReconciler will merge any details
- // with those returned during the Observe phase.
- password := database.GeneratePassword()
- cd := resource.ConnectionDetails{runtimev1alpha1.ResourceCredentialsSecretPasswordKey: []byte(password)}
-
- // Create a new instance.
- new := database.Instance{Name: i.Name, FancinessLevel: i.FancinessLevel, Version: i.Version}
- err := e.client.CreateInstance(ctx, new, password)
-
- // Note that we use resource.Ignore to squash any error that indicates the
- // external resource already exists. Create implementations must not return
- // an error if asked to create a resource that already exists. Real managed
- // resource controllers are advised to avoid unintentially 'adoptign' an
- // existing, unrelated external resource, per
- // https://github.com/crossplaneio/crossplane-runtime/issues/27
- return resource.ExternalCreation{ConnectionDetails: cd}, errors.Wrap(resource.Ignore(database.IsExists, err), "cannot create instance")
-}
-
-// Update the existing external resource to match the specifications of our
-// managed resource. resource.ManagedReconciler only calls Update if Observe
-// reported that the external resource was not up to date.
-func (e *external) Update(ctx context.Context, mg resource.Managed) (resource.ExternalUpdate, error) {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return resource.ExternalUpdate{}, errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- // Recall that FancinessLevel is the only field that we _can_ update.
- new := database.Instance{Name: i.Name, FancinessLevel: i.FancinessLevel}
- err := e.client.UpdateInstance(ctx, new)
- return resource.ExternalUpdate{}, errors.Wrap(err, "cannot update instance")
-}
-
-// Delete the external resource. resource.ManagedReconciler only calls Delete
-// when a managed resource with the 'Delete' reclaim policy has been deleted.
-func (e *external) Delete(ctx context.Context, mg resource.Managed) error {
- i, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return errors.New("managed resource is not a FavouriteDBInstance")
- }
- // Indicate that we're about to delete the instance.
- i.SetConditions(runtimev1alpha1.Deleting())
-
- // Delete the instance.
- err := e.client.DeleteInstance(ctx, i.Spec.Name)
-
- // Note that we use resource.Ignore to squash any error that indicates the
- // external resource does not exist. Delete implementations must not return
- // an error when asked to delete a non-existent external resource.
- return errors.Wrap(resource.Ignore(database.IsNotFound, err), "cannot delete instance")
-}
-```
-
-### Resource Claim Scheduling Controllers
-
-Scheduling controllers should use [`resource.NewClaimSchedulingReconciler`] to
-specify the resource claim kind it schedules and the resource class kind it
-schedules them to. Note that unlike their resource claim kinds, resource claim
-scheduling controllers are always part of the infrastructure stack that defines
-the resource class they schedule claims to. The following is an example
-controller that reconciles the `FancySQLInstance` resource claim by scheduling
-it to a `FavouriteDBInstanceClass`:
-
-```go
-import (
- "fmt"
- "strings"
-
- ctrl "sigs.k8s.io/controller-runtime"
-
- runtimev1alpha1 "github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1"
- "github.com/crossplaneio/crossplane-runtime/pkg/resource"
-
- // Note that the hypothetical FancySQL resource claim is part of Crossplane,
- // not stack-fcp, because it is (hypothetically) portable across multiple
- // infrastructure stacks.
- databasev1alpha1 "github.com/crossplaneio/crossplane/apis/database/v1alpha1"
-
- "github.com/crossplaneio/stack-fcp/apis/database/v1alpha3"
-)
-
-type PostgreSQLInstanceClaimSchedulingController struct{}
-
-// SetupWithManager instantiates a new controller using a
-// resource.ClaimSchedulingReconciler configured to reconcile FancySQLInstances
-// by scheduling them to FavouriteDBInstanceClasses.
-func (c *FancySQLInstanceClaimSchedulingController) SetupWithManager(mgr ctrl.Manager) error {
- // It's Crossplane convention to name resource claim scheduling controllers
- // "scheduler.claimkind.resourcekind.resourceapigroup", for example in this
- // case "fancysqlinstance.favouritedbinstance.fcp.crossplane.io".
- name := strings.ToLower(fmt.Sprintf("scheduler.%s.%s.%s",
- databasev1alpha1.FancySQLInstanceKind,
- v1alpha3.FavouriteDBInstanceKind,
- v1alpha3.Group))
-
- return ctrl.NewControllerManagedBy(mgr).
- Named(name).
- For(&databasev1alpha1.FancySQLInstance{}).
- WithEventFilter(resource.NewPredicates(resource.AllOf(
- // Claims must supply a class selector to be scheduled. Claims that
- // do not supply a class selector use a default resource class, if
- // one exists.
- resource.HasClassSelector(),
-
- // Claims with a class reference have either already been scheduled
- // to a resource class, or specified one explicitly.
- resource.HasNoClassReference(),
-
- // Claims with a managed resource reference are either already bound
- // to a managed resource, or are requesting to be bound to an
- // existing managed resource.
- resource.HasNoManagedResourceReference(),
- ))).
- Complete(resource.NewClaimSchedulingReconciler(mgr,
- resource.ClaimKind(databasev1alpha1.FancySQLInstanceGroupVersionKind),
- resource.ClassKind(v1alpha3.FavouriteDBInstanceClassGroupVersionKind),
- ))
-}
-```
-
-### Resource Claim Defaulting Controllers
-
-Defaulting controllers are configured almost (but not quite) identically to
-scheduling controllers. They use a [`resource.NewClaimSchedulingReconciler`] to
-specify the resource claim kind they configure and the resource class kind they
-default to. Unlike their resource claim kinds, defaulting controllers are always
-part of the infrastructure stack that defines the resource class they default
-claims to. The following is an example controller that reconciles the
-`FancySQLInstance` resource claim by setting its class reference to a
-`FavouriteDBInstanceClass` annotated as the default class:
-
-```go
-import (
- "fmt"
- "strings"
-
- ctrl "sigs.k8s.io/controller-runtime"
-
- runtimev1alpha1 "github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1"
- "github.com/crossplaneio/crossplane-runtime/pkg/resource"
-
- // Note that the hypothetical FancySQL resource claim is part of Crossplane,
- // not stack-fcp, because it is (hypothetically) portable across multiple
- // infrastructure stacks.
- databasev1alpha1 "github.com/crossplaneio/crossplane/apis/database/v1alpha1"
-
- "github.com/crossplaneio/stack-fcp/apis/database/v1alpha3"
-)
-
-type PostgreSQLInstanceClaimDefaultingController struct{}
-
-// SetupWithManager instantiates a new controller using a
-// resource.ClaimDefaultingReconciler configured to reconcile FancySQLInstances
-// by scheduling them to FavouriteDBInstanceClasses.
-func (c *FancySQLInstanceClaimDefaultingController) SetupWithManager(mgr ctrl.Manager) error {
- // It's Crossplane convention to name resource claim scheduling controllers
- // "defaulter.claimkind.resourcekind.resourceapigroup", for example in this
- // case "fancysqlinstance.favouritedbinstance.fcp.crossplane.io".
- name := strings.ToLower(fmt.Sprintf("scheduler.%s.%s.%s",
- databasev1alpha1.FancySQLInstanceKind,
- v1alpha3.FavouriteDBInstanceKind,
- v1alpha3.Group))
-
- return ctrl.NewControllerManagedBy(mgr).
- Named(name).
- For(&databasev1alpha1.FancySQLInstance{}).
- WithEventFilter(resource.NewPredicates(resource.AllOf(
- // Claims with a class selector desire scheduling to a matching
- // resource class, and are not subject to defaulting.
- resource.HasNoClassSelector(),
-
- // Claims with a class reference have either already been scheduled
- // to a resource class, or specified one explicitly.
- resource.HasNoClassReference(),
-
- // Claims with a managed resource reference are either already bound
- // to a managed resource, or are requesting to be bound to an
- // existing managed resource.
- resource.HasNoManagedResourceReference(),
- ))).
- Complete(resource.NewClaimDefaultingReconciler(mgr,
- resource.ClaimKind(databasev1alpha1.FancySQLInstanceGroupVersionKind),
- resource.ClassKind(v1alpha3.FavouriteDBInstanceClassGroupVersionKind),
- ))
-}
-```
-
-### Resource Claim Controllers
-
-Resource claim controllers should use [`resource.NewClaimReconciler`] to wrap a
-managed-resource specific implementation of [`resource.ManagedConfigurator`].
-Parts of `resource.ClaimReconciler`'s behaviour is customisable; refer to the
-[`resource.NewClaimReconciler`] GoDoc for a list of options. Note that unlike
-their resource claim kinds, resource claim controllers are always part of the
-infrastructure stack that defines the managed resource they reconcile claims
-with. The following is an example controller that reconciles the
-`FancySQLInstance` resource claim with the `FavouriteDBInstance` managed
-resource:
-
-```go
-import (
- "context"
- "fmt"
- "strings"
-
- "github.com/pkg/errors"
- corev1 "k8s.io/api/core/v1"
- ctrl "sigs.k8s.io/controller-runtime"
- "sigs.k8s.io/controller-runtime/pkg/source"
-
- runtimev1alpha1 "github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1"
- "github.com/crossplaneio/crossplane-runtime/pkg/resource"
-
- // Note that the hypothetical FancySQL resource claim is part of Crossplane,
- // not stack-fcp, because it is (hypothetically) portable across multiple
- // infrastructure stacks.
- databasev1alpha1 "github.com/crossplaneio/crossplane/apis/database/v1alpha1"
-
- "github.com/crossplaneio/stack-fcp/apis/database/v1alpha3"
-)
-
-type FavouriteDBInstanceClaimController struct{}
-
-// SetupWithManager instantiates a new controller using a resource.ClaimReconciler
-// configured to reconcile FancySQLInstances by binding them to FavouriteDBInstances.
-func (c *FavouriteDBInstanceClaimController) SetupWithManager(mgr ctrl.Manager) error {
- // It's Crossplane convention to name resource claim controllers
- // "claimkind.resourcekind.resourceapigroup", for example in this case
- // "fancysqlinstance.favouritedbinstance.fcp.crossplane.io".
- name := strings.ToLower(fmt.Sprintf("%s.%s.%s",
- databasev1alpha1.FancySQLInstanceKind,
- v1alpha3.FavouriteDBInstanceKind,
- v1alpha3.Group))
-
- // The controller below watches for changes to both FancySQLInstance and
- // FavouriteDBInstance kind resources. We use watch predicates to filter
- // out any requests to reconcile resources that we're not interested in.
- p := resource.NewPredicates(resource.AnyOf(
- // We want to reconcile FancySQLInstance kind resource claims that
- // reference a FavouriteDBInstanceClass.
- resource.HasClassReferenceKind(resource.ClassKind(v1alpha3.FavouriteDBInstanceClassGroupVersionKind),
-
- // We want to reconcile FancySQLInstance kind resource claims that
- // explicitly set their .spec.resourceRef to a FavouriteDBInstance kind
- // managed resource.
- resource.HasManagedResourceReferenceKind(resource.ManagedKind(v1alpha3.FavouriteDBInstanceGroupVersionKind)),
-
- // We want to reconcile FavouriteDBInstance managed resources. Resources
- // without a claim reference will be filtered by the below
- // EnqueueRequestForClaim watch event handler.
- resource.IsManagedKind(resource.ManagedKind(v1alpha3.FavouriteDBInstanceClassGroupVersionKind), mgr.GetScheme()),
- ))
-
- // Create a new resource claim reconciler...
- r := resource.NewClaimReconciler(mgr,
- // ..that uses the supplied claim, class, and managed resource kinds.
- resource.ClaimKind(databasev1alpha1.FancySQLInstanceGroupVersionKind),
- resource.ClassKind(v1alpha3.FavouriteDBInstanceClassGroupVersionKind),
- resource.ManagedKind(v1alpha3.FavouriteDBInstanceGroupVersionKind),
- // The resource claim reconciler assumes managed resources do not
- // use the status subresource for compatibility with older managed
- // resource kinds, so well behaved resources must explicitly tell the
- // reconciler to update the status subresource per
- // https://github.com/crossplaneio/crossplane-runtime/issues/29
- resource.WithManagedBinder(resource.NewAPIManagedStatusBinder(mgr.GetClient())),
- resource.WithManagedFinalizer(resource.NewAPIManagedStatusUnbinder(mgr.GetClient())),
- // The following configurators configure how a managed resource will be
- // configured when one must be dynamically provisioned.
- resource.WithManagedConfigurators(
- resource.ManagedConfiguratorFn(ConfigureFavouriteDBInstance),
- resource.NewObjectMetaConfigurator(mgr.GetScheme()),
- ))
-
- // Note that we watch for both FancySQLInstance and FavouriteDBInstance
- // resources. When the latter passes our predicates we look up the resource
- // claim it references and reconcile that claim.
- return ctrl.NewControllerManagedBy(mgr).
- Named(name).
- Watches(&source.Kind{Type: &v1alpha3.FavouriteDBInstance{}}, &resource.EnqueueRequestForClaim{}).
- For(&databasev1alpha1.FancySQLInstance{}).
- WithEventFilter(p).
- Complete(r)
-}
-
-// ConfigureFavouriteDBInstance is responsible for updating the supplied managed
-// resource using the supplied resource class.
-func ConfigureFavouriteDBInstance(_ context.Context, cm resource.Claim, cs resource.Class, mg resource.Managed) error {
- if _, ok := cm.(*databasev1alpha1.FancySQLInstance); !ok {
- return errors.New("resource claim is not a FancySQLInstance")
- }
-
- class, ok := cs.(*v1alpha3.FavouriteDBInstanceClass)
- if !ok {
- return errors.New("resource class is not a FavouriteDBInstanceClass")
- }
-
- instance, ok := mg.(*v1alpha3.FavouriteDBInstance)
- if !ok {
- return errors.New("managed resource is not a FavouriteDBInstance")
- }
-
- instance.Spec = v1alpha3.FavouriteDBInstanceSpec{
- ResourceSpec: runtimev1alpha1.ResourceSpec{
- // It's typical for dynamically provisioned managed resources to
- // store their connection details in a Secret named for the claim's
- // UID. Managed resource secrets are not intended for human
- // consumption; they're copied to the resource claim's secret when
- // the resource is bound.
- WriteConnectionSecretToReference: runtimev1alpha1.SecretReference{
- Namespace: class.SpecTemplate.WriteConnectionSecretsToNamespace,
- Name: string(cm.GetUID()),
- },
- ProviderReference: class.SpecTemplate.ProviderReference,
- ReclaimPolicy: class.SpecTemplate.ReclaimPolicy,
- },
- FavouriteDBInstanceParameters: class.SpecTemplate.FavouriteDBInstanceParameters,
- }
-
- return nil
-}
-```
-
-### Connection Secret Propagation Controller
-
-Managed resource kinds that may update their connection secrets after creation
-time must instantiate a connection secret propagation controller. This
-controller ensures any updates to the managed resource's connection secret are
-propagated to the connection secret of its bound resource claim. The resource
-claim reconciler ensures managed resource and resource claim secrets are
-eligible for use with by the secret propagatation controller by adding the
-appropriate annotations and controller references.
-
-The following controller propagates any changes made to a `FavouriteDBInstance`
-connection secret to the connection secret of its bound `FancySQLInstance`:
-
-```go
-import (
- "fmt"
- "strings"
-
- corev1 "k8s.io/api/core/v1"
- ctrl "sigs.k8s.io/controller-runtime"
- "sigs.k8s.io/controller-runtime/pkg/source"
-
- "github.com/crossplaneio/crossplane-runtime/pkg/resource"
- databasev1alpha1 "github.com/crossplaneio/crossplane/apis/database/v1alpha1"
-
- "github.com/crossplaneio/stack-fcp/apis/database/v1alpha3"
-)
-
-type FavouriteDBInstanceSecretController struct{}
-
-func (c *FavouriteDBInstanceSecretController) SetupWithManager(mgr ctrl.Manager) error {
- p := resource.NewPredicates(resource.AnyOf(
- resource.AllOf(resource.IsControlledByKind(databasev1alpha1.FancySQLInstanceGroupVersionKind), resource.IsPropagated()),
- resource.AllOf(resource.IsControlledByKind(v1alpha3.FavouriteDBInstanceGroupVersionKind), resource.IsPropagator()),
- ))
-
- return ctrl.NewControllerManagedBy(mgr).
- Named(strings.ToLower(fmt.Sprintf("connectionsecret.%s.%s", v1alpha3.FavouriteDBInstanceKind, v1alpha3.Group))).
- Watches(&source.Kind{Type: &corev1.Secret{}}, &resource.EnqueueRequestForPropagator{}).
- For(&corev1.Secret{}).
- WithEventFilter(p).
- Complete(resource.NewSecretPropagatingReconciler(mgr))
-}
-```
-
-### Wrapping Up
-
-Once all your controllers are in place you'll want to test them. Note that most
-projects under the [crossplaneio org] [favor] table driven tests that use Go's
-standard library `testing` package over kubebuilder's Gingko based tests.
-
-Finally, don't forget to plumb any newly added resource kinds and controllers up
-to your controller manager. Simple stacks may do this for each type within
-within `main()`, but most more complicated stacks take an approach in which each
-package exposes an `AddToScheme` (for resource kinds) or `SetupWithManager` (for
-controllers) function that invokes the same function within its child packages,
-resulting in a `main.go` like:
-
-```go
-import (
- "time"
-
- "sigs.k8s.io/controller-runtime/pkg/client/config"
- "sigs.k8s.io/controller-runtime/pkg/manager"
- "sigs.k8s.io/controller-runtime/pkg/runtime/signals"
-
- "github.com/crossplaneio/crossplane/apis"
-
- fcpapis "github.com/crossplaneio/stack-fcp/apis"
- "github.com/crossplaneio/stack-fcp/pkg/controller"
-)
-
-func main() {
- cfg, err := config.GetConfig()
- if err != nil {
- panic(err)
- }
-
- mgr, err := manager.New(cfg, manager.Options{SyncPeriod: 1 * time.Hour})
- if err != nil {
- panic(err)
- }
-
- if err := apis.AddToScheme(mgr.GetScheme()); err != nil {
- panic(err)
- }
-
- if err := fcpapis.AddToScheme(mgr.GetScheme()); err != nil {
- panic(err)
- }
-
- if err := controller.SetupWithManager(mgr); err != nil {
- panic(err)
- }
-
- panic(mgr.Start(signals.SetupSignalHandler()))
-}
-```
-
-## In Review
-
-In this guide we walked through the process of defining all of the resource
-kinds and controllers necessary to build support for a new managed service;
-possibly even a completely new infrastructure stack. Please do not hesitate to
-[reach out] to the Crossplane maintainers and community for help designing and
-implementing support for new managed services. [#sig-services] would highly
-value any feedback you may have about the services development process!
-
-[What Makes a Crossplane Managed Service]: #what-makes-a-crossplane-managed-service
-[managed resource]: concepts.md#managed-resource
-[resource claim]: concepts.md#resource-claim
-[resource class]: concepts.md#resource-class
-[dynamic provisioning]: concepts.md#dynamic-and-static-provisioning
-[`CloudMemorystoreInstance`]: https://github.com/crossplaneio/stack-gcp/blob/42ebb8b71/gcp/apis/cache/v1beta1/cloudmemorystore_instance_types.go#L146
-[`CloudMemorystoreInstanceClass`]: https://github.com/crossplaneio/stack-gcp/blob/42ebb8b71/gcp/apis/cache/v1beta1/cloudmemorystore_instance_types.go#L237
-[`Provider`]: https://github.com/crossplaneio/stack-gcp/blob/24ab7381b/gcp/apis/v1alpha3/types.go#L37
-[`RedisCluster`]: https://github.com/crossplaneio/crossplane/blob/3c6cf4e/apis/cache/v1alpha1/rediscluster_types.go#L40
-[`RedisClusterClass`]: https://github.com/crossplaneio/crossplane/blob/3c6cf4e/apis/cache/v1alpha1/rediscluster_types.go#L116
-[watching the API server]: https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
-[kubebuilder]: https://kubebuilder.io/
-[controller-runtime]: https://github.com/kubernetes-sigs/controller-runtime
-[crossplane-runtime]: https://github.com/crossplaneio/crossplane-runtime/
-[golden path]: https://charity.wtf/2018/12/02/software-sprawl-the-golden-path-and-scaling-teams-with-agency/
-[API Conventions]: https://github.com/kubernetes/community/blob/c6e1e89a/contributors/devel/sig-architecture/api-conventions.md
-[kubebuilder book]: https://book.kubebuilder.io/
-[Stacks quick start]: https://github.com/crossplaneio/crossplane-cli/blob/357d18e7b/README.md#quick-start-stacks
-[resources]: https://kubebuilder.io/cronjob-tutorial/gvks.html#kinds-and-resources
-[kinds]: https://kubebuilder.io/cronjob-tutorial/gvks.html#kinds-and-resources
-[objects]: https://kubernetes.io/docs/concepts/#kubernetes-objects
-[comment marker]: https://kubebuilder.io/reference/markers.html
-[comment markers]: https://kubebuilder.io/reference/markers.html
-[`resource.Managed`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#Managed
-[`resource.Claim`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#Claim
-[`resource.Class`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#Class
-[`resource.ManagedReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#ManagedReconciler
-[`resource.NewManagedReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#NewManagedReconciler
-[`resource.ClaimReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#ClaimReconciler
-[`resource.NewClaimReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#NewClaimReconciler
-[`resource.ClaimSchedulingReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#ClaimSchedulingReconciler
-[`resource.NewClaimSchedulingReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#NewClaimSchedulingReconciler
-[`resource.ClaimDefaultingReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#ClaimDefaultingReconciler
-[`resource.NewClaimDefaultingReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#NewClaimDefaultingReconciler
-[`resource.SecretPropagatingReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#SecretPropagatingReconciler
-[`resource.NewSecretPropagatingReconciler`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#NewSecretPropagatingReconciler
-[`resource.ExternalConnecter`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#ExternalConnecter
-[`resource.ExternalClient`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#ExternalClient
-[`resource.ManagedConfigurator`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#ManagedConfigurator
-[`ResourceSpec`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1#ResourceSpec
-[`ResourceStatus`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1#ResourceStatus
-[`ResourceClaimSpec`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1#ResourceClaimSpec
-[`ResourceClaimStatus`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1#ResourceClaimStatus
-[`ClassSpecTemplate`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/apis/core/v1alpha1#ClassSpecTemplate
-['resource.ExternalConnecter`]: https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/resource#ExternalConnecter
-[opening a Crossplane issue]: https://github.com/crossplaneio/crossplane/issues/new/choose
-[`GroupVersionKind`]: https://godoc.org/k8s.io/apimachinery/pkg/runtime/schema#GroupVersionKind
-[`reconcile.Reconciler`]: https://godoc.org/sigs.k8s.io/controller-runtime/pkg/reconcile#Reconciler
-[favor]: https://github.com/crossplaneio/crossplane/issues/452
-[reach out]: https://github.com/crossplaneio/crossplane#contact
-[#sig-services]: https://crossplane.slack.com/messages/sig-services
-[crossplaneio org]: https://github.com/crossplaneio
-[`angryjet`]: https://github.com/crossplaneio/crossplane-tools
-[Managed Resource API Patterns]: ../design/one-pager-managed-resource-api-design.md
\ No newline at end of file
diff --git a/docs/v0.4/services-guide.md b/docs/v0.4/services-guide.md
deleted file mode 100644
index 054ee1de..00000000
--- a/docs/v0.4/services-guide.md
+++ /dev/null
@@ -1,143 +0,0 @@
----
-title: Services Guide
-toc: true
-weight: 410
----
-
-# Services Guide
-This guide is an overview of enabling cloud service provisioning on an existing
-Kubernetes target cluster, including how to integrate Crossplane with existing
-cloud networking configurations to provide secure managed service connectivity.
-Step-by-step instructions are provided for [GCP][gcp-services-guide],
-[AWS][aws-services-guide], and [Azure][azure-services-guide].
-
-To dynamically provision a new Kubernetes target cluster see the Stacks Guides
-for [GCP][stack-guide-gcp], [AWS][stack-guide-aws], and
-[Azure][stack-guide-azure].
-
-## Table of Contents
-1. [Introduction](#introduction)
-1. [Secure network connectivity for cloud
- services](#secure-network-connectivity-for-cloud-services)
-1. [Dynamic provisioning with claims and
- classes](#dynamic-provisioning-with-claims-and-classes)
-1. [Connection secrets for pods in a
- deployment](#connection-secrets-for-pods-in-a-deployment)
-1. [Next Steps](#next-steps)
-1. [Learn More](#learn-more)
-
-## Introduction
-Cloud service provisioning can be added to existing clusters by
-installing Crossplane directly onto the target cluster. Crossplane is designed
-to integrate with existing cloud networking and security resources, so managed
-services like RDS, CloudSQL, and Azure DB can be provisioned using Kubernetes
-objects and securely consumed by pods in a cluster.
-
-Crossplane achieves this by:
-1. establishing secure network connectivity between the worker nodes in a
- cluster and cloud services
-1. populating Kuberentes `Secrets` that pods in a `Deployment` can use to
- securely access the managed service
-
-## Secure network connectivity for cloud services
-Crossplane currently supports private IP secure connectivity for AWS, GCP, and
-Azure Stacks. Managed services instances are made available on the cluster's
-prviate network(s) so pods can access them. Crossplane also supports
-configuring ingress/egress rules to further restrict allowed network traffic.
-
-While each cloud provider uses different resources for establishing secure
-connectivity between a Kubernetes cluster (EKS, GKE, AKS) and managed services
-(RDS, CloudSQL, and Azure DB), the basic pattern is the same:
-1. Configure cluster networking
- * network(s) and subnet(s) - L3 networking for the worker nodes
-1. Enable managed service access:
- * private service connection / endpoint - make services available via
- peering or other
- * private IP range(s) or subnet group - the private IPs a managed service
- will get
- * security groups or network rules - to restrict network traffic
-1. Provision a managed service instance
- * creates an instance e.g. MySQL from RDS, CloudSQL, or Azure DB
- * assigns a private IP from the private IP range above
-1. Securely use the managed service with secrets
- * pods on a cluster node can access the managed service via private IP
- * pods use credentials to securely connect to a managed service
-
-Crossplane provides Kubernetes resources for all of the above, so you can define
-a secure connectivity model for the managed services you want to make available
-for self-service provisioning in the cluster using claims and classes.
-
-## Dynamic provisioning with claims and classes
-Crossplane employs a layered architecture consisting of managed resources that
-represent a cloud service, and resource claims and classes that enable dynamic
-provisioning of those services.
-
-Managed resources are high fidelity representations of the API resources that
-make up a cloud service. They're not portable across clouds. A
-`CloudSQLInstance` is an example of a managed resource - it's relevant only to
-the Google Cloud Platform (GCP) and exposes all of the nitty gritty
-configuration details of a CloudSQL instance. The networking and security
-Kubernetes resources mentioned above fall into this category.
-
-Resource claims and classes are the next layer up. Resource claims like
-`MySQLInstance` enable dynamic provisioning of managed resources by matching a
-claim to a class like a `CloudSQLInstanceClass` that provides the detailed
-configuration template to provision a new cloud service instance. Resource
-classes can reference secure connectivity resources (networks), such that new
-instances of that class can be made available on the cluster's private network.
-Resource classes, cluster networking, and secure connectivity resources are
-designed to work together to enable self-service provisioning of securely
-connected cloud services in a Kubernetes cluster.
-
-Resource claims can be matched to a class in several ways:
-1. rely on a class marked `resourceclass.crossplane.io/is-default-class:
-"true"`
-1. match on class labels using a `claim.spec.classSelector`
-1. use a `claim.spec.classRef` to a specific class
-
-The first two methods rely on a default class of service or use a
-`classSelector` that matches any suitable resource class available in the
-target cluster. As such, the first two methods are considered portable
-resource claims that can be used in any cluster that provides the desired class
-of service. You may have one cluster using GCP and another cluster using AWS,
-and the same claim can be used in either cluster so long as the claim can be
-matched to a suitable class of cloud service.
-
-The third method uses an explicit `classRef` to a specific resource class like
-a `CloudSQLInstanceClass` which means the claim may only be used with that
-class. Since resource classes are specific to a single cloud, claims that use
-a `classRef` are not portable across different cloud providers.
-
-## Connection secrets for pods in a deployment
-Resource claims automatically write a connection secret that pods in a
-deployment can use to securely access the underlying cloud service. The claim's
-`writeConnectionSecretToRef` field is used to specify the name of the secret
-that should be created, which can then be used in the deployment's
-configuration. Since the claim is created in Kubernetes, and the secret is
-automatically populated by Crossplane, all cloud service secrets are managed
-automatically without leaving Kubernetes.
-
-## Next steps
-Step-by-step instructions for enabling cloud service provisioning on an
-existing cluster are provided in the service guides for:
-* [GCP][gcp-services-guide]
-* [AWS][aws-services-guide]
-* [Azure][azure-services-guide]
-
-### Learn More
-* [Join Crossplane Slack][join-crossplane-slack]
-* [Contact Us][contact-us]
-* [Learn More][learn-more]
-
-
-[gcp-services-guide]: services/gcp-services-guide.md
-[aws-services-guide]: services/aws-services-guide.md
-[azure-services-guide]: services/azure-services-guide.md
-
-[stack-guide-gcp]: stacks-guide-gcp.md
-[stack-guide-aws]: stacks-guide-aws.md
-[stack-guide-azure]: stacks-guide-azure.md
-
-[contact-us]: https://github.com/crossplaneio/crossplane#contact
-[join-crossplane-slack]: https://slack.crossplane.io
-[learn-more]: learn-more.md
diff --git a/docs/v0.4/services/aws-services-guide.md b/docs/v0.4/services/aws-services-guide.md
deleted file mode 100644
index e97883ae..00000000
--- a/docs/v0.4/services/aws-services-guide.md
+++ /dev/null
@@ -1,461 +0,0 @@
----
-title: Using AWS Services
-toc: true
-weight: 430
-indent: true
----
-
-# AWS Services Guide
-
-This user guide will walk you through Wordpress application deployment using
-Crossplane managed resources and the official Wordpress Docker image.
-
-## Table of Contents
-
-1. [Pre-requisites](#pre-requisites)
-1. [Preparation](#preparation)
-1. [Set Up Crossplane](#set-up-crossplane)
- 1. [Install in Target Cluster](#install-in-target-cluster)
- 1. [Cloud Provider](#cloud-provider)
- 1. [Configure Managed Service Access](#configure-managed-service-access)
- 1. [Resource Classes](#resource-classes)
-1. [Provision MySQL](#provision-mysql)
- 1. [Resource Claim](#resource-claim)
-1. [Install Wordpress](#install-wordpress)
-1. [Clean Up](#clean-up)
-1. [Conclusion and Next Steps](#conclusion-and-next-steps)
-
-## Pre-requisites
-
-These tools are required to complete this guide. They must be installed on your
-local machine.
-
-* [kubectl][install-kubectl]
-* [Helm][using-helm], minimum version `v2.10.0+`.
-
-## Preparation
-
-This guide assumes that you have already [installed][aws-cli-install] and
-[configured][aws-cli-configure]. It also assumes an existing EKS cluster,
-configured in a VPC with three public subnets (i.e. exposed to the internet).
-
-In order to utilize these pre-existing resources, set environment variables that
-can be used when creating resources necessary to deploy Wordpress.
-
-```bash
-export CLUSTER_NAME=yourclustername
-export REGION=yourclusterregion
-export VPC_ID=yourvpcid
-export SUBNET_ONE_ID=yourpublicsubnetoneid
-export SUBNET_TWO_ID=yourpublicsubnettwoid
-export SUBNET_THREE_ID=yourpublicsubnetthreeid
-```
-
-## Set Up Crossplane
-
-To keep your resource configuration organized, start by creating a new
-directory:
-
-```bash
-mkdir wordpress && cd $_
-```
-
-### Install in Target Cluster
-
-Assuming you are [connected][eks-kubectl] to your EKS cluster via `kubectl`:
-
-1. Install Crossplane from alpha channel. (See the [Crossplane Installation
- Guide][crossplane-install] for more information.)
-
-```bash
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-2. Install the AWS stack into Crossplane. (See the [AWS stack
- section][aws-stack-install] of the install guide for more information.)
-
-```bash
-cat > stack-aws.yaml < aws-dbsubnet.yaml < aws-sg.yaml < aws-mysql-standard.yaml < rdsinstanceclass.database.aws.crossplane.io/aws-mysql-standard created
-
-* You can verify creation with the following command and output:
-
-```bash
-$ kubectl get rdsinstanceclasses.database.aws.crossplane.io
-NAME PROVIDER-REF RECLAIM-POLICY AGE
-standard-mysql aws-provider Delete 11s
-```
-
-You are free to create more AWS `RDSInstanceClass` instances to define more
-potential configurations. For instance, you may create `large-aws-rds` with
-field `size: 100`.
-
-## Provision MySQL
-
-### Resource Claims
-
-Resource claims are used for dynamic provisioning of a managed resource (like a
-MySQL instance) by matching the claim to a resource class. This can be done in
-several ways: (a) rely on the default class marked
-`resourceclass.crossplane.io/is-default-class: "true"`, (b) use a
-`claim.spec.classRef` to a specific class, or (c) match on class labels using a
-`claim.spec.classSelector`.
-
-*Note: claims may also be used in [static provisioning] with a reference to an
-existing managed resource.*
-
-In the `RDSInstanceClass` above, we added the default annotation, so our claim
-will default to it automatically if no other classes exist with said annotation.
-If there are multiple classes annotated as default, one will be chosen at
-random.
-
-* Define a `MySQLInstance` claim in `mysql-claim.yaml` and create it:
-
-```bash
-cat > mysql-claim.yaml <
-Annotations: kubectl.kubernetes.io/last-applied-configuration:
- {"apiVersion":"database.crossplane.io/v1alpha1","kind":"MySQLInstance","metadata":{"annotations":{},"name":"mysql-claim","namespace":"defa...
-API Version: database.crossplane.io/v1alpha1
-Kind: MySQLInstance
-Metadata:
- Creation Timestamp: 2019-10-24T19:59:18Z
- Finalizers:
- finalizer.resourceclaim.crossplane.io
- Generation: 3
- Resource Version: 6425
- Self Link: /apis/database.crossplane.io/v1alpha1/namespaces/default/mysqlinstances/mysql-claim
- UID: c3aca763-f698-11e9-a957-12a4af141bea
-Spec:
- Class Ref:
- API Version: database.aws.crossplane.io/v1beta1
- Kind: RDSInstanceClass
- Name: standard-mysql
- UID: 6cf90617-f698-11e9-b058-028a0ecde201
- Engine Version: 5.6
- Resource Ref:
- API Version: database.aws.crossplane.io/v1beta1
- Kind: RDSInstance
- Name: app-project1-dev-mysql-claim-8shd2
- Write Connection Secret To Ref:
- Name: wordpressmysql
-Status:
- Conditions:
- Last Transition Time: 2019-10-24T19:59:20Z
- Reason: Managed claim is waiting for managed resource to become bindable
- Status: False
- Type: Ready
- Last Transition Time: 2019-10-24T19:59:20Z
- Reason: Successfully reconciled managed resource
- Status: True
- Type: Synced
-Events:
-```
-
-## Install Wordpress
-
-Installing Wordpress requires creating a Kubernetes `Deployment` and load
-balancer `Service`. We will point the deployment to the `wordpressmysql` secret
-that we specified in our claim above for the Wordpress container environment
-variables. It should have been populated with our MySQL connection details after
-the claim became `Bound`.
-
-* Check to make sure `wordpressmysql` exists and is populated:
-
-```bash
-$ kubectl describe secret wordpressmysql
-Name: wordpressmysql
-Namespace: default
-Labels:
-Annotations: crossplane.io/propagate-from-name: c3aca763-f698-11e9-a957-12a4af141bea
- crossplane.io/propagate-from-namespace: crossplane-system
- crossplane.io/propagate-from-uid: c539fcef-f698-11e9-a957-12a4af141bea
-
-Type: Opaque
-
-Data
-====
-endpoint: 83 bytes
-password: 27 bytes
-username: 10 bytes
-```
-
-* Define the `Deployment` and `Service` in `wordpress-app.yaml` and create it:
-
-```bash
-cat > wordpress-app.yaml <`, wait until it
-becomes available, then navigate to the address. You should see the following:
-
-
-
-## Clean Up
-
-Because we put all of our configuration in a single directory, we can delete it
-all with this command:
-
-```bash
-kubectl delete -f wordpress/
-```
-
-If you would like to also uninstall Crossplane and the AWS stack, run the
-following command:
-
-```bash
-kubectl delete namespace crossplane-system
-```
-
-## Conclusion and Next Steps
-
-In this guide we:
-
-* Configured RDS to communicate with EKS
-* Installed Crossplane from the alpha channel
-* Installed the AWS stack
-* Setup an AWS `Provider` with our account
-* Created a `RDSInstanceClass` with configuration for an AWS RDS instance
-* Created a `MySQLInstance` claim that was defaulted to the `mysql-standard`
- resource class
-* Created a `Deployment` and `Service` to run Wordpress on our EKS Cluster and
- assign an external IP address to it
-
-If you would like to try out a similar workflow using a different cloud
-provider, take a look at the other [services guides][services]. If you would
-like to learn more about stacks, checkout the [stacks guide][stacks].
-
-
-[install-kubectl]: https://kubernetes.io/docs/tasks/tools/install-kubectl/
-[using-helm]: https://docs.helm.sh/using_helm/
-[crossplane-install]: ../install-crossplane.md#alpha
-[cloud-creds]: ../cloud-providers.md
-[aws-provider-guide]: ../cloud-providers/aws/aws-provider.md
-[aws-rds]: https://aws.amazon.com/rds/
-[services]: ../services-guide.md
-[stacks]: ../stacks-guide.md
-[aws-stack-install]: ../install-crossplane.md#aws-stack
-[eks-kubectl]: https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html
-[static provisioning]: ../concepts.md#dynamic-and-static-provisioning
diff --git a/docs/v0.4/services/azure-services-guide.md b/docs/v0.4/services/azure-services-guide.md
deleted file mode 100644
index f26c4d3b..00000000
--- a/docs/v0.4/services/azure-services-guide.md
+++ /dev/null
@@ -1,480 +0,0 @@
----
-title: Using Azure Services
-toc: true
-weight: 440
-indent: true
----
-
-# Azure Services Guide
-
-This user guide will walk you through Wordpress application deployment using
-Crossplane managed resources and the official Wordpress Docker image.
-
-## Table of Contents
-
-1. [Pre-requisites](#pre-requisites)
-1. [Preparation](#preparation)
-1. [Set Up Crossplane](#set-up-crossplane)
- 1. [Install in Target Cluster](#install-in-target-cluster)
- 1. [Cloud Provider](#cloud-provider)
- 1. [Resource Classes](#resource-classes)
- 1. [Configure Managed Service Access](#configure-managed-service-access)
-1. [Provision MySQL](#provision-mysql)
- 1. [Resource Claim](#resource-claim)
- 1. [Virtual Network Rule](#virtual-network-rule)
-1. [Install Wordpress](#install-wordpress)
-1. [Clean Up](#clean-up)
-1. [Conclusion and Next Steps](#conclusion-and-next-steps)
-
-## Pre-requisites
-
-These tools are required to complete this guide. They must be installed on your
-local machine.
-
-* [Azure CLI][azure-cli]
- * Make sure to [login][azure-login] after installation.
-* [kubectl][install-kubectl]
- * kubectl also be installed using the Azure CLI: `az aks install-cli`
-* [Helm][using-helm], minimum version `v2.10.0+`.
-* [jq][jq-docs] - command line JSON processor `v1.5+`
-
-
-## Preparation
-
-This guide assumes that you have setup the Azure CLI and are logged in to your
-desired account. It also assumes that you have an existing AKS cluster in a
-Virtual Network. Make sure to populate the environment variables below with the
-relevant values for your AKS cluster.
-
-*Note: environment variables are used throughout this guide.*
-
-```bash
-export AKS_RESOURCE_GROUP=myAKSResourceGroup
-export AKS_VNET=myAKSVnet
-export AKS_NAME=myAKSName
-export AKS_REGION=myRegion
-export SUBSCRIPTION_ID=$(az account list | jq -j '.[0].id')
-```
-
-## Set Up Crossplane
-
-### Install in Target Cluster
-
-Assuming you are [connected][aks-kubectl] to your AKS cluster via `kubectl`:
-
-1. Install Crossplane from alpha channel. (See the [Crossplane Installation
- Guide][crossplane-install] for more information.)
-
-```bash
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-2. Install the Azure stack into Crossplane. (See the [Azure stack
- section][azure-stack-install] of the install guide for more information.)
-
-```yaml
-cat > stack-azure.yaml < azure-mysql-standard.yaml < sqlserverclass.database.azure.crossplane.io/azure-mysql-standard created
-
-
-* You can verify creation with the following command and output:
-
-```bash
-$ kubectl get sqlserverclasses
-NAME PROVIDER-REF RECLAIM-POLICY AGE
-azure-mysql-standard azure-provider Delete 17s
-```
-
-You are free to create more Azure `SQLServerClass` instances to define more
-potential configurations. For instance, you may create `large-azure-mysql` with
-field `storageGB: 100`.
-
-### Configure Managed Service Access
-
-In order for the AKS cluster to talk to the MySQL Database, you must condigure a
-`Microsoft.Sql` service endpoint on the AKS Virtual Network for all subnets. If
-you do not already have this configured, Azure has a [guide][service endpoint]
-on how to set it up.
-
-## Provision MySQL
-
-### Resource Claims
-
-Resource claims are used for dynamic provisioning of a managed resource (like a
-MySQL instance) by matching the claim to a resource class. This can be done in
-several ways: (a) rely on the default class marked
-`resourceclass.crossplane.io/is-default-class: "true"`, (b) use a
-`claim.spec.classRef` to a specific class, or (c) match on class labels using a
-`claim.spec.classSelector`.
-
-*Note: claims may also be used in [static provisioning] with a reference to an
-existing managed resource.*
-
-In the `SQLServerClass` above, we added the labels `size: standard` and `demo:
-"true"`, so our claim will be scheduled to that class using the labels are
-specified in the `claim.spec.classSelector`. If there are multiple classes which
-match the specified label(s) one will be chosen at random.
-
-* Define a `MySQLInstance` claim in `mysql-claim.yaml` and create it:
-
-```yaml
-cat > mysql-claim.yaml <
-Annotations: kubectl.kubernetes.io/last-applied-configuration:
- {"apiVersion":"database.crossplane.io/v1alpha1","kind":"MySQLInstance","metadata":{"annotations":{},"name":"mysql-claim","namespace":"defa...
-API Version: database.crossplane.io/v1alpha1
-Kind: MySQLInstance
-Metadata:
- Creation Timestamp: 2019-10-28T15:43:28Z
- Finalizers:
- finalizer.resourceclaim.crossplane.io
- Generation: 3
- Resource Version: 11072
- Self Link: /apis/database.crossplane.io/v1alpha1/namespaces/default/mysqlinstances/mysql-claim
- UID: afff42b3-f999-11e9-a2d5-c64d758a651f
-Spec:
- Class Ref:
- API Version: database.azure.crossplane.io/v1alpha3
- Kind: SQLServerClass
- Name: azure-mysql-standard
- UID: 5710f3db-f999-11e9-a2d5-c64d758a651f
- Class Selector:
- Match Labels:
- Demo: true
- Size: standard
- Engine Version: 5.6
- Resource Ref:
- API Version: database.azure.crossplane.io/v1alpha3
- Kind: MySQLServer
- Name: default-mysql-claim-bm4ft
- UID: b02c1389-f999-11e9-a2d5-c64d758a651f
- Write Connection Secret To Ref:
- Name: wordpressmysql
-Status:
- Conditions:
- Last Transition Time: 2019-10-28T15:43:29Z
- Reason: Managed claim is waiting for managed resource to become bindable
- Status: False
- Type: Ready
- Last Transition Time: 2019-10-28T15:43:29Z
- Reason: Successfully reconciled managed resource
- Status: True
- Type: Synced
-Events:
-```
-
-*Note: You must wait until the claim becomes bound before continuing with this
-guide. It could take a few minutes for Azure to complete MySQL creation.*
-
-### Virtual Network Rule
-
-Before we install Wordpress, we need establish connectivity between our MySQL
-database and our AKS cluster. We can do this by creating a [Virtual Network
-Rule][azure-vnet-rule].
-
-* Set `MYSQL_NAME` environment variable:
-
-```bash
-export MYSQL_NAME=$(kubectl get -o json mysqlinstance mysql-claim | jq -j '.spec.resourceRef.name')
-```
-
-* Define a `MySQLServerVirtualNetworkRule` in `wordpress-vnet-rule.yaml` and
- create it:
-
-```yaml
-cat > wordpress-vnet-rule.yaml <
-Annotations: crossplane.io/propagate-from-name: 084b9476-f99e-11e9-a2d5-c64d758a651f
- crossplane.io/propagate-from-namespace: crossplane-system
- crossplane.io/propagate-from-uid: 2e71f6f9-f99e-11e9-a2d5-c64d758a651f
-
-Type: Opaque
-
-Data
-====
-endpoint: 50 bytes
-password: 27 bytes
-username: 33 bytes
-```
-
-* Define the `Deployment` and `Service` in `wordpress-app.yaml` and create it:
-
-```yaml
-cat > wordpress-app.yaml <`, wait until it
-becomes available, then navigate to the address. You should see the following:
-
-
-
-
-## Clean Up
-
-Because we put all of our configuration in a single directory, we can delete it
-all with this command:
-
-```bash
-kubectl delete -f wordpress/
-```
-
-If you would like to also uninstall Crossplane and the AWS stack, run the
-following command:
-
-```bash
-kubectl delete namespace crossplane-system
-```
-
-## Conclusion and Next Steps
-
-In this guide we:
-
-* Installed Crossplane from alpha channel
-* Installed the Azure stack
-* Setup an Azure `Provider` with our account
-* Created a `SQLServerClass` in the ` with configuration for a MySQL database on
- Azure
-* Created a `MySQLInstance` claim in the that was scheduled to the
- `mysql-standard` resource class
-* Created a `MySQLServerVirtualNetworkRule` to establish secure connectivity
- between our AKS Cluster and MySQL database
-* Created a `Deployment` and `Service` to run Wordpress on our AKS Cluster and
- assign an external IP address to it
-
-If you would like to try out a similar workflow using a different cloud
-provider, take a look at the other [services guides][services]. If you would
-like to learn more about stacks, checkout the [stacks guide][stacks].
-
-
-[azure-cli]: https://docs.microsoft.com/en-us/cli/azure/?view=azure-cli-latest
-[azure-login]: https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli?view=azure-cli-latest
-[install-kubectl]: https://kubernetes.io/docs/tasks/tools/install-kubectl/
-[using-helm]: https://docs.helm.sh/using_helm/
-[jq-docs]: https://stedolan.github.io/jq/
-[service endpoint]: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoint-policies-overview
-[aks-kubectl]: https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough#connect-to-the-cluster
-
-[crossplane-install]: ../install-crossplane.md#alpha
-[azure-stack-install]: ../install-crossplane.md#azure-stack
-[cloud-creds]: ../cloud-providers.md
-
-[azure-provider-guide]: ../cloud-providers/azure/azure-provider.md
-
-[azure-mysql]: https://azure.microsoft.com/en-us/services/mysql/
-[azure-vnet-rule]: https://docs.microsoft.com/en-us/azure/mysql/concepts-data-access-and-security-vnet
-[static provisioning]: ../concepts.md#dynamic-and-static-provisioning
-
-[services]: ../services-guide.md
-[stacks]: ../stacks-guide.md
diff --git a/docs/v0.4/services/gcp-services-guide.md b/docs/v0.4/services/gcp-services-guide.md
deleted file mode 100644
index fcca78de..00000000
--- a/docs/v0.4/services/gcp-services-guide.md
+++ /dev/null
@@ -1,529 +0,0 @@
----
-title: Using GCP Services
-toc: true
-weight: 420
-indent: true
----
-
-# GCP Services Guide
-
-This user guide will walk you through Wordpress application deployment using
-your existing Kubernetes cluster and Crossplane managed resources. We will:
-* Install Crossplane to your cluster.
-* Create necessary resource classes for MySQL database instance.
-* Create network resources to get GKE cluster to connect to MySQL instance.
-* Deploy Wordpress.
-
-## Table of Contents
-
-1. [Pre-requisites](#pre-requisites)
-1. [Preparation](#preparation)
-1. [Set Up Crossplane](#set-up-crossplane)
- 1. [Install in Target Cluster](#install-in-target-cluster)
- 1. [Cloud Provider](#cloud-provider)
- 1. [Resource Classes](#resource-classes)
- 1. [Configure Managed Service Access](#configure-managed-service-access)
-1. [Provision MySQL](#provision-mysql)
- 1. [Resource Claim](#resource-claim)
-1. [Install Wordpress](#install-wordpress)
-1. [Clean Up](#clean-up)
-1. [Conclusion and Next Steps](#conclusion-and-next-steps)
-
-## Pre-requisites
-
-* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
-* A GKE cluster.
-
-## Preparation
-
-This guide assumes that you have setup the gcloud CLI and are logged in to your
-desired account.
-
-*Note: environment variables are used throughout this guide. You should use your
-own values.*
-
-Run the following:
-```bash
-export PROJECT_ID=crossplane-playground # the project that all resources reside.
-export NETWORK_NAME=default # the network that your GKE cluster lives in.
-export SUBNETWORK_NAME=default # the subnetwork that your GKE cluster lives in.
-```
-
-## Set Up Crossplane
-
-### Installation
-
-Assuming you are
-[connected](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl)
-to your GKE cluster via `kubectl`:
-
-* Install Crossplane from alpha channel using the [Crossplane Installation
- Guide](../install-crossplane.md#alpha)
-* Install the GCP stack into Crossplane using the [GCP stack
- section](../install-crossplane.md#gcp-stack) of the install guide.
-
-To keep your resource configuration organized, start by creating a new
-directory:
-
-```bash
-mkdir wordpress && cd $_
-```
-
-### Cloud Provider
-
-It is essential to make sure that the GCP user credentials are configured in
-Crossplane as a provider. Please follow the steps in the GCP [provider
-guide](../cloud-providers/gcp/gcp-provider.md) for more information.
-
-### Resource Classes
-
-Resource classes are used to define a reusable configuration for a specific
-managed service. Wordpress requires a MySQL database, which can be satisfied by
-a [Google Cloud SQL Instance](https://cloud.google.com/sql/docs/mysql/).
-
-* Define a GCP CloudSQL class `CloudSQLInstanceClass`:
-
-```bash
-cat > gcp-mysql-standard.yaml < network.yaml <
- Annotations: crossplane.io/external-name: example-connection
- kubectl.kubernetes.io/last-applied-configuration:
- {"apiVersion":"servicenetworking.gcp.crossplane.io/v1alpha3","kind":"Connection","metadata":{"annotations":{},"name":"example-connection"}...
- API Version: servicenetworking.gcp.crossplane.io/v1alpha3
- Kind: Connection
- Metadata:
- Creation Timestamp: 2019-10-28T14:10:23Z
- Finalizers:
- finalizer.managedresource.crossplane.io
- Generation: 1
- Resource Version: 7245
- Self Link: /apis/servicenetworking.gcp.crossplane.io/v1alpha3/connections/example-connection
- UID: aeae7e4d-f98c-11e9-8275-42010a800122
- Spec:
- Network: projects/crossplane-playground/global/networks/default
- Parent: services/servicenetworking.googleapis.com
- Provider Ref:
- Name: gcp-provider
- Reclaim Policy: Delete
- Reserved Peering Ranges:
- example-globaladdress
- Status:
- Conditions:
- Last Transition Time: 2019-10-28T14:10:23Z
- Reason: Successfully resolved managed resource references to other resources
- Status: True
- Type: ReferencesResolved
- Last Transition Time: 2019-10-28T14:10:23Z
- Reason: Managed resource is being created
- Status: False
- Type: Ready
- Last Transition Time: 2019-10-28T14:10:23Z
- Reason: Successfully reconciled managed resource
- Status: True
- Type: Synced
- Events:
- ```
-
- We are looking for the `Connection` resource to report `Type: Ready` `Status:
- True` in its `status.conditions`.
-
-## Provision
-
-### Resource Claim
-
-Resource claims are used for dynamic provisioning of a managed resource (like a
-MySQL instance) by matching the claim to a resource class. This can be done in
-several ways: (a) rely on the default class marked
-`resourceclass.crossplane.io/is-default-class: "true"`, (b) use a
-`claim.spec.classRef` to a specific class, or (c) match on class labels using a
-`claim.spec.classSelector`.
-
-*Note: claims may also be used in [static
-provisioning](../concepts.md#dynamic-and-static-provisioning) with a reference
-to an existing managed resource.*
-
-In the `CloudSQLInstanceClass` above, we added the label `size: standard`, so
-our claim will be scheduled to that class using the label is specified in the
-`claim.spec.classSelector`. If there are multiple classes which match the
-specified label(s) one will be chosen at random.
-
-* Define a `MySQLInstance` claim in `mysql-claim.yaml`:
-
- ```bash
- cat > mysql-claim.yaml <
-Annotations: kubectl.kubernetes.io/last-applied-configuration:
- {"apiVersion":"database.crossplane.io/v1alpha1","kind":"MySQLInstance","metadata":{"annotations":{},"name":"mysql-claim","namespace":"defa...
-API Version: database.crossplane.io/v1alpha1
-Kind: MySQLInstance
-Metadata:
- Creation Timestamp: 2019-10-28T14:18:55Z
- Finalizers:
- finalizer.resourceclaim.crossplane.io
- Generation: 3
- Resource Version: 9011
- Self Link: /apis/database.crossplane.io/v1alpha1/namespaces/default/mysqlinstances/mysql-claim
- UID: e0329d69-f98d-11e9-8275-42010a800122
-Spec:
- Class Ref:
- API Version: database.gcp.crossplane.io/v1beta1
- Kind: CloudSQLInstanceClass
- Name: standard-cloudsql
- UID: 431580bd-f989-11e9-8275-42010a800122
- Class Selector:
- Match Labels:
- Size: standard
- Engine Version: 5.7
- Resource Ref:
- API Version: database.gcp.crossplane.io/v1beta1
- Kind: CloudSQLInstance
- Name: default-mysql-claim-vtnf7
- UID: e07c42c5-f98d-11e9-8275-42010a800122
- Write Connection Secret To Ref:
- Name: wordpressmysql
-Status:
- Conditions:
- Last Transition Time: 2019-10-28T14:18:56Z
- Reason: Managed claim is waiting for managed resource to become bindable
- Status: False
- Type: Ready
- Last Transition Time: 2019-10-28T14:18:56Z
- Reason: Successfully reconciled managed resource
- Status: True
- Type: Synced
-Events:
-```
-
-*Note: You must wait until the claim becomes bound before continuing with this
-guide. It could take a few minutes for GCP to complete CloudSQL creation.*
-
-## Install Wordpress
-
-Installing Wordpress requires creating a Kubernetes `Deployment` and load
-balancer `Service`. We will point the deployment to the `wordpressmysql` secret
-that we specified in our claim above for the Wordpress container environment
-variables. It should have been populated with our MySQL connection details after
-the claim became `Bound`.
-
-> Binding status tells you whether your resource has been provisioned and ready
-to use. Crossplane binds the actual resource to the claim via changing the
-readiness condition to `Bound`. This happens only when the resource is ready to
-be consumed.
-
-* Check to make sure `wordpressmysql` exists and is populated:
-
-*Command*
-```bash
-kubectl describe secret wordpressmysql
-```
-
-*Output*
-```bash
-Name: wordpressmysql
-Namespace: default
-Labels:
-Annotations: crossplane.io/propagate-from-name: 330cccf5-f991-11e9-8275-42010a800122
- crossplane.io/propagate-from-namespace: crossplane-system
- crossplane.io/propagate-from-uid: 33581ec7-f991-11e9-8275-42010a800122
-
-Type: Opaque
-
-Data
-====
-endpoint: 10 bytes
-password: 27 bytes
-publicIP: 13 bytes
-serverCACertificateCert: 1272 bytes
-serverCACertificateCommonName: 98 bytes
-serverCACertificateCreateTime: 24 bytes
-serverCACertificateExpirationTime: 24 bytes
-privateIP: 10 bytes
-serverCACertificateCertSerialNumber: 1 bytes
-serverCACertificateInstance: 25 bytes
-serverCACertificateSha1Fingerprint: 40 bytes
-username: 4 bytes
-```
-
-* Define the `Deployment` and `Service` in `wordpress.yaml`:
-
- ```bash
- cat > wordpress.yaml <`, wait until it
-becomes available, then navigate to the address. You should see the following:
-
-
-
-## Clean Up
-
-Because we put all of our configuration in a single directory, we can delete it
-all with this command:
-
-```bash
-kubectl delete -f wordpress/
-```
-
-If you would like to also uninstall Crossplane and the AWS stack, run the
-following command:
-
-```bash
-kubectl delete namespace crossplane-system
-```
-
-## Conclusion and Next Steps
-
-We're done!
-
-In this guide, we:
-
-* Set up Crossplane on our GKE Cluster.
-* Installed Crossplane GCP Stack.
-* Created resource classes for MySQL database.
-* Provisioned a MySQL database on GCP using Crossplane.
-* Connected our GKE cluster to our MySQL database.
-* Installed Wordpress to our GKE cluster.
-
-In this guide, we used an existing GKE cluster but actually Crossplane can
-provision a Kubernetes cluster from GCP just like it provisions a MySQL
-database.
-
-We deployed Wordpress using bare `Deployment` and `Service` resources but there
-is actually a Wordpress App stack that creates these resources for us!
-
-Check out the [stacks guides](../stacks-guide.md)!
-
-## References
-
-* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
-* [Crossplane Installation Guide](../install-crossplane.md#alpha)
-* [GCP Stack Installation](../install-crossplane.md#gcp-stack)
-* [GCP Provider Guide](../cloud-providers/gcp/gcp-provider.md)
-* [Google Cloud SQL Instance](https://cloud.google.com/sql/docs/mysql/)
-* [Default Resource Classes One-Pager](https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-default-resource-class.md)
-* [Google Private Service Connection](https://cloud.google.com/vpc/docs/configure-private-services-access)
diff --git a/docs/v0.4/services/wordpress-start.png b/docs/v0.4/services/wordpress-start.png
deleted file mode 100644
index e21ad0f6..00000000
Binary files a/docs/v0.4/services/wordpress-start.png and /dev/null differ
diff --git a/docs/v0.4/stacks-guide-aws.md b/docs/v0.4/stacks-guide-aws.md
deleted file mode 100644
index 4aa377c2..00000000
--- a/docs/v0.4/stacks-guide-aws.md
+++ /dev/null
@@ -1,578 +0,0 @@
----
-title: "Stacks Guide: AWS Setup"
-toc: true
-weight: 530
-indent: true
----
-
-# Stacks Guide: AWS Setup
-
-## Table of Contents
-
-- [Stacks Guide: AWS Setup](#stacks-guide-aws-setup)
- - [Table of Contents](#table-of-contents)
- - [Introduction](#introduction)
- - [Install the AWS stack](#install-the-aws-stack)
- - [Validate the installation](#validate-the-installation)
- - [Configure the AWS account](#configure-the-aws-account)
- - [Set Up Network Configuration](#set-up-network-configuration)
- - [TL;DR](#tldr)
- - [Behind the scenes](#behind-the-scenes)
- - [Configure Resource Classes](#configure-resource-classes)
- - [TL;DR](#tldr-1)
- - [More Details](#more-details)
- - [Recap](#recap)
- - [Next Steps](#next-steps)
-
-## Introduction
-
-In this guide, we will set up an AWS provider in Crossplane so that we can
-install and use the [WordPress sample stack][sample-WordPress-stack], which
-depends on MySQL and Kubernetes!
-
-Before we begin, you will need:
-
-- Everything from the [Crossplane Stacks Guide][stacks-guide] before the cloud
- provider setup
- - The `kubectl` (v1.15+) tool installed and pointing to a Crossplane cluster
- - The [Crossplane CLI][crossplane-cli] installed
-- An account on [AWS][aws]
-- The [aws cli][aws command line tool] installed
-
-At the end, we will have:
-
-- A Crossplane cluster configured to use AWS
-- A typical AWS network configured to support secure connectivity between
- resources
-- Support in Crossplane cluster for satisfying MySQL and Kubernetes claims
-- A slightly better understanding of:
- - The way AWS is configured in Crossplane
- - The way dependencies for cloud-portable workloads are configured in
- Crossplane
-
-We will **not** be covering the core concepts in this guide, but feel free to
-check out the [Crossplane concepts document][crossplane-concepts] for that.
-
-## Install the AWS stack
-
-After Crossplane has been installed, it can be extended with more functionality
-by installing a [Crossplane Stack][stack-docs]! Let's install the [stack for
-Amazon Web Services][stack-aws] (AWS) to add support for that cloud provider.
-
-The namespace where we install the stack, is also the one in which the provider
-secret will reside. The name of this namespace is arbitrary, and we are calling
-it `crossplane-system` in this guide. Let's create it:
-
-```bash
-# namespace for AWS stack and provider secret
-kubectl create namespace crossplane-system
-```
-
-Now we install the AWS stack using Crossplane CLI. Since this is an
-infrastructure stack, we need to specify that it's cluster-scoped by passing the
-`--cluster` flag.
-
-```bash
-kubectl crossplane stack generate-install --cluster 'crossplane/stack-aws:v0.2.1' stack-aws | kubectl apply --namespace crossplane-system -f -
-```
-
-The rest of this guide assumes that the AWS stack is installed within
-`crossplane-system` namespace.
-
-### Validate the installation
-
-To check to see whether our stack installed correctly, we can look at the status
-of our stack:
-
-```bash
-kubectl -n crossplane-system get stack
-```
-
-It should look something like:
-
-```bash
-NAME READY VERSION AGE
-stack-aws True 0.0.2 45s
-```
-
-## Configure the AWS account
-
-It is essential to make sure that the AWS user credentials are configured in
-Crossplane as a provider. Please follow the steps in the AWS [provider
-guide][aws-provider-guide] for more information.
-
-## Set Up Network Configuration
-
-In this section we build a simple AWS network configuration, by creating
-corresponding Crossplane managed resources. These resources are cluster scoped,
-so don't belong to a specific namespace. This network configuration enables
-resources in the WordPress stack to communicate securely. In this guide, we will use
-the [sample AWS network configuration][] in the Crossplane repository. You can read
-more [here][crossplane-aws-networking-docs] about network secure connectivity
-configurations in Crossplane.
-
-### TL;DR
-
-Apply the sample network configuration resources:
-
-```bash
-kubectl apply -k github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/aws/network-config?ref=release-0.4
-```
-
-And you're done! You can check the status of the provisioning by running:
-
-```bash
-kubectl get -k github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/aws/network-config?ref=release-0.4
-```
-
-When all resources have the `Ready` condition in `True` state, the provisioning
-is complete. You can now move on to the next section, or keep reading below for
-more details about the managed resources that we created.
-
-### Behind the scenes
-
-When configured in AWS, WordPress resources map to an EKS cluster and an RDS
-database instance. In order to make the RDS instance accessible from the EKS
-cluster, they both need to live within the same VPC. However, a VPC is not the
-only AWS resource that needs to be created to provide inter-resource
-connectivity. In general, a **Network Configuration** which consists of a set of
-VPCs, Subnets, Security Groups, Route Tables, IAM Roles and other resources is
-required for this purpose. For more information, see [AWS resource
-connectivity][aws-resource-connectivity] design document.
-
-To inspect the resources that we created above, let's run:
-
-```bash
-kubectl kustomize github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/aws/network-config?ref=release-0.4 > network-config.yaml
-```
-
-This will save the sample network configuration resources locally in
-`network-config.yaml`. Please note that the AWS parameters that are used in
-these resources (like `cidrBlock`, `region`, etc...) are arbitrarily chosen in
-this solution and could be configured to implement other
-[configurations][eks-user-guide].
-
-Below we inspect each of these resources in more details.
-
-- **`VPC`** Represents an AWS [Virtual Private Network][] (VPC).
-
- ```yaml
- ---
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: VPC
- metadata:
- name: sample-vpc
- spec:
- cidrBlock: 192.168.0.0/16
- enableDnsSupport: true
- enableDnsHostNames: true
- reclaimPolicy: Delete
- providerRef:
- name: aws-provider
- ```
-
-- **`Subnet`** Represents an AWS [Subnet][]. For this configuration we create
- one Subnet per each availability zone in the selected region.
-
- ```yaml
- ---
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: Subnet
- metadata:
- name: sample-subnet1
- spec:
- cidrBlock: 192.168.64.0/18
- vpcIdRef:
- name: sample-vpc
- availabilityZone: us-west-2a
- reclaimPolicy: Delete
- providerRef:
- name: aws-provider
- ---
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: Subnet
- metadata:
- name: sample-subnet2
- spec:
- cidrBlock: 192.168.128.0/18
- vpcIdRef:
- name: sample-vpc
- availabilityZone: us-west-2b
- reclaimPolicy: Delete
- providerRef:
- name: aws-provider
- ---
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: Subnet
- metadata:
- name: sample-subnet3
- spec:
- cidrBlock: 192.168.192.0/18
- vpcIdRef:
- name: sample-vpc
- availabilityZone: us-west-2c
- reclaimPolicy: Delete
- providerRef:
- name: aws-provider
- ```
-
-- **`InternetGateway`** Represents an AWS [Internet Gateway][] which allows the
- resources in the VPC to have access to the Internet. Since the WordPress
- application will be accessed from the internet, this resource is required in
- the network configuration.
-
- ```yaml
- ---
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: InternetGateway
- metadata:
- name: sample-internetgateway
- spec:
- vpcIdRef:
- name: sample-vpc
- reclaimPolicy: Delete
- providerRef:
- name: aws-provider
- ```
-
-- **`RouteTable`** Represents an AWS [Route Table][], which specifies rules to
- direct traffic in a virtual network. We use a Route Table to redirect internet
- traffic from all Subnets to the Internet Gateway instance.
-
- ```yaml
- ---
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: RouteTable
- metadata:
- name: sample-routetable
- spec:
- vpcIdRef:
- name: sample-vpc
- routes:
- - destinationCidrBlock: 0.0.0.0/0
- gatewayIdRef:
- name: sample-internetgateway
- associations:
- - subnetIdRef:
- name: sample-subnet1
- - subnetIdRef:
- name: sample-subnet2
- - subnetIdRef:
- name: sample-subnet3
- reclaimPolicy: Delete
- providerRef:
- name: aws-provider
- ```
-
-- **`SecurityGroup`** Represents an AWS [Security Group][], which controls
- inbound and outbound traffic to EC2 instances.
-
- We need two security groups in this configuration:
-
- - A security group to assign later to the EKS cluster workers, so they have
- the right permissions to communicate with each API server
-
- ```yaml
- ---
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: SecurityGroup
- metadata:
- name: sample-cluster-sg
- spec:
- vpcIdRef:
- name: sample-vpc
- groupName: my-cool-ekscluster-sg
- description: Cluster communication with worker nodes
- reclaimPolicy: Delete
- providerRef:
- name: aws-provider
- ```
-
- - A security group to assign later to the RDS database instance, which
- allows the instance to accept traffic from worker nodes.
-
- ```yaml
- ---
- apiVersion: network.aws.crossplane.io/v1alpha3
- kind: SecurityGroup
- metadata:
- name: sample-rds-sg
- spec:
- vpcIdRef:
- name: sample-vpc
- groupName: my-cool-rds-sg
- description: open rds access to crossplane workload
- reclaimPolicy: Delete
- ingress:
- - fromPort: 3306
- toPort: 3306
- protocol: tcp
- cidrBlocks:
- - cidrIp: 0.0.0.0/0
- description: all ips
- providerRef:
- name: aws-provider
- ```
-
-- **`DBSubnetGroup`** Represents an AWS [Database Subnet Group][] that stores a
- set of existing Subnets in different availability zones, from which an IP
- address is chosen and assigned to the RDS instance.
-
- ```yaml
- ---
- apiVersion: database.aws.crossplane.io/v1alpha3
- kind: DBSubnetGroup
- metadata:
- name: sample-dbsubnetgroup
- spec:
- groupName: my-cool-dbsubnetgroup
- description: EKS vpc to rds
- subnetIdRefs:
- - name: sample-subnet1
- - name: sample-subnet2
- - name: sample-subnet3
- tags:
- - key: name
- value: my-cool-dbsubnetgroup
- reclaimPolicy: Delete
- providerRef:
- name: aws-provider
- ```
-
-- **`IAMRole`** Represents An AWS [IAM Role][], which assigns a set of access
- policies to the AWS principal that assumes it. We create a role, and later add
- policies to it and then assign the role to the cluster. This grants the
- permissions the cluster needs to communicate with other resources in AWS.
-
- ```yaml
- ---
- apiVersion: identity.aws.crossplane.io/v1alpha3
- kind: IAMRole
- metadata:
- name: sample-eks-cluster-role
- spec:
- roleName: my-cool-eks-cluster-role
- description: a role that gives a cool power
- assumeRolePolicyDocument: |
- {
- "Version": "2012-10-17",
- "Statement": [
- {
- "Effect": "Allow",
- "Principal": {
- "Service": "eks.amazonaws.com"
- },
- "Action": "sts:AssumeRole"
- }
- ]
- }
- reclaimPolicy: Delete
- providerRef:
- name: aws-provider
- ```
-
-- **`IAMRolePolicyAttachment`** Represents an AWS [IAM Role Policy][], which
- defines a certain permission in an IAM Role. We need two policies to create
- and assign to the IAM Role above, so the cluster my communicate with other
- AWS resources.
-
- ```yaml
- ---
- apiVersion: identity.aws.crossplane.io/v1alpha3
- kind: IAMRolePolicyAttachment
- metadata:
- name: sample-role-servicepolicy
- spec:
- roleNameRef:
- name: sample-eks-cluster-role
- # wellknown policy arn
- policyArn: arn:aws:iam::aws:policy/AmazonEKSServicePolicy
- reclaimPolicy: Delete
- providerRef:
- name: aws-provider
- ---
- apiVersion: identity.aws.crossplane.io/v1alpha3
- kind: IAMRolePolicyAttachment
- metadata:
- name: sample-role-clusterpolicy
- spec:
- roleNameRef:
- name: sample-eks-cluster-role
- # wellknown policy arn
- policyArn: arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
- reclaimPolicy: Delete
- providerRef:
- name: aws-provider
- ```
-
-As you probably have noticed, some resources are referencing other resources in
-their YAML representations. For instance for `Subnet` resource we have:
-
-```yaml
-...
- vpcIdRef:
- name: sample-vpc
-...
-```
-
-Such cross resource referencing is a Crossplane feature that enables managed
-resources to retrieve other resources attributes. This creates a *blocking
-dependency*, preventing the dependent resource from being created before the referred
-resource is ready. In the example above, `Subnet` will be blocked until the
-referred `VPC` is created, and then it retrieves its `vpcId`. For more
-information, see [Cross Resource Referencing][].
-
-## Configure Resource Classes
-
-Once we have the network configuration set up, we need to tell Crossplane how to
-satisfy WordPress's claims (that will be created when we later install the
-WordPress stack) for a database and a Kubernetes cluster. The [Resource
-Classes][resource-claims-docs] serve as templates for the corresponding resource
-claims.
-
-In this guide, we will use the [sample AWS resource classes][] in Crossplane
-repository.
-
-### TL;DR
-
-Apply the sample AWS resource classes:
-
-```bash
-kubectl apply -k github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/aws/resource-classes?ref=release-0.4
-```
-
-And you're done! Note that these resources do not immediately provision external
-AWS resources, as they only serve as as template classes.
-
-### More Details
-
-To inspect the resource classes that we created above, run:
-
-```bash
-kubectl kustomize github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/aws/resource-classes?ref=release-0.4 > resource-classes.yaml
-```
-
-This will save the sample resource classes YAML locally in
-`resource-classes.yaml`. As mentioned above, these resource classes serve as
-templates and could be configured depending on the specific needs that are
-needed from the underlying resources. For instance, in the sample resources the
-`RDSInstanceClass` has `size: 20`, which will result in RDS databases of size 20
-once a claim is submitted for this class. In addition, it's possible to have
-multiple classes defined for the same claim kind, but our sample has defined
-only one class for each resource type.
-
-Below we inspect each of these resource classes in more details:
-
-- **`RDSInstanceClass`** Represents a resource that serves as a template to
- create an [RDS Database Instance][].
-
- ```yaml
- ---
- apiVersion: database.aws.crossplane.io/v1beta1
- kind: RDSInstanceClass
- metadata:
- name: standard-mysql
- annotations:
- resourceclass.crossplane.io/is-default-class: "true"
- specTemplate:
- writeConnectionSecretsToNamespace: crossplane-system
- forProvider:
- dbInstanceClass: db.t2.small
- masterUsername: cool_user
- vpcSecurityGroupIDRefs:
- - name: sample-rds-sg
- dbSubnetGroupNameRef:
- name: sample-dbsubnetgroup
- allocatedStorage: 20
- engine: mysql
- skipFinalSnapshotBeforeDeletion: true
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- ```
-
-- **`EKSClusterClass`** Represents a resource that serves as a template to create an [EKS Cluster][].
-
- ```yaml
- ---
- apiVersion: compute.aws.crossplane.io/v1alpha3
- kind: EKSClusterClass
- metadata:
- name: standard-cluster
- annotations:
- resourceclass.crossplane.io/is-default-class: "true"
- specTemplate:
- writeConnectionSecretsToNamespace: crossplane-system
- region: us-west-2
- roleARNRef:
- name: sample-eks-cluster-role
- vpcIdRef:
- name: sample-vpc
- subnetIdRefs:
- - name: sample-subnet1
- - name: sample-subnet2
- - name: sample-subnet3
- securityGroupIdRefs:
- - name: sample-cluster-sg
- workerNodes:
- nodeInstanceType: m3.medium
- nodeAutoScalingGroupMinSize: 1
- nodeAutoScalingGroupMaxSize: 1
- nodeGroupName: demo-nodes
- clusterControlPlaneSecurityGroupRef:
- name: sample-cluster-sg
- providerRef:
- name: aws-provider
- reclaimPolicy: Delete
- ```
-
-These resources will be the default resource classes for the corresponding
-claims (`resourceclass.crossplane.io/is-default-class: "true"` annotation). For
-more details about resource claims and how they work, see the documentation on
-[resource claims][resource-claims-docs], and [resource class selection].
-
-## Recap
-
-To recap what we've set up now in our environment:
-
-- A Crossplane Provider resource for AWS
-- A Network Configuration to have secure connectivity between resources
-- An EKSClusterClass and an RDSInstanceClass with the right configuration to use
- the mentioned networking setup.
-
-## Next Steps
-
-Next we'll set up a Crossplane App Stack and use it! Head [back over to the
-Stacks Guide document][stacks-guide-continue] so we can pick up where we left
-off.
-
-
-[crossplane-concepts]: concepts.md
-[stacks-guide]: stacks-guide.md
-[aws]: https://aws.amazon.com
-[stack-aws]: https://github.com/crossplaneio/stack-aws
-[sample-wordpress-stack]: https://github.com/crossplaneio/sample-stack-wordpress
-[stack-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#crossplane-stacks
-[aws command line tool]: https://aws.amazon.com/cli/
-[crossplane-cli]: https://github.com/crossplaneio/crossplane-cli/tree/release-0.2
-[Virtual Private Network]: https://aws.amazon.com/vpc/
-[Subnet]: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-subnet-basics
-[aws-resource-connectivity]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-resource-connectivity-mvp.md#amazon-web-services
-[Internet Gateway]: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html
-[Route Table]: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html
-[Security Group]: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
-[Database Subnet Group]: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html
-[IAM Role]: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
-[IAM Role Policy]: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html
-[stacks-guide-continue]: stacks-guide.md#install-support-for-our-application-into-crossplane
-[resource-claims-docs]: concepts.md#resource-claims-and-resource-classes
-[eks-user-guide]: https://docs.aws.amazon.com/eks/latest/userguide/create-public-private-vpc.html
-[Cross Resource Referencing]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-cross-resource-referencing.md
-[sample AWS network configuration]: https://github.com/crossplaneio/crossplane/tree/master/cluster/examples/workloads/kubernetes/wordpress/aws/network-config?ref=release-0.4
-[sample AWS resource classes]: https://github.com/crossplaneio/crossplane/tree/master/cluster/examples/workloads/kubernetes/wordpress/aws/resource-classes?ref=release-0.4
-[RDS Database Instance]: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.html
-[EKS Cluster]: https://docs.aws.amazon.com/eks/latest/userguide/clusters.html
-[resource-classes-docs]: concepts.md#resource-claims-and-resource-classes
-[resource class selection]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-simple-class-selection.md
-[crossplane-aws-networking-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-resource-connectivity-mvp.md#amazon-web-services
-[aws-provider-guide]: cloud-providers/aws/aws-provider.md
diff --git a/docs/v0.4/stacks-guide-azure.md b/docs/v0.4/stacks-guide-azure.md
deleted file mode 100644
index bc61918f..00000000
--- a/docs/v0.4/stacks-guide-azure.md
+++ /dev/null
@@ -1,455 +0,0 @@
----
-title: "Stacks Guide: Azure Setup"
-toc: true
-weight: 540
-indent: true
----
-
-# Stacks Guide: Azure Setup
-
-## Table of Contents
-
-- [Stacks Guide: Azure Setup](#stacks-guide-azure-setup)
- - [Table of Contents](#table-of-contents)
- - [Introduction](#introduction)
- - [Install the Azure Stack](#install-the-azure-stack)
- - [Validate the installation](#validate-the-installation)
- - [Configure Azure Account](#configure-azure-account)
- - [Set Up Network Configuration](#set-up-network-configuration)
- - [TL;DR](#tldr)
- - [Behind the scenes](#behind-the-scenes)
- - [Configure Resource Classes](#configure-resource-classes)
- - [TL;DR](#tldr-1)
- - [More Details](#more-details)
- - [Post Stack Installation Network Configuration](#post-stack-installation-network-configuration)
- - [Recap](#recap)
- - [Next Steps](#next-steps)
-
-## Introduction
-
-In this guide, we will set up an Azure provider in Crossplane so that we can
-install and use the [WordPress sample stack][sample-WordPress-stack], which
-depends on MySQL and Kubernetes!
-
-Before we begin, you will need:
-
-- Everything from the [Crossplane Stacks Guide][stacks-guide] before the cloud
- provider setup
- - The `kubectl` (v1.15+) tool installed and pointing to a Crossplane cluster
- - The [Crossplane CLI][crossplane-cli] installed
-- An account on [Azure][azure]
-- The [jq][jq] tool for interacting with some JSON
-
-At the end, we will have:
-
-- A Crossplane cluster configured to use Azure
-- A typical Azure network configured to support secure connectivity between
- resources
-- Support in Crossplane cluster for satisfying MySQL and Kubernetes claims
-- A slightly better understanding of:
- - The way Azure is configured in Crossplane
- - The way dependencies for cloud-portable workloads are configured in
- Crossplane
-
-We will **not** be covering the core concepts in this guide, but feel free to
-check out the [Crossplane concepts document][crossplane-concepts] for that.
-
-## Install the Azure Stack
-
-After Crossplane has been installed, it can be extended with more functionality
-by installing a [Crossplane Stack][stack-docs]! Let's install the [stack for
-Microsoft Azure][stack-azure] to add support for that cloud provider.
-
-The namespace where we install the stack, is also the one in which the provider
-secret will reside. The name of this namespace is arbitrary, and we are calling
-it `crossplane-system` in this guide. Let's create it:
-
-```bash
-# namespace for Azure stack and provider secret
-kubectl create namespace crossplane-system
-```
-
-Now we install the Azure stack using Crossplane CLI. Since this is an
-infrastructure stack, we need to specify that it's cluster-scoped by passing the
-`--cluster` flag.
-
-```bash
-kubectl crossplane stack generate-install --cluster 'crossplane/stack-azure:v0.2.1' stack-azure | kubectl apply --namespace crossplane-system -f -
-```
-
-The rest of this guide assumes that the Azure stack is installed within
-`crossplane-system` namespace.
-
-### Validate the installation
-
-To check to see whether our stack installed correctly, we can look at the status
-of our stack:
-
-```bash
-kubectl -n crossplane-system get stack
-```
-
-It should look something like:
-
-```bash
-NAME READY VERSION AGE
-stack-azure True 0.0.2 45s
-```
-
-## Configure Azure Account
-
-We will make use of the following services on Azure:
-
-- Resource Group
-- Azure Kubernetes Service
-- Azure Database for MySQL
-- Virtual Network
-- Subnetwork
-- Virtual Network Rule
-
-It is essential to make sure that the Azure user credentials are configured in
-Crossplane as a provider. Please follow the steps [provider
-guide][azure-provider-guide] for more information.
-
-## Set Up Network Configuration
-
-In this section we build a simple Azure virtual network configuration, by
-creating corresponding Crossplane managed resources. These resources are cluster
-scoped, so don't belong to a specific namespace. This network configuration
-enables resources in the WordPress stack to communicate securely. In this guide, we
-will use the [sample Azure network configuration][] in the Crossplane repository.
-You can read more [here][crossplane-azure-networking-docs] about network secure
-connectivity configurations in Crossplane.
-
-### TL;DR
-
-Apply the sample network configuration resources:
-
-```bash
-kubectl apply -k github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/azure/network-config?ref=release-0.4
-```
-
-And you're done! You can check the status of the provisioning by running:
-
-```bash
-kubectl get -k github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/azure/network-config?ref=release-0.4
-```
-
-When all resources have the `Ready` condition in `True` state, the provisioning
-is complete. You can now move on to the next section, or keep reading below for
-more details about the managed resources that we created.
-
-### Behind the scenes
-
-In order to provision Azure resources, a [Resource
-Group][azure-resource-group-docs] is needed to to logically group resources
-together. In addition, WordPress resources map to an AKS cluster and a SQLServer
-database instance. To make the database instance securely accessible from the
-cluster, they both need to live within the same Virtual Network. However, a
-Virtual Network is not the only Azure resource that is needed to provide
-inter-resource connectivity. In general, a **Network Configuration** which
-consists of a set of Virtual Networks, Subnets, VNet Rules and other resource is
-required for this purpose. For more information, see [Azure resource
-connectivity][azure-resource-connectivity] design document.
-
-To inspect the resources that we created above, let's run:
-
-```bash
-kubectl kustomize github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/azure/network-config?ref=release-0.4 > network-config.yaml
-```
-
-This will save the sample network configuration resources locally in
-`network-config.yaml`. Please note that the Azure parameters that are used in
-these resources (like `addresPrefixes`, `location`, etc...) are arbitrarily
-chosen in this solution and could be configured to implement other
-[configurations][azure-network-configuration].
-
-Below we inspect each of these resources in more details.
-
-- **`ResourceGroup`** Represents an Azure [Resource
- Group][azure-resource-group-docs], that is used to logically group resources
- together.
-
- ```yaml
- ---
- apiVersion: azure.crossplane.io/v1alpha3
- kind: ResourceGroup
- metadata:
- name: sample-rg
- spec:
- name: my-cool-rg
- location: Central US
- reclaimPolicy: Delete
- providerRef:
- name: azure-provider
- ```
-
-- **`VirtualNetwork`** Represents an Azure [Virtual
- Network][azure-virtual-network].
-
- ```yaml
- ---
- apiVersion: network.azure.crossplane.io/v1alpha3
- kind: VirtualNetwork
- metadata:
- name: sample-vnet
- spec:
- name: my-cool-vnet
- resourceGroupNameRef:
- name: sample-rg
- location: Central US
- properties:
- addressSpace:
- addressPrefixes:
- - 10.2.0.0/16
- reclaimPolicy: Delete
- providerRef:
- name: azure-provider
- ```
-
-- **`Subnet`** Represents an Azure [Subnet][azure-virtual-network].
-
- ```yaml
- ---
- apiVersion: network.azure.crossplane.io/v1alpha3
- kind: Subnet
- metadata:
- name: sample-subnet
- spec:
- name: my-cool-subnet
- resourceGroupNameRef:
- name: sample-rg
- virtualNetworkNameRef:
- name: sample-vnet
- properties:
- addressPrefix: 10.2.0.0/24
- serviceEndpoints:
- - service: Microsoft.Sql
- reclaimPolicy: Delete
- providerRef:
- name: azure-provider
- ```
-
-As you probably have noticed, some resources are referencing other resources in
-their YAML representations. For instance for `Subnet` resource we have:
-
-```yaml
-...
- virtualNetworkNameRef:
- name: sample-vnet
-...
-```
-
-Such cross resource referencing is a Crossplane feature that enables managed
-resources to retrieve other resources attributes. This creates a *blocking
-dependency*, preventing the dependent resource from being created before the referred
-resource is ready. In the example above, `Subnet` will be blocked until the
-referred `VirtualNetwork` is created, and then it retrieves its `name`. For more
-information, see [Cross Resource Referencing][].
-
-## Configure Resource Classes
-
-Once we have the network set up, we also need to tell Crossplane how to satisfy
-WordPress's claims (that will be created when we later install the WordPress
-stack) for a database and a Kubernetes cluster. The [Resource
-Classes][resource-claims-and-classes-docs] serve as templates for the
-corresponding resource claims.
-
-In this guide, we will use the [sample Azure resource classes][]in Crossplane
-repository.
-
-### TL;DR
-
-Apply the sample Azure resource classes:
-
-```bash
-kubectl apply -k github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/azure/resource-classes?ref=release-0.4
-```
-
-And you're done! Note that these resources do not immediately provision external
-Azure resources, as they only serve as template classes.
-
-### More Details
-
-To inspect the resource classes that we created above, run:
-
-```bash
-kubectl kustomize github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/azure/resource-classes?ref=release-0.4 > resource-classes.yaml
-```
-
-This will save the sample resource classes YAML locally in
-`resource-classes.yaml`. As mentioned above, these resource classes serve as
-templates and could be configured depending on the specific needs that are
-needed from the underlying resources. For instance, in the sample resources the
-`SQLServerClass` has `storageGB: 25`, which will result in SQLServer databases
-of size 25 once a claim is submitted for this class. In addition, it's possible
-to have multiple classes defined for the same claim kind, but our sample has
-defined only one class for each resource type.
-
-Below we inspect each of these resource classes in more details:
-
-- **`SQLServerClass`** Represents a resource that defines the blueprint for how
- a "standard" [Azure MySQL Server][azure-mysql-database] should be dynamically
- provisioned
-
- ```yaml
- ---
- apiVersion: database.azure.crossplane.io/v1alpha3
- kind: SQLServerClass
- metadata:
- name: standard-mysql
- annotations:
- resourceclass.crossplane.io/is-default-class: "true"
- specTemplate:
- writeConnectionSecretsToNamespace: crossplane-system
- adminLoginName: my-cool-login
- resourceGroupNameRef:
- name: sample-rg
- location: Central US
- sslEnforced: false
- version: "5.6"
- pricingTier:
- tier: GeneralPurpose
- vcores: 2
- family: Gen5
- storageProfile:
- storageGB: 25
- backupRetentionDays: 7
- geoRedundantBackup: false
- reclaimPolicy: Delete
- providerRef:
- name: azure-provider
- ```
-
-- **`AKSClusterClass`** Represents a resource that serves as a template to
- create an [Azure Kubernetes Engine][azure-aks](AKS).
-
- ```yaml
- ---
- apiVersion: compute.azure.crossplane.io/v1alpha3
- kind: AKSClusterClass
- metadata:
- name: standard-cluster
- annotations:
- resourceclass.crossplane.io/is-default-class: "true"
- specTemplate:
- writeConnectionSecretsToNamespace: crossplane-system
- resourceGroupNameRef:
- name: sample-rg
- vnetSubnetIDRef:
- name: sample-subnet
- location: Central US
- version: "1.12.8"
- nodeCount: 1
- nodeVMSize: Standard_B2s
- dnsNamePrefix: crossplane-aks
- disableRBAC: false
- writeServicePrincipalTo:
- name: akscluster-net
- namespace: crossplane-system
- reclaimPolicy: Delete
- providerRef:
- name: azure-provider
- ```
-
-These resources will be the default resource classes for the corresponding
-claims (`resourceclass.crossplane.io/is-default-class: "true"` annotation). For
-more details about resource claims and how they work, see the documentation on
-[resource claims][resource-claims-and-classes-docs], and [resource class
-selection].
-
-## Post Stack Installation Network Configuration
-
-After the WordPress stack is installed, we will need the AKS Cluster it
-provisions to be able to communicate with the MySQL database it provisions. In
-Azure, we can do so using a [Virtual Network Rule][azure-vnet-rule]. However,
-the rule cannot be created until after the MySQLInstance claim is created and
-satisfied, so we will start a short script to continually check if the database
-exists, and will create the rule if so.
-
-```bash
-cat > vnet-rule.yaml < vnetwatch.sh <<'EOF'
-#!/usr/bin/env bash
-
-set -e
-trap 'exit 1' SIGINT
-
-echo -n "waiting for mysql endpoint..." >&2
-while kubectl get mysqlservers -o yaml | grep -q 'items: \[\]'; do
- echo -n "." >&2
- sleep 5
-done
-echo "done" >&2
-
-export MYSQL_NAME=$(kubectl get mysqlservers -o=jsonpath='{.items[0].metadata.name}')
-
-sed "s/MYSQL_NAME/$MYSQL_NAME/g" vnet-rule.yaml | kubectl apply -f -
-
-EOF
-
-chmod +x vnetwatch.sh && ./vnetwatch.sh
-```
-
-The script should be left running in the background while we go through the rest
-of the guide and install the WordPress stack.
-
-## Recap
-
-To recap what we've set up now in our environment:
-
-- A Crossplane Provider resource for Azure
-- A Network Configuration to have secure connectivity between resources
-- An CloudSQLInstanceClass and an GKEClusterClass with the right configuration
- to use the mentioned networking setup.
-- A script that will create our Virtual Network Rule when our MySQL database
- name comes available.
-
-## Next Steps
-
-Next we'll set up a Crossplane App Stack and use it! Head [back over to the
-Stacks Guide document][stacks-guide-continue] so we can pick up where we left
-off.
-
-
-[crossplane-concepts]: concepts.md
-[sample-wordpress-stack]: https://github.com/crossplaneio/sample-stack-wordpress
-[crossplane-cli]: https://github.com/crossplaneio/crossplane-cli/tree/release-0.2
-[crossplane-azure-networking-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-resource-connectivity-mvp.md#microsoft-azure
-[stacks-guide]: stacks-guide.md
-[provider-azure-guide]: cloud-providers/azure/azure-provider.md
-[stack-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#crossplane-stacks
-[stack-azure]: https://github.com/crossplaneio/stack-azure
-[azure]: https://azure.microsoft.com
-[azure-vnet-rule]: https://docs.microsoft.com/en-us/azure/mysql/concepts-data-access-and-security-vnet
-[azure-resource-group-docs]: https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview
-[stacks-guide-continue]: stacks-guide.md#install-support-for-our-application-into-crossplane
-[jq]: https://stedolan.github.io/jq/
-[azure-virtual-network]: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview
-[azure-resource-connectivity]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-resource-connectivity-mvp.md#microsoft-azure
-[azure-network-configuration]: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-using-network-configuration-file
-[sample Azure resource classes]: https://github.com/crossplaneio/crossplane/tree/master/cluster/examples/workloads/kubernetes/wordpress/azure/resource-classes?ref=release-0.4
-[azure-mysql-database]: https://azure.microsoft.com/en-us/services/mysql/
-[azure-aks]: https://azure.microsoft.com/en-us/services/kubernetes-service/
-[resource-claims-and-classes-docs]: https://github.com/crossplaneio/crossplane/blob/master/docs/concepts.md#resource-claims-and-resource-classes
-[sample Azure network configuration]: https://github.com/crossplaneio/crossplane/tree/master/cluster/examples/workloads/kubernetes/wordpress/azure/network-config?ref=release-0.4
-[Cross Resource Referencing]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-cross-resource-referencing.md
-[resource class selection]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-simple-class-selection.md
-[azure-provider-guide]: cloud-providers/azure/azure-provider.md
diff --git a/docs/v0.4/stacks-guide-gcp.md b/docs/v0.4/stacks-guide-gcp.md
deleted file mode 100644
index fbd71ecc..00000000
--- a/docs/v0.4/stacks-guide-gcp.md
+++ /dev/null
@@ -1,424 +0,0 @@
----
-title: "Stacks Guide: GCP Setup"
-toc: true
-weight: 520
-indent: true
----
-
-# Stacks Guide: GCP Setup
-
-## Table of Contents
-
-- [Stacks Guide: GCP Setup](#stacks-guide-gcp-setup)
- - [Table of Contents](#table-of-contents)
- - [Introduction](#introduction)
- - [Install the GCP Stack](#install-the-gcp-stack)
- - [Configure GCP Account](#configure-gcp-account)
- - [Set up cloud provider credentials](#set-up-cloud-provider-credentials)
- - [Configure Crossplane Provider for GCP](#configure-crossplane-provider-for-gcp)
- - [Set Up Network Configuration](#set-up-network-configuration)
- - [TL;DR](#tldr)
- - [Behind the scenes](#behind-the-scenes)
- - [Configure Resources Classes](#configure-resources-classes)
- - [TL;DR](#tldr-1)
- - [More Details](#more-details)
- - [Recap](#recap)
- - [Next Steps](#next-steps)
-
-## Introduction
-
-In this guide, we will set up a GCP provider in Crossplane so that we can
-install and use the [WordPress sample stack][sample-wordpress-stack], which
-depends on MySQL and Kubernetes!
-
-Before we begin, you will need:
-
-- Everything from the [Crossplane Stacks Guide][stacks-guide] before the
- cloud provider setup
- - The `kubectl` (v1.15+) tool installed and pointing to a Crossplane cluster
- - The [Crossplane CLI][crossplane-cli] installed
-- An account on [Google Cloud Platform][gcp]
-
-At the end, we will have:
-
-- A Crossplane control cluster configured to use GCP
-- A typical GCP network configured to support secure connectivity between
- resources
-- Support in Crossplane cluster for satisfying MySQL and Kubernetes claims
-- A slightly better understanding of:
- - The way GCP is configured in Crossplane
- - The way dependencies for cloud-portable workloads are configured in
- Crossplane
-
-We will **not** be covering the core concepts in this guide, but feel free to
-check out the [Crossplane concepts document][crossplane-concepts] for that.
-
-## Install the GCP Stack
-
-After Crossplane has been installed, it can be extended with more
-functionality by installing a [Crossplane Stack][stack-docs]! Let's
-install the [stack for Google Cloud Platform][stack-gcp] (GCP) to add
-support for that cloud provider.
-
-The namespace where we install the stack, is also the one in which the provider
-secret will reside. The name of this namespace is arbitrary, and we are calling
-it `crossplane-system` in this guide. Let's create it:
-
-```bash
-# namespace for GCP stack and provider secret
-kubectl create namespace crossplane-system
-```
-
-Now we install the GCP stack using Crossplane CLI. Since this is an
-infrastructure stack, we need to specify that it's cluster-scoped by passing the
-`--cluster` flag.
-
-```bash
-kubectl crossplane stack generate-install --cluster 'crossplane/stack-gcp:v0.2.1' stack-gcp | kubectl apply --namespace crossplane-system -f -
-```
-
-The rest of this guide assumes that the GCP stack is installed within
-`crossplane-system` namespace.
-
-To check to see whether our stack installed correctly, we can look at
-the status of our stack:
-
-```bash
-kubectl -n crossplane-system get stack
-```
-
-It should look something like:
-
-```bash
-NAME READY VERSION AGE
-stack-gcp True 0.0.2 5m19s
-```
-
-## Configure GCP Account
-
-We will make use of the following services on GCP:
-
-- GKE
-- CloudSQL Instance
-- Network
-- Subnetwork
-- GlobalAddress
-- Private Service Connection
-
-For all these to work, you need to enable the following [APIs][gcp-enable-apis]
-in your GCP project:
-
-- Compute Engine API
-- Service Networking API
-- Kubernetes Engine API
-
-We will also need to tell Crossplane how to use the credentials for the GCP
-account. For this exercise, the GCP account that we will tell Crossplane about
-should have the following [roles][gcp-assign-roles] assigned:
-
-- Cloud SQL Admin
-- Compute Network Admin
-- Kubernetes Engine Admin
-- Service Account User
-
-### Set up cloud provider credentials
-
-It is essential to make sure that the GCP user credentials are configured in
-Crossplane as a provider. Please follow the steps in the GCP [provider
-guide][gcp-provider-guide] for more information.
-
-## Set Up Network Configuration
-
-In this section we build a simple GCP network configuration, by creating
-corresponding Crossplane managed resources. These resources are cluster scoped,
-so don't belong to a specific namespace. This network configuration enables
-resources in the WordPress stack to communicate securely. In this guide, we will use
-the [sample GCP network configuration][] in the Crossplane repository. You can read
-more [here][crossplane-gcp-networking-docs] about network secure connectivity
-configurations in Crossplane.
-
-### TL;DR
-
-Apply the sample network configuration resources:
-
-```bash
-kubectl apply -k github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/gcp/network-config?ref=release-0.4
-```
-
-And you're done! You can check the status of the provisioning by running:
-
-```bash
-kubectl get -k github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/gcp/network-config?ref=release-0.4
-```
-
-When all resources have the `Ready` condition in `True` state, the provisioning
-is complete. You can now move on to the next section, or keep reading below for
-more details about the managed resources that we created.
-
-### Behind the scenes
-
-WordPress needs a MySQL database and a Kubernetes cluster. But these
-two resources need a private network to communicate securely. So, we
-need to set up the network before we set up the database and the
-Kubernetes cluster.
-
-To inspect the resources that we created above, let's run:
-
-```bash
-kubectl kustomize github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/gcp/network-config?ref=release-0.4 > network-config.yaml
-```
-
-This will save the sample network configuration resources locally in
-`network-config.yaml`. Please note that the GCP parameters that are used in these
-resources (like `ipCidrRange`, `region`, etc...) are arbitrarily chosen in this
-solution and could be configured to implement other
-[configurations][gcp-network-configuration].
-
-Below we inspect each of these resources in more details.
-
-- **`Network`** Represents a GCP [Virtual Private Cloud (VPC)
- Network][gcp-network-configuration], that all cloud instances we'll create
- will use.
-
- ```yaml
- ---
- apiVersion: compute.gcp.crossplane.io/v1alpha3
- kind: Network
- metadata:
- name: sample-network
- spec:
- name: my-cool-network
- autoCreateSubnetworks: false
- routingConfig:
- routingMode: REGIONAL
- reclaimPolicy: Delete
- providerRef:
- name: gcp-provider
- ```
-
-- **`Subnetwork`** Represents a GCP [Virtual Private Cloud Subnetwork][gcp-network-configuration], which
- defines IP ranges to be used by GKE cluster.
-
- ```yaml
- ---
- apiVersion: compute.gcp.crossplane.io/v1alpha3
- kind: Subnetwork
- metadata:
- name: sample-subnetwork
- spec:
- name: my-cool-subnetwork
- region: us-central1
- ipCidrRange: "192.168.0.0/24"
- privateIpGoogleAccess: true
- secondaryIpRanges:
- - rangeName: pods
- ipCidrRange: 10.0.0.0/8
- - rangeName: services
- ipCidrRange: 172.16.0.0/16
- networkRef:
- name: sample-network
- reclaimPolicy: Delete
- providerRef:
- name: gcp-provider
- ```
-
-- **`GlobalAddress`** Represents a GCP [Global Address][gcp-ip-address], which defines the IP
- range that will be allocated for cloud services connecting to the instances in the given Network.
-
- ```yaml
- ---
- apiVersion: compute.gcp.crossplane.io/v1alpha3
- kind: GlobalAddress
- metadata:
- name: sample-globaladdress
- spec:
- name: my-cool-globaladdress
- purpose: VPC_PEERING
- addressType: INTERNAL
- prefixLength: 16
- networkRef:
- name: sample-network
- reclaimPolicy: Delete
- providerRef:
- name: gcp-provider
- ```
-
-- **`Connection`** Represents a GCP [Connection][gcp-connection], which allows
- cloud services to use the allocated GlobalAddress for communication. Behind
- the scenes, it creates a VPC peering to the network that those service
- instances actually live.
-
- ```yaml
- ---
- apiVersion: servicenetworking.gcp.crossplane.io/v1alpha3
- kind: Connection
- metadata:
- name: sample-connection
- spec:
- parent: services/servicenetworking.googleapis.com
- networkRef:
- name: sample-network
- reservedPeeringRangeRefs:
- - name: sample-globaladdress
- reclaimPolicy: Delete
- providerRef:
- name: gcp-provider
- ```
-
-As you probably have noticed, some resources are referencing other resources
- in their YAML representations. For instance for `Subnetwork` resource we have:
-
-```yaml
-...
- networkRef:
- name: sample-network
-...
-```
-
-Such cross resource referencing is a Crossplane feature that enables managed
-resources to retrieve other resources attributes. This creates a *blocking
-dependency*, preventing the dependent resource from being created before the referred
-resource is ready. In the example above, `Subnetwork` will be blocked until the
-referred `Network` is created, and then it retrieves its id. For more
-information, see [Cross Resource Referencing][].
-
-## Configure Resources Classes
-
-Once we have the network configuration set up, we need to tell Crossplane how to
-satisfy WordPress's claims (that will be created when we later install the
-WordPress stack) for a database and a Kubernetes cluster. The resource classes
-serve as templates for the corresponding resource claims. For more information,
-refer to [Resource Classes][resource-claims-and-classes-docs] design document.
-
-In this guide, we will use the [sample GCP resource classes] in Crossplane
-repository.
-
-### TL;DR
-
-Apply the sample GCP resource classes:
-
-```bash
-kubectl apply -k github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/gcp/resource-classes?ref=release-0.4
-```
-
-And you're done! Note that these resources do not immediately provision external GCP resourcs.
-
-### More Details
-
-To inspect the resource classes that we created above, run:
-
-```bash
-kubectl kustomize github.com/crossplaneio/crossplane//cluster/examples/workloads/kubernetes/wordpress/gcp/resource-classes?ref=release-0.4 > resource-classes.yaml
-```
-
-This will save the sample resource classes YAML locally in
-`resource-classes.yaml`. As mentioned above, these resource classes serve as
-templates and could be configured depending on the specific needs that are
-needed from the underlying resources. For instance, in the sample resources the
-`CloudSQLInstanceClass` has `storageGB: 10`, which will result in databases of
-size 10GB once a claim is submitted for this class. In addition, it's possible
-to have multiple classes defined for the same claim kind, but our sample has
-defined only one class for each resource type.
-
-Below we inspect each of these resource classes in more details:
-
-- **`CloudSQLInstanceClass`** Represents a resource that serves as a template to
- create a [Cloud SQL Database Instance][gcp-cloudsql].
-
- ```yaml
- ---
- apiVersion: database.gcp.crossplane.io/v1beta1
- kind: CloudSQLInstanceClass
- metadata:
- name: standard-mysql
- annotations:
- resourceclass.crossplane.io/is-default-class: "true"
- specTemplate:
- writeConnectionSecretsToNamespace: crossplane-system
- forProvider:
- databaseVersion: MYSQL_5_7
- region: us-central1
- settings:
- tier: db-n1-standard-1
- dataDiskType: PD_SSD
- dataDiskSizeGb: 10
- ipConfiguration:
- privateNetworkRef:
- name: sample-network
- reclaimPolicy: Delete
- providerRef:
- name: gcp-provider
- ```
-
-- **`GKEClusterClass`** Represents a resource that serves as a template to
- create a [Kubernetes Engine][gcp-gke] (GKE).
-
- ```yaml
- ---
- apiVersion: compute.gcp.crossplane.io/v1alpha3
- kind: GKEClusterClass
- metadata:
- name: standard-cluster
- annotations:
- resourceclass.crossplane.io/is-default-class: "true"
- specTemplate:
- machineType: n1-standard-1
- numNodes: 1
- zone: us-central1-b
- networkRef:
- name: sample-network
- subnetworkRef:
- name: sample-subnetwork
- enableIPAlias: true
- clusterSecondaryRangeName: pods
- servicesSecondaryRangeName: services
- reclaimPolicy: Delete
- providerRef:
- name: gcp-provider
- ```
-
-These resources will be the default resource classes for the corresponding
-claims (`resourceclass.crossplane.io/is-default-class: "true"` annotation). For
-more details about resource claims and how they work, see the documentation on
-[resource claims][resource-claims-and-classes-docs], and [resource class selection].
-
-## Recap
-
-To recap what we've set up now in our environment:
-
-- A Crossplane Provider resource for GCP
-- A Network Configuration to have secure connectivity between resources
-- An CloudSQLInstanceClass and an GKEClusterClass with the right configuration to use
- the mentioned networking setup.
-
-## Next Steps
-
-Next we'll set up a Crossplane App Stack and use it! Head [back over to
-the Stacks Guide document][stacks-guide-continue] so we can pick up
-where we left off.
-
-
-[crossplane-concepts]: concepts.md
-[crossplane-cli]: https://github.com/crossplaneio/crossplane-cli/tree/release-0.2
-[crossplane-gcp-networking-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-resource-connectivity-mvp.md#google-cloud-platform
-[stacks-guide]: https://github.com/crossplaneio/crossplane/blob/master/docs/stacks-guide.md
-[gcp-credentials]: https://github.com/crossplaneio/crossplane/blob/master/cluster/examples/gcp-credentials.sh
-[gcp-enable-apis]: https://cloud.google.com/endpoints/docs/openapi/enable-api
-[gcp-assign-roles]: https://cloud.google.com/iam/docs/granting-roles-to-service-accounts
-[gcp]: https://cloud.google.com/
-[stacks-guide-continue]: https://github.com/crossplaneio/crossplane/blob/master/docs/stacks-guide.md#install-support-for-our-application-into-crossplane
-[sample-wordpress-stack]: https://github.com/crossplaneio/sample-stack-wordpress
-[stack-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#crossplane-stacks
-[stack-gcp]: https://github.com/crossplaneio/stack-gcp
-[resource-claims-and-classes-docs]: https://github.com/crossplaneio/crossplane/blob/master/docs/concepts.md#resource-claims-and-resource-classes
-[cloud-provider-setup-gcp]: https://github.com/crossplaneio/crossplane/blob/master/docs/cloud-providers/gcp/gcp-provider.md
-[gcp-network-configuration]: https://cloud.google.com/vpc/docs/vpc
-[Cross Resource Referencing]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-cross-resource-referencing.md
-[sample GCP resource classes]: https://github.com/crossplaneio/crossplane/tree/master/cluster/examples/workloads/kubernetes/wordpress/gcp/resource-classes?ref=release-0.4
-[gcp-cloudsql]: https://cloud.google.com/sql/
-[gcp-gke]: https://cloud.google.com/kubernetes-engine/
-[sample GCP network configuration]: https://github.com/crossplaneio/crossplane/tree/master/cluster/examples/workloads/kubernetes/wordpress/gcp/network-config?ref=release-0.4
-[gcp-ip-address]: https://cloud.google.com/compute/docs/ip-addresses/
-[gcp-connection]: https://cloud.google.com/vpc/docs/configure-private-services-access
-[resource class selection]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-simple-class-selection.md
-[gcp-provider-guide]: cloud-providers/gcp/gcp-provider.md
diff --git a/docs/v0.4/stacks-guide-rook.md b/docs/v0.4/stacks-guide-rook.md
deleted file mode 100644
index 0bba3979..00000000
--- a/docs/v0.4/stacks-guide-rook.md
+++ /dev/null
@@ -1,873 +0,0 @@
----
-title: "Stacks Guide: Rook"
-toc: true
-weight: 550
-indent: true
----
-
-# Stacks Guide: Rook
-
-> Note: this guide does not follow along with the other stacks guides. It
-> deploys a different application (Yugastore) and involves using the GCP stack
-> along with the Rook stack.
-
-This user guide will walk you through [Yugastore] application deployment using
-Crossplane's [Rook] stack to run [YugabyteDB] in a Google Cloud [GKE] Kubernetes
-cluster. To do so, we will broadly:
-
-1. Provision a GKE Kubernetes cluster
-1. Install the Rook [Yugabyte operator] into the GKE cluster
-1. Provision a YugabyteDB cluster and deploy the Yugastore app into the GKE
- cluster
-
-... all using Crossplane!
-
-## Table of Contents
-
-1. [Pre-requisites](#pre-requisites)
-1. [Preparation](#preparation)
-1. [Set Up Crossplane](#set-up-crossplane)
- 1. [Install in Standalone Control
- Cluster](#install-in-standalone-control-cluster)
- 1. [GCP Provider](#gcp-provider)
- 1. [Rook Provider](#rook-provider)
- 1. [Resource Classes](#resource-classes)
-1. [Provision Target Cluster](#provision-target-cluster)
- 1. [Provision GKE Cluster with a Resource
- Claim](#provision-gke-cluster-with-a-resource-claim)
- 1. [Install Rook Yugabyte Operator with a
- KubernetesApplication](#install-rook-yugabyte-operator-with-a-kubernetesapplication)
-1. [Deploy Yugastore into Target Cluster](#deploy-yugastore-into-target-cluster)
- 1. [Provision YugabyteDB with a Resource
- Claim](#provision-yugabytedb-with-a-resource-claim)
- 1. [Provision Yugastore with a
- KubernetesApplication](#provision-yugastore-with-a-kubernetesapplication)
-1. [Results](#results)
-1. [Cleanup](#cleanup)
-1. [Conclusion and Next Steps](#conclusion-and-next-steps)
-
-## Pre-requisites
-
-These tools are required to complete this guide. They must be installed on your
-local machine.
-
-* [kubectl][install-kubectl]
- * kubectl also be installed using the Azure CLI: `az aks install-cli`
-* [Helm][using-helm], minimum version `v2.10.0+`.
-
-
-## Preparation
-
-This guide assumes that you have an existing Kubernetes cluster, which will
-serve as the Crossplane control cluster. Good options for running local
-Kubernetes clusters include [KIND] and [Minikube].
-
-In order to utilize GCP services, we must set the `PROJECT_ID` of the GCP
-project we want to use. Run the following:
-```bash
-export PROJECT_ID=crossplane-playground # the project that all resources reside.
-```
-
-## Set Up Crossplane
-
-### Install in Standalone Control Cluster
-
-Using your local Kubernetes cluster:
-
-1. Install Crossplane from the alpha channel. (See the [Crossplane Installation
- Guide][crossplane-install] for more information.)
-
-```bash
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-2. Install the GCP stack into Crossplane. (See the [GCP stack
- section][gcp-stack-install] of the install guide for more information.)
-
-```bash
-cat > stack-gcp.yaml < stack-rook.yaml < gcp-provider.yaml < gkeclass.yaml < yugabyteclass.yaml < k8sclaim.yaml < rook-operator.yaml < yugabyteclaim.yaml < yugastore.yaml <
-[Yugastore]: https://github.com/yugabyte/yugastore
-[Rook]: https://rook.io/
-[Yugabyte operator]: https://rook.io/docs/rook/v1.1/yugabytedb.html
-[YugabyteDB]: https://www.yugabyte.com/
-[GKE]: https://cloud.google.com/kubernetes-engine/
-
-[KIND]: https://kind.sigs.k8s.io/
-[Minikube]: https://github.com/kubernetes/minikube
-
-[install-kubectl]: https://kubernetes.io/docs/tasks/tools/install-kubectl/
-[using-helm]: https://docs.helm.sh/using_helm/
-
-[crossplane-install]: install-crossplane.md#alpha
-[gcp-stack-install]: install-crossplane.md#gcp-stack
-[rook-stack-install]: install-crossplane.md#rook-stack
-[cloud-creds]: cloud-providers/gcp/gcp-provider.md
-
-[CustomResourceDefinition]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
-[instance]: https://rook.io/docs/rook/v1.1/yugabytedb-cluster-crd.html
-[operator YAML]: https://github.com/rook/rook/blob/master/cluster/examples/kubernetes/yugabytedb/operator.yaml
-[complex-workload-design]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-complex-workloads.md#design
-
-[services]: services-guide.md
-[stacks]: stacks-guide.md
diff --git a/docs/v0.4/stacks-guide.md b/docs/v0.4/stacks-guide.md
deleted file mode 100644
index 5b2b7796..00000000
--- a/docs/v0.4/stacks-guide.md
+++ /dev/null
@@ -1,364 +0,0 @@
----
-title: "Stacks Guide"
-toc: true
-weight: 510
-indent: false
----
-
-# Stacks Guide
-
-
-## Table of Contents
-
-1. [Introduction](#introduction)
-2. [Concepts](#concepts)
-3. [Before you get started](#before-you-get-started)
-4. [Install the Crossplane CLI](#install-the-crossplane-cli)
-5. [Install and configure Crossplane](#install-and-configure-crossplane)
-6. [Install support for our application into
- Crossplane](#install-support-for-our-application-into-crossplane)
-7. [Create a Wordpress](#create-a-wordpress)
-8. [Clean up](#clean-up)
-9. [Conclusion](#conclusion)
-10. [Next steps](#next-steps)
-11. [References](#references)
-
-## Introduction
-
-Welcome to the Crossplane Stack guide! In this document, we will:
-
-* Learn how to install an existing stack
-* Interact with a stack to see how to use it
-* Glimpse what is possible with a stack
-* Touch a little bit on how stacks work
-
-We will **not**:
-
-* Learn first principles (see the [concepts
- document][crossplane-concepts] for that level of detail)
-* Develop our own stack from scratch (go to [this development
- guide][stack-developer-guide] to learn how to do that)
-
-Let's go!
-
-## Concepts
-
-There are a bunch of things you might want to know to fully understand
-what's happening in this document. This guide won't cover them, but
-there are other ones that do. Here are some links!
-
-* [Crossplane concepts][crossplane-concepts]
-* [Kubernetes concepts][kubernetes-concepts]
-
-## Before you get started
-
-This guide assumes you are using a *nix-like environment. It also
-assumes you have a basic working familiarity with the following:
-
-* The terminal environment
-* Setting up cloud provider accounts for the cloud provider you want to
- use
-* [Kubernetes][kubernetes-docs] and [kubectl][kubectl-docs]
-
-You will need:
-
-* A *nix-like environment
-* A cloud provider account, for the cloud provider of your choice (out
- of the supported providers)
-* A locally-configured kubectl which points to a configured Kubernetes
- cluster. We will put Crossplane in this cluster, and we'll refer to it
- as the control cluster.
-
-## Install the Crossplane CLI
-
-To interact with stacks, we're going to use the [Crossplane
-CLI][crossplane-cli], because it's more convenient. To install it, we
-can use the one-line curl bash:
-
-```
-RELEASE=v0.2.0 && curl -sL https://raw.githubusercontent.com/crossplaneio/crossplane-cli/"${RELEASE}"/bootstrap.sh | RELEASE=${RELEASE} bash
-```
-
-To use the latest release, you can use `master` as the `RELEASE` instead
-of using a specific version.
-
-## Install and configure Crossplane
-
-To use Crossplane, we'll need to install and configure it. In this case,
-we want to use Crossplane with a cloud provider, so we'll need to
-configure the provider.
-
-### Install Crossplane
-
-The recommended way of installing Crossplane is by using
-[helm][helm-install]. We can grab the most stable version currently
-available by using:
-
-```
-helm repo add crossplane-alpha https://charts.crossplane.io/alpha
-helm install --name crossplane --namespace crossplane-system crossplane-alpha/crossplane
-```
-
-For more options for installing, including how to install a more
-bleeding-edge version, or how to uninstall, see the [full install
-documentation][crossplane-install-docs].
-
-### Create the application namespace
-
-[Kubernetes namespaces][kubernetes-namespaces-docs] are used to isolate
-resources in the same cluster, and we'll use them in our Crossplane
-control cluster too. Let's create a namespace for our application's
-resources. We'll call it `app-project1-dev` for the purposes of this
-guide, but any name can be used.
-
-```
-kubectl create namespace app-project1-dev
-```
-
-The reason we need to create the namespace before we configure the cloud
-provider is because we will be setting up some cloud provider
-configuration in that namespace. The configuration will help our
-application not care about which specific provider it uses. For more
-details on how this works, see the Crossplane documentation on [portable
-classes][portable-classes-docs].
-
-### Configure support for your cloud provider
-
-Next we'll set up support for our cloud provider of choice! See the
-provider-specific guides:
-
-* [AWS][aws-setup]
-* [GCP][gcp-setup]
-* [Azure][azure-setup]
-
-Then come back here! Don't worry; we'll still be here when you're ready.
-
-Don't see your favorite cloud provider? [Help us add
-support][provider-stack-developer-guide] for it!
-
-## Install support for our application into Crossplane
-
-Now that we've got Crossplane set up and configured to use a cloud
-provider, we're ready to add support for creating WordPresses! We'll do
-this using a Crossplane Stack. For more information about stacks, see
-the [full Stack documentation][stack-docs].
-
-We can use the [Crossplane CLI][crossplane-cli] to install our stack which adds support for
-Wordpress. Let's install it into a namespace for our project, which
-we'll call `app-project1-dev` for the purposes of this guide. To install
-to the current namespace, `install` can be used, but since we want to
-install to a specific namespace, we will use `generate-install`:
-
-```
-kubectl crossplane stack generate-install 'crossplane/sample-stack-wordpress:latest' 'sample-stack-wordpress' | kubectl apply --namespace app-project1-dev -f -
-```
-
-Using the `generate-install` command and piping the output to `kubectl
-apply` instead of using the `install` command gives us more control over
-how the stack's installation is handled. Everything is a Kubernetes
-object!
-
-This pulls the stack package from a registry to install it into
-Crossplane. For more details about how to use the CLI, see the
-[documentation for the CLI][crossplane-cli-docs]. For more details about how stacks work behind
-the scenes, see the documentation about the [stack
-manager][stack-manager-docs] and the [stack
-format][stack-format-docs].
-
-## Create a Wordpress
-
-Now that Crossplane supports Wordpress creation, we can ask Crossplane
-to spin up a Wordpress for us. We can do this by creating a Kubernetes
-resource that our Wordpress stack will recognize:
-
-```
-cat > my-wordpress.yaml <
-[crossplane-cli]: https://github.com/crossplaneio/crossplane-cli/tree/release-0.2
-[crossplane-cli-docs]: https://github.com/crossplaneio/crossplane-cli/blob/release-0.2/README.md
-[crossplane-concepts]: concepts.md
-[crossplane-install-docs]: install-crossplane.md
-[crossplane-api-reference]: api.md
-
-[kubernetesapplicationresource-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-complex-workloads.md
-[claims-docs]: concepts.md#resource-claims-and-resource-classes
-[resource-classes-docs]: concepts.md#resource-claims-and-resource-classes
-[portable-classes-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-default-resource-class.md
-[workloads-docs]: concepts.md#resources-and-workloads
-
-[kubernetes-concepts]: https://kubernetes.io/docs/concepts/
-[kubernetes-docs]: https://kubernetes.io/docs/home/
-[kubernetes-namespaces-docs]: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
-[kubectl-docs]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
-
-[helm-install]: https://github.com/helm/helm#install
-
-[aws-docs]: https://docs.aws.amazon.com/
-[gcp-docs]: https://cloud.google.com/docs/
-[azure-docs]: https://docs.microsoft.com/azure/
-
-[aws-setup]: stacks-guide-aws.md
-[gcp-setup]: stacks-guide-gcp.md
-[azure-setup]: stacks-guide-azure.md
-
-[stack-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#crossplane-stacks
-[stack-quick-start]: https://github.com/crossplaneio/crossplane-cli/tree/release-0.2#quick-start-stacks
-[stack-concepts]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#crossplane-stacks
-[stack-registry]: https://hub.docker.com/search?q=crossplane&type=image
-[stack-manager-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#installation-flow
-[stack-format-docs]: https://github.com/crossplaneio/crossplane/blob/master/design/design-doc-stacks.md#stack-package-format
-[stack-developer-guide]: developer-guide.md
-[provider-stack-developer-guide]: developer-guide.md
diff --git a/docs/v0.4/troubleshoot.md b/docs/v0.4/troubleshoot.md
deleted file mode 100644
index f2f65aec..00000000
--- a/docs/v0.4/troubleshoot.md
+++ /dev/null
@@ -1,133 +0,0 @@
----
-title: Troubleshooting
-toc: true
-weight: 820
-indent: true
----
-# Troubleshooting
-
-* [Using the trace command](#using-the-trace-command)
-* [Resource Status and Conditions](#resource-status-and-conditions)
-* [Crossplane Logs](#crossplane-logs)
-* [Pausing Crossplane](#pausing-crossplane)
-* [Deleting a Resource Hangs](#deleting-a-resource-hangs)
-
-## Using the trace command
-
-The [Crossplane CLI](https://github.com/crossplaneio/crossplane-cli) trace
-command provides a holistic view for a particular object and related
-ones to ease debugging and troubleshooting process. It finds the
-relevant Crossplane resources for a given one and provides detailed
-information as well as an overview indicating what could be wrong.
-
-Usage:
-```
-kubectl crossplane trace TYPE[.GROUP] NAME [-n| --namespace NAMESPACE] [--kubeconfig KUBECONFIG] [-o| --outputFormat dot]
-```
-
-Examples:
-```
-# Trace a KubernetesApplication
-kubectl crossplane trace KubernetesApplication wordpress-app-83f04457-0b1b-4532-9691-f55cf6c0da6e -n app-project1-dev
-
-# Trace a MySQLInstance
-kubectl crossplane trace MySQLInstance wordpress-mysql-83f04457-0b1b-4532-9691-f55cf6c0da6e -n app-project1-dev
-```
-
-For more information, see [the trace command documentation](https://github.com/crossplaneio/crossplane-cli/tree/master/docs/trace-command.md).
-
-## Resource Status and Conditions
-
-Most Crossplane resources have a `status` section that can represent the current
-state of that particular resource. Running `kubectl describe` against a
-Crossplane resource will frequently give insightful information about its
-condition. For example, to determine the status of a MySQLInstance resource
-claim, run:
-
-```shell
-kubectl -n app-project1-dev describe mysqlinstance mysql-claim
-```
-
-This should produce output that includes:
-
-```console
-Status:
- Conditions:
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Managed claim is waiting for managed resource to become bindable
- Status: False
- Type: Ready
- Last Transition Time: 2019-09-16T13:46:42Z
- Reason: Successfully reconciled managed resource
- Status: True
- Type: Synced
-```
-
-Most Crossplane resources set exactly two condition types; `Ready` and `Synced`.
-`Ready` represents the availability of the resource itself - whether it is
-creating, deleting, available, unavailable, binding, etc. `Synced` represents
-the success of the most recent attempt to 'reconcile' the _desired_ state of the
-resource with its _actual_ state. The `Synced` condition is the first place you
-should look when a Crossplane resource is not behaving as expected.
-
-## Crossplane Logs
-
-The next place to look to get more information or investigate a failure would
-be in the Crossplane pod logs, which should be running in the
-`crossplane-system` namespace. To get the current Crossplane logs, run the
-following:
-
-```shell
-kubectl -n crossplane-system logs -lapp=crossplane
-```
-
-Remember that much of Crossplane's functionality is provided by Stacks. You can
-use `kubectl logs` to view Stack logs too, though Stacks may not run in the
-`crossplane-system` namespace.
-
-## Pausing Crossplane
-
-Sometimes, for example when you encounter a bug. it can be useful to pause
-Crossplane if you want to stop it from actively attempting to manage your
-resources. To pause Crossplane without deleting all of its resources, run the
-following command to simply scale down its deployment:
-
-```bash
-kubectl -n crossplane-system scale --replicas=0 deployment/crossplane
-```
-
-Once you have been able to rectify the problem or smooth things out, you can unpause Crossplane simply by scaling its deployment back up:
-
-```bash
-kubectl -n crossplane-system scale --replicas=1 deployment/crossplane
-```
-
-Remember that much of Crossplane's functionality is provided by Stacks. You can
-use `kubectl scale` to pause Stack pods too, though Stacks may not run in the
-`crossplane-system` namespace.
-
-## Deleting a Resource Hangs
-
-The resources that Crossplane manages will automatically be cleaned up so as not
-to leave anything running behind. This is accomplished by using finalizers, but
-in certain scenarios the finalizer can prevent the Kubernetes object from
-getting deleted.
-
-To deal with this, we essentially want to patch the object to remove its
-finalizer, which will then allow it to be deleted completely. Note that this
-won't necessarily delete the external resource that Crossplane was managing, so
-you will want to go to your cloud provider's console and look there for any
-lingering resources to clean up.
-
-In general, a finalizer can be removed from an object with this command:
-
-```console
-kubectl patch