Merge pull request #41 from muvaf/sync-upstream-release-1.6

Sync upstream release 1.6

.github/workflows/configurations.yml

@@ -0,0 +1,130 @@
+name: Configurations
+
+on:
+  push:
+    branches:
+      - master
+      - release-*
+  workflow_dispatch: {}
+
+env:
+  DOCKER_USR: ${{ secrets.UPBOUND_XP_ROBOT_USR }}
+
+jobs:
+  getting-started-with-aws:
+    runs-on: ubuntu-18.04
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+        with:
+          submodules: true
+          fetch-depth: 0
+      # The tagger step uses the same logic in the build submodule to generate package tag
+      # https://github.com/upbound/build/blob/4f64913157a952dbe77cd9e05457d9abe695a1d4/makelib/common.mk#L193
+      - name: Set tag
+        run: echo "::set-output name=VERSION_TAG::$(git describe --dirty --always --tags | sed 's/-/./2' | sed 's/-/./2' )"
+        id: tagger
+      - name: Login to Docker
+        uses: docker/login-action@v1
+        if: env.DOCKER_USR != ''
+        with:
+          registry: registry.upbound.io
+          username: ${{ secrets.UPBOUND_XP_ROBOT_USR }}
+          password: ${{ secrets.UPBOUND_XP_ROBOT_PSW }}
+      - name: Build
+        uses: crossplane-contrib/[email protected]
+        with:
+          channel: master
+          version: current
+          command: build configuration -f docs/snippets/package/aws --name=getting-started-with-aws.xpkg
+      - name: Push
+        uses: crossplane-contrib/[email protected]
+        with:
+          command: push configuration -f docs/snippets/package/aws/getting-started-with-aws.xpkg registry.upbound.io/xp/getting-started-with-aws:${{ steps.tagger.outputs.VERSION_TAG }}
+
+  getting-started-with-aws-with-vpc:
+    runs-on: ubuntu-18.04
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+        with:
+          submodules: true
+          fetch-depth: 0
+      - name: Set tag
+        run: echo "::set-output name=VERSION_TAG::$(git describe --dirty --always --tags | sed 's/-/./2' | sed 's/-/./2' )"
+        id: tagger
+      - name: Login to Docker
+        uses: docker/login-action@v1
+        if: env.DOCKER_USR != ''
+        with:
+          registry: registry.upbound.io
+          username: ${{ secrets.UPBOUND_XP_ROBOT_USR }}
+          password: ${{ secrets.UPBOUND_XP_ROBOT_PSW }}
+      - name: Build
+        uses: crossplane-contrib/[email protected]
+        with:
+          channel: master
+          version: current
+          command: build configuration -f docs/snippets/package/aws-with-vpc --name=getting-started-with-aws-with-vpc.xpkg
+      - name: Push
+        uses: crossplane-contrib/[email protected]
+        with:
+          command: push configuration -f docs/snippets/package/aws-with-vpc/getting-started-with-aws-with-vpc.xpkg registry.upbound.io/xp/getting-started-with-aws-with-vpc:${{ steps.tagger.outputs.VERSION_TAG }}
+
+  getting-started-with-gcp:
+    runs-on: ubuntu-18.04
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+        with:
+          submodules: true
+          fetch-depth: 0
+      - name: Set tag
+        run: echo "::set-output name=VERSION_TAG::$(git describe --dirty --always --tags | sed 's/-/./2' | sed 's/-/./2' )"
+        id: tagger
+      - name: Login to Docker
+        uses: docker/login-action@v1
+        if: env.DOCKER_USR != ''
+        with:
+          registry: registry.upbound.io
+          username: ${{ secrets.UPBOUND_XP_ROBOT_USR }}
+          password: ${{ secrets.UPBOUND_XP_ROBOT_PSW }}
+      - name: Build
+        uses: crossplane-contrib/[email protected]
+        with:
+          channel: master
+          version: current
+          command: build configuration -f docs/snippets/package/gcp --name=getting-started-with-gcp.xpkg
+      - name: Push
+        uses: crossplane-contrib/[email protected]
+        with:
+          command: push configuration -f docs/snippets/package/gcp/getting-started-with-gcp.xpkg registry.upbound.io/xp/getting-started-with-gcp:${{ steps.tagger.outputs.VERSION_TAG }}
+
+  getting-started-with-azure:
+    runs-on: ubuntu-18.04
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+        with:
+          submodules: true
+          fetch-depth: 0
+      - name: Set tag
+        run: echo "::set-output name=VERSION_TAG::$(git describe --dirty --always --tags | sed 's/-/./2' | sed 's/-/./2' )"
+        id: tagger
+      - name: Login to Docker
+        uses: docker/login-action@v1
+        if: env.DOCKER_USR != ''
+        with:
+          registry: registry.upbound.io
+          username: ${{ secrets.UPBOUND_XP_ROBOT_USR }}
+          password: ${{ secrets.UPBOUND_XP_ROBOT_PSW }}
+      - name: Build
+        uses: crossplane-contrib/[email protected]
+        with:
+          channel: master
+          version: current
+          command: build configuration -f docs/snippets/package/azure --name=getting-started-with-azure.xpkg
+      - name: Push
+        uses: crossplane-contrib/[email protected]
+        with:
+          command: push configuration -f docs/snippets/package/azure/getting-started-with-azure.xpkg registry.upbound.io/xp/getting-started-with-azure:${{ steps.tagger.outputs.VERSION_TAG }}

cluster/composition/postgresqlinstance.yaml

@@ -33,9 +33,9 @@ spec:
             properties:
               engineVersion:
                 description: 'EngineVersion specifies the desired PostgreSQL engine
-                              version. Allowed Versions: 9.6 and 11.'
+                              version. Allowed Versions: 10 and 11.'
                 enum:
-                  - "9.6"
+                  - "10"
                   - "11"
                 type: string
               storageGB:

design/README.md

@@ -3,15 +3,15 @@
 This directory contains all documents informing Crossplane's design. Crossplane
 designs must transition through up to three of the following phases:
 
-1. Proposals. A proposal is simply a Github issue against this reposistory with
+1. Proposals. A proposal is simply a Github issue against this repository with
    the [`proposal` label][proposal-label]. Proposals need not be more than two
    to three paragraphs.
 2. One-pagers. A One-pager is a brief document pitching an idea for further
    experimentation. One-pagers, as the name suggests, are usually around one
    page long. They provide just enough context to achieve buy-in from Crossplane
    maintainers.
 3. Design documents. A design document is a longer, more detailed design. Design
-   documents should typically be preceeded by a one-pager and/or a good amount
+   documents should typically be preceded by a one-pager and/or a good amount
    of research and experimentation.
 
 All designs must start as a proposal. In some simple cases this proposal alone

design/defunct/design-doc-agent.md

@@ -277,7 +277,7 @@ agent needs to know the namespace that it should sync to in the central cluster.
 
 The easiest configuration would be the one where we specify the `Secret` and a
 target namespace via installation commands of the agent. Both of these inputs
-will act as default and they can be overriden for each `Namespace`
+will act as default and they can be overridden for each `Namespace`
 independently. For example, multiple namespaces can have different requirements
 with the same name which could cause conficts in the central cluster because all
 namespaces are rolled up into one namespace. In order to prevent conflicts, the

design/defunct/one-pager-packages-security-isolation.md

@@ -27,7 +27,7 @@ Instead, it is a centralized control plane intended to manage resources external
 There is not really a need for Packages being installed into the control plane to request arbitrary permissions.
 Crossplane can be more opinionated about the types of permissions granted within its control plane and lock things down in a more secure way.
 
-Futhermore, packages are currently scoped to a single type that is used in all scenarios and by all personas.
+Furthermore, packages are currently scoped to a single type that is used in all scenarios and by all personas.
 All new types of functionality, from an end user wanting to install a simple application to an administrator wanting to install support for low level infrastructure types, are all treated the same.
 They have the same approach to security and access control and the artifacts that they install have the same scope of impact to the control plane.
 This one size fits all approach is not ideal though; the multiple scenarios and personas need finer grain control around security, access, and isolation.

design/defunct/one-pager-template-stacks.md

@@ -56,7 +56,7 @@ and some set of cluster state.
 * **Crossplane Managed Cluster**
   : A Kubernetes cluster being managed by Crossplane, which may or may not have
   Crossplane installed within that cluster
-* **SM (Stack Manager)** : The cluster priviliged deployment that manages
+* **SM (Stack Manager)** : The cluster privileged deployment that manages
   `Stack`, `ClusterStackInstall` and `StackInstall` resources. One per
   Crossplane cluster. The Stack Manager creates `Deployment` resources as
   defined by a `Stack` to handle resources of the CRD types that `Stack`

design/design-doc-provider-strategy.md

@@ -343,7 +343,7 @@ spec:
     location: West US 2
     minimalTlsVersion: TLS12
     sslEnforcement: Disabled
-    version: "9.6"
+    version: "11"
     sku:
       tier: GeneralPurpose
       capacity: 2
@@ -363,7 +363,7 @@ spec:
     location: "East US"
     administratorLogin: "psqladminun"
     skuName: "GP_Gen5_4" # different than native where 3 fields are used.
-    version: "9.6"
+    version: "11"
     storageMb: 640000 # different than native where this is given under storageProfile
     publicNetworkAccessEnabled: true # schema same, but not supported in our native provider yet.
     sslEnforcementEnabled: true # in native, enum Disabled/Enabled instead of boolean
@@ -383,7 +383,7 @@ spec:
     location: West US 2
     minimalTlsVersion: TLS12
     sslEnforcement: Disabled
-    version: "9.6"
+    version: "11"
     sku:
       tier: GeneralPurpose
       capacity: 2
@@ -743,4 +743,4 @@ The costs that we will need to account for by this decision are roughly:
 * The separation will signal that the Terraform is not just an implementation
   detail, but in reality, it actually is.
   * The CRDs and controllers we generate are completely XRM-compliant and work
-    just like other resources from the end user perspective.
+    just like other resources from the end user perspective.

design/design-doc-rbac-manager.md

@@ -838,7 +838,7 @@ role binding. This alternative approach is appealing in that it leverages
 * Cluster roles must be manually cleaned up when a namespace is deleted.
 
 In all the difference between using namespace-aligned cluster roles and actual
-namespaced roles is neglible both in terms of functionality and complexity, so
+namespaced roles is negligible both in terms of functionality and complexity, so
 the decision comes down to which approach is more 'idiomatic'.
 
 [Aggregated ClusterRoles]: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles

design/one-pager-composition-revisions.md

@@ -102,7 +102,7 @@ spec:
         kind: CloudSQLInstance
         spec:
           forProvider:
-            databaseVersion: POSTGRES_9_6
+            databaseVersion: POSTGRES_12
             region: us-central1
             settings:
               tier: db-custom-1-3840
@@ -147,7 +147,7 @@ spec:
         kind: CloudSQLInstance
         spec:
           forProvider:
-            databaseVersion: POSTGRES_9_6
+            databaseVersion: POSTGRES_12
             region: us-central1
             settings:
               tier: db-custom-1-3840
@@ -305,4 +305,4 @@ straightforward to build if there is demand for the functionality.
 [metacontroller-controller-revisions]: https://metacontroller.github.io/metacontroller/api/controllerrevision.html
 [kubernetes-controller-revisions]: https://kubernetes.io/docs/tasks/manage-daemon/rollback-daemon-set/#understanding-daemonset-revisions
 [xr-to-composition]: images/xr-to-composition.svg
-[xr-to-revision]: images/xr-to-revision.svg
+[xr-to-revision]: images/xr-to-revision.svg

design/one-pager-k8s-native-providers.md

@@ -335,7 +335,7 @@ spec:
     name: postgresql-standard
   writeConnectionSecretToRef:
     name: postgresqlconn
-  engineVersion: "9.6"
+  engineVersion: "12"
 ```
 
 On creation of the `PostgreSQLInstance` claim, the claim controller would
@@ -559,4 +559,4 @@ func (c *ClusterController) SetupWithManager(mgr ctrl.Manager) error {
 [crossplane-runtime]: https://github.com/crossplane/crossplane-runtime
 [crossplane-runtime #22]: https://github.com/crossplane/crossplane-runtime/issues/22
 [crossplane-runtime #34]: https://github.com/crossplane/crossplane-runtime/issues/34
-[crossplane #859]: https://github.com/crossplane/crossplane/issues/859
+[crossplane #859]: https://github.com/crossplane/crossplane/issues/859

design/one-pager-managed-resource-api-design.md

@@ -503,7 +503,7 @@ what and we know that we'll get a full object body. However;
 * Pointer type should be used only if the corresponding field is pointer type in
   the provider's SDK type.
 
-Note that some required fields by all CRUD calls might be late-initalized. For
+Note that some required fields by all CRUD calls might be late-initialized. For
 example, a config parameter can only be fetched from the provider and CRUD
 operations except `Create` requires it. In those cases, mark the field as
 optional since at any step we may not have it.

design/one-pager-package-format-v2.md

@@ -121,7 +121,7 @@ spec:
   dependsOn:
     # Required. Specifies an OCI image containing a package dependency. This key
     # may be either 'provider' or 'configuration'. This is sugar; in either case
-    # the package manager determines whether the depencency is really a Provider
+    # the package manager determines whether the dependency is really a Provider
     # or a Configuration by unpacking it and inspecting its kind.
   - provider: example/provider-uncommon
     # Required. Will be extended to support version ranges in future, but
@@ -197,15 +197,15 @@ spec:
   dependsOn:
     # Required. Specifies an OCI image containing a package dependency. This key
     # may be either 'provider' or 'configuration'. This is sugar; in either case
-    # the package manager determines whether the depencency is really a Provider
+    # the package manager determines whether the dependency is really a Provider
     # or a Configuration by unpacking it and inspecting its kind.
   - provider: example/provider-example
     # Required. Will be extended to support version ranges in future, but
     # currently treated as a specific version tag.
     version: v0.1.0
     # Required. Specifies an OCI image containing a package dependency. This key
     # may be either 'provider' or 'configuration'. This is sugar; in either case
-    # the package manager determines whether the depencency is really a Provider
+    # the package manager determines whether the dependency is really a Provider
     # or a Configuration by unpacking it and inspecting its kind.
   - configuration: example/some-dependency
     # Required. Will be extended to support version ranges in future, but

docs/concepts/composition.md

@@ -150,7 +150,7 @@ spec:
       kind: CloudSQLInstance
       spec:
         forProvider:
-          databaseVersion: POSTGRES_9_6
+          databaseVersion: POSTGRES_12
           region: us-central1
           settings:
             tier: db-custom-1-3840

docs/concepts/managed-resources.md

@@ -40,7 +40,7 @@ of Crossplane managed resources. Following is an example of a managed resource:
 <div class="tab-content">
 <div class="tab-pane fade in active" id="aws-tab-1" markdown="1">
 
-The AWS provider supports provisioning an [RDS] instance via the `RDSInstance`
+The AWS provider supports provisioning an [RDS][rds] instance via the `RDSInstance`
 managed resource it adds to Crossplane.
 
 ```yaml
@@ -89,7 +89,7 @@ kubectl delete rdsinstance rdspostgresql
 </div>
 <div class="tab-pane fade" id="gcp-tab-1" markdown="1">
 
-The GCP provider supports provisioning a [CloudSQL] instance with the
+The GCP provider supports provisioning a [CloudSQL][cloudsql] instance with the
 `CloudSQLInstance` managed resource it adds to Crossplane.
 
 ```yaml
@@ -99,7 +99,7 @@ metadata:
   name: cloudsqlpostgresql
 spec:
   forProvider:
-    databaseVersion: POSTGRES_9_6
+    databaseVersion: POSTGRES_12
     region: us-central1
     settings:
       tier: db-custom-1-3840
@@ -361,7 +361,7 @@ 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:
+example from Azure MySQL managed resource referring to an Azure Resource Group:
 
 ```yaml
 spec:
@@ -438,10 +438,12 @@ using needs to store `annotations` and `spec` fields, which most tools do
 including Velero.
 
 [term-xrm]: terminology.md#crossplane-resource-model
+[rds]: https://aws.amazon.com/rds/
+[cloudsql]: https://cloud.google.com/sql
 [composition]: composition.md
 [api-versioning]: https://kubernetes.io/docs/reference/using-api/api-overview/#api-versioning
 [velero]: https://velero.io/
 [api-reference]: ../api-docs/overview.md
 [provider]: providers.md
 [issue-727]: https://github.com/crossplane/crossplane/issues/727
-[issue-1143]: https://github.com/crossplane/crossplane/issues/1143
+[issue-1143]: https://github.com/crossplane/crossplane/issues/1143

docs/contributing/provider_development_guide.md

@@ -319,7 +319,7 @@ 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
+under [What Makes a Crossplane Infrastructure Resource]. 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