diff --git a/.github/workflows/link-checker.yml b/.github/workflows/link-checker.yml
index 7967e6ad0..9209981af 100644
--- a/.github/workflows/link-checker.yml
+++ b/.github/workflows/link-checker.yml
@@ -19,7 +19,7 @@ jobs:
- name: Setup Hugo
uses: peaceiris/actions-hugo@v2
with:
- hugo-version: '0.109.0'
+ hugo-version: '0.119.0'
extended: true
- name: Build
diff --git a/.github/workflows/weekly-link-checker.yml b/.github/workflows/weekly-link-checker.yml
index 75baff01e..945296cc8 100644
--- a/.github/workflows/weekly-link-checker.yml
+++ b/.github/workflows/weekly-link-checker.yml
@@ -18,7 +18,7 @@ jobs:
- name: Setup Hugo
uses: peaceiris/actions-hugo@v2
with:
- hugo-version: '0.109.0'
+ hugo-version: '0.119.0'
extended: true
- name: Build
diff --git a/config.yaml b/config.yaml
index 90dfd2d5c..71523cfa6 100644
--- a/config.yaml
+++ b/config.yaml
@@ -51,7 +51,7 @@ security:
- ^REVIEW_ID
params:
- latest: "1.13"
+ latest: "1.14"
upboundLink: "https://www.upbound.io/"
slackLink: "https://slack.crossplane.io/"
githubLink: "https://github.com/crossplane/crossplane"
diff --git a/content/contribute/features.md b/content/contribute/features.md
index 06c9912a1..697f63169 100644
--- a/content/contribute/features.md
+++ b/content/contribute/features.md
@@ -123,9 +123,9 @@ Hugo to fail.
## Images
All images are in `/content/media`.
-Crossplane supports standard [Markdown image
-syntax](https://www.markdownguide.org/basic-syntax/#images-1) but using the
-`img` shortcode is strongly recommended.
+Crossplane supports standard
+[Markdown image syntax](https://www.markdownguide.org/basic-syntax/#images-1)
+but using the `img` shortcode is strongly recommended.
Images using the shortcode are automatically converted to `webp` image format,
compressed and use responsive image sizing.
@@ -157,8 +157,9 @@ Which generates this responsive image (change your browser size to see it change
{{}}
## Links
-Crossplane docs support standard [Markdown
-links](https://www.markdownguide.org/basic-syntax/#links) but Crossplane prefers link shortcodes
+Crossplane docs support standard
+[Markdown links](https://www.markdownguide.org/basic-syntax/#links)
+but Crossplane prefers link shortcodes
for links between docs pages. Using shortcodes prevents incorrect link creation
and notifies which links to change after moving a page.
@@ -187,8 +188,9 @@ If the `ref` value points to a page that doesn't exist, Hugo fails to start.
### Linking to external sites
Minimize linking to external sites. When linking to any page outside of
-`crossplane.io` use standard [markdown link
-syntax](https://www.markdownguide.org/basic-syntax/#links) without using the
+`crossplane.io` use standard
+[markdown link syntax](https://www.markdownguide.org/basic-syntax/#links)
+without using the
`ref` shortcode.
For example,
diff --git a/content/master/concepts/compositions.md b/content/master/concepts/compositions.md
index f9666c6d2..281e57d52 100644
--- a/content/master/concepts/compositions.md
+++ b/content/master/concepts/compositions.md
@@ -1322,8 +1322,8 @@ Composition.
## Composition validation
-When creating a Composition Crossplane automatically validates specific
-parameters in the Composition.
+When creating a Composition, Crossplane automatically validates its integrity,
+checking that the Composition is well formed, for example:
If using `mode: Resources`:
@@ -1344,47 +1344,78 @@ If using `mode: Pipeline` (Composition Functions):
* The `pipeline` field isn't empty.
* No duplicate step names.
-### Resource schema validation
-
-Optionally, Crossplane can also validate the schema of the resources defined
-inside a Composition. This verifies that the resource `apiVersion` and `kinds`
-are valid.
-
+### Composition schema aware validation
+
+Crossplane also performs schema aware
+validation of Compositions. Schema validation checks that `patches`,
+`readinessChecks` and `connectionDetails` are valid according to the resource
+schemas. For example, checking that the source and destination fields of a patch
+are valid according to the source and destination resource schema.
+
+{{}}
+Composition schema aware validation is a beta feature. Crossplane enables
+beta features by default.
+
+Disable schema aware validation by setting the
+`--enable-composition-webhook-schema-validation=false` flag on the Crossplane
+pod.
-Enable "schema validation" with the
-`--enable-composition-webhook-schema-validation` flag on the Crossplane pod.
The [Crossplane Pods]({{[}}) page has
more information on enabling Crossplane flags.
+{{< /hint >}}
+
+#### Schema aware validation modes
+
+Crossplane always rejects Compositions in case of integrity errors.
+
+Set the schema aware validation mode to configure how Crossplane handles both
+missing resource schemas and schema aware validation errors.
{{}}
-
-Schema validation only checks the `apiVersion` and `kind` are valid. Schema
-validation doesn't validate the fields of a specific resource.
-
+If a resource schema is missing, Crossplane skips schema aware validation
+but still returns an error for integrity errors and a warning or an error
+for the missing schemas.
{{< /hint >}}
-The default validations are still checked with schema validation enabled.
-#### Validation modes
+The following modes are available:
-Schema validation supports two modes:
-* `loose` (default) - Sends an warning for each schema error and installs the
- Composition if the default validations pass.
-* `strict` - Send an error for every schema validation error and rejects the
- Composition.
+{{< table "table table-sm table-striped" >}}
+| Mode | Missing Schema | Schema Aware Error | Integrity Error |
+| -------- | -------------- |--------------------|-----------------|
+| `warn` | Warning | Warning | Error |
+| `loose` | Warning | Error | Error |
+| `strict` | Error | Error | Error |
+{{< /table >}}
Change the validation mode for a Composition with the
-{{}}crossplane.io/composition-validation-mode{{}}
-annotation.
+{{}}crossplane.io/composition-schema-aware-validation-mode{{}}
+annotation.
+
+If not specified, the default mode is `warn`.
-For example, to enable `strict` mode checking:
+For example, to enable `loose` mode checking set the annotation value to
+{{}}loose{{}}.
```yaml {copy-lines="none",label="mode"}
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
annotations:
- crossplane.io/composition-validation-mode: strict
+ crossplane.io/composition-schema-aware-validation-mode: loose
# Removed for brevity
spec:
# Removed for brevity
```
+
+{{}}
+Validation modes also apply to Compositions defined by Configuration packages.
+
+Depending on the mode configured in the Composition, schema aware validation
+issues may result in warnings or the rejection of the Composition.
+
+View the Crossplane logs for validation warnings.
+
+Crossplane sets a Configuration as unhealthy if there are validation errors.
+View the Configuration details with `kubectl describe configuration` to see the
+specific errors.
+{{< /hint >}}
diff --git a/content/master/concepts/environment-configs.md b/content/master/concepts/environment-configs.md
index d05190172..586c5725c 100644
--- a/content/master/concepts/environment-configs.md
+++ b/content/master/concepts/environment-configs.md
@@ -1,6 +1,6 @@
---
title: Environment Configurations
-weight: 90
+weight: 75
state: alpha
alphaVersion: "1.11"
description: "Environment Configurations or EnvironmentConfigs are an in-memory datastore used in patching Compositions"
diff --git a/content/master/concepts/managed-resources.md b/content/master/concepts/managed-resources.md
index e7bb4d51f..f054a1be4 100644
--- a/content/master/concepts/managed-resources.md
+++ b/content/master/concepts/managed-resources.md
@@ -308,8 +308,9 @@ spec:
### managementPolicies
-{{}}
-The managed resource `managementPolicies` option is an alpha feature.
+{{}}
+The managed resource `managementPolicies` option is a beta feature. Crossplane enables
+beta features by default.
The Provider determines support for management policies.
Refer to the Provider's documentation to see if the Provider supports
diff --git a/content/master/concepts/providers.md b/content/master/concepts/providers.md
index 576475456..1b723ae8f 100644
--- a/content/master/concepts/providers.md
+++ b/content/master/concepts/providers.md
@@ -600,7 +600,7 @@ a future release.
[`DeploymentRuntimeConfig`]({{][}}) is the
-replacement for Controller configuration and is available in v1.14.
+replacement for Controller configuration and is available in v1.14+.
{{< /hint >}}
Applying a Crossplane `ControllerConfig` to a Provider changes the settings of
diff --git a/content/master/concepts/usages.md b/content/master/concepts/usages.md
index f8858c50d..b8f8c8e36 100644
--- a/content/master/concepts/usages.md
+++ b/content/master/concepts/usages.md
@@ -189,7 +189,7 @@ spec:
baz: qux
```
-## Usage in a composition
+## Usage in a Composition
A typical use case for Usages is to define a deletion ordering between the
resources in a Composition. The Usages support
diff --git a/content/master/software/install.md b/content/master/software/install.md
index 84c458a30..874f1aef6 100644
--- a/content/master/software/install.md
+++ b/content/master/software/install.md
@@ -245,10 +245,10 @@ at the table below.
{{< table caption="Feature flags" >}}
| Status | Flag | Description |
| --- | --- | --- |
-| Beta | `--enable-composition-revisions` |Enable support for CompositionRevisions. |
-| Beta | `--enable-deployment-runtime-configs` |Enable support for Deployment Runtime Configurations. |
+| Beta | `--enable-composition-revisions` |Enable support for CompositionRevisions |
+| Beta | `--enable-composition-webhook-schema-validation` | Enable Composition validation using schemas. |
+| Beta | `--enable-deployment-runtime-configs` |Enable support for Deployment Runtime Configs. |
| Alpha | `--enable-composition-functions` | Enable support for Composition Functions. |
-| Alpha | `--enable-composition-webhook-schema-validation` | Enable Composition validation using schemas. |
| Alpha | `--enable-environment-configs` | Enable support for EnvironmentConfigs. |
| Alpha | `--enable-external-secret-stores` | Enable support for External Secret Stores. |
| Alpha | `--enable-usages` | Enable support for Usages. |
diff --git a/content/v1.11/concepts/composition.md b/content/v1.11/concepts/composition.md
deleted file mode 100644
index ac2fdffa3..000000000
--- a/content/v1.11/concepts/composition.md
+++ /dev/null
@@ -1,1277 +0,0 @@
----
-title: Composite Resources
-weight: 103
----
-
-Crossplane Composite Resources are opinionated Kubernetes Custom Resources that
-are _composed_ of [Managed Resources][managed-resources]. We often call them XRs
-for short.
-
-![Diagram of claims, XRs, and Managed Resources][xrs-and-mrs]
-
-Composite Resources are designed to let you build your own platform with your
-own opinionated concepts and APIs without needing to write a Kubernetes
-controller from scratch. Instead, you define the schema of your XR and teach
-Crossplane which Managed Resources it should compose (i.e. create) when someone
-creates the XR you defined.
-
-If you're already familiar with Composite Resources and looking for a detailed
-configuration reference or some tips, tricks, and troubleshooting information,
-try the [Composition Reference][xr-ref].
-
-Below is an example of a Composite Resource:
-
-```yaml
-apiVersion: database.example.org/v1alpha1
-kind: XPostgreSQLInstance
-metadata:
- name: my-db
-spec:
- parameters:
- storageGB: 20
- compositionRef:
- name: production
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: my-db-connection-details
-```
-
-You define your own XRs, so they can be of whatever API version and kind you
-like, and contain whatever spec and status fields you need.
-
-## How It Works
-
-The first step towards using Composite Resources is configuring Crossplane so
-that it knows what XRs you'd like to exist, and what to do when someone creates
-one of those XRs. This is done using a `CompositeResourceDefinition` (XRD)
-resource and one or more `Composition` resources.
-
-Once you've configured Crossplane with the details of your new XR you can either
-create one directly, or use a _claim_. Typically only the folks responsible for
-configuring Crossplane (often a platform or SRE team) have permission to create
-XRs directly. Everyone else manages XRs via a lightweight proxy resource called
-a Composite Resource Claim (or claim for short). More on that later.
-
-![Diagram combining all Composition concepts][how-it-works]
-
-> If you're coming from the Terraform world you can think of an XRD as similar
-> to the `variable` blocks of a Terraform module, while the `Composition` is
-> the rest of the module's HCL code that describes how to use those variables to
-> create a bunch of resources. In this analogy the XR or claim is a little like
-> a `tfvars` file providing inputs to the module.
-
-### Defining Composite Resources
-
-A `CompositeResourceDefinition` (or XRD) defines the type and schema of your XR.
-It lets Crossplane know that you want a particular kind of XR to exist, and what
-fields that XR should have. An XRD is a little like a `CustomResourceDefinition`
-(CRD), but slightly more opinionated. Writing an XRD is mostly a matter of
-specifying an OpenAPI ["structural schema"][crd-docs].
-
-The XRD that defines the `XPostgreSQLInstance` XR above would look like this:
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-metadata:
- name: xpostgresqlinstances.database.example.org
-spec:
- group: database.example.org
- names:
- kind: XPostgreSQLInstance
- plural: xpostgresqlinstances
- claimNames:
- kind: PostgreSQLInstance
- plural: postgresqlinstances
- 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
-```
-
-You might notice that the `XPostgreSQLInstance` example above has some fields
-that don't appear in the XRD, like the `writeConnectionSecretToRef` and
-`compositionRef` fields. This is because Crossplane automatically injects some
-standard Crossplane Resource Model (XRM) fields into all XRs.
-
-### Configuring Composition
-
-A `Composition` lets Crossplane know what to do when someone creates a Composite
-Resource. Each `Composition` creates a link between an XR and a set of one or
-more Managed Resources - when the XR is created, updated, or deleted the set of
-Managed Resources are created, updated or deleted accordingly.
-
-You can add multiple Compositions for each XRD, and choose which should be used
-when XRs are created. This allows a Composition to act like a class of service -
-for example you could configure one Composition for each environment you
-support, such as production, staging, and development.
-
-A basic `Composition` for the above `XPostgreSQLInstance` might look like this:
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-metadata:
- name: example
- labels:
- crossplane.io/xrd: xpostgresqlinstances.database.example.org
- provider: gcp
-spec:
- writeConnectionSecretsToNamespace: crossplane-system
- compositeTypeRef:
- apiVersion: database.example.org/v1alpha1
- kind: XPostgreSQLInstance
- resources:
- - name: cloudsqlinstance
- base:
- apiVersion: database.gcp.crossplane.io/v1beta1
- kind: CloudSQLInstance
- spec:
- forProvider:
- databaseVersion: POSTGRES_12
- region: us-central1
- settings:
- tier: db-custom-1-3840
- dataDiskType: PD_SSD
- ipConfiguration:
- ipv4Enabled: true
- authorizedNetworks:
- - value: "0.0.0.0/0"
- patches:
- - type: FromCompositeFieldPath
- fromFieldPath: spec.parameters.storageGB
- toFieldPath: spec.forProvider.settings.dataDiskSizeGb
-```
-
-The above `Composition` tells Crossplane that when someone creates an
-`XPostgreSQLInstance` XR Crossplane should create a `CloudSQLInstance` in
-response. The `storageGB` field of the `XPostgreSQLInstance` should be used to
-configure the `dataDiskSizeGb` field of the `CloudSQLInstance`. This is only a
-small subset of the functionality a `Composition` enables - take a look at the
-[reference page][xr-ref] to learn more.
-
-> We almost always talk about XRs composing Managed Resources, but actually an
-> XR can also compose other XRs to allow nested layers of abstraction. XRs don't
-> support composing arbitrary Kubernetes resources (e.g. Deployments, operators,
-> etc) directly but you can do so using our [Kubernetes][provider-kubernetes]
-> and [Helm][provider-helm] providers.
-
-### Claiming Composite Resources
-
-Crossplane uses Composite Resource Claims (or just claims, for short) to allow
-application operators to provision and manage XRs. When we talk about using XRs
-it's typically implied that the XR is being used via a claim. Claims are almost
-identical to their corresponding XRs. It helps to think of a claim as an
-application team’s interface to an XR. You could also think of claims as the
-public (app team) facing part of the opinionated platform API, while XRs are the
-private (platform team) facing part.
-
-A claim for the `XPostgreSQLInstance` XR above would look like this:
-
-```yaml
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstance
-metadata:
- namespace: default
- name: my-db
-spec:
- parameters:
- storageGB: 20
- compositionRef:
- name: production
- writeConnectionSecretToRef:
- name: my-db-connection-details
-```
-
-There are three key differences between an XR and a claim:
-
-1. Claims are namespaced, while XRs (and Managed Resources) are cluster scoped.
-1. Claims are of a different `kind` than the XR - by convention the XR's `kind`
- without the proceeding `X`. For example a `PostgreSQLInstance` claims an
- `XPostgreSQLInstance`.
-1. An active claim contains a reference to its corresponding XR, while an XR
- contains both a reference to the claim an array of references to the managed
- resources it composes.
-
-Not all XRs offer a claim - doing so is optional. See the XRD section of the
-[Composition reference][xr-ref] to learn how to offer a claim.
-
-![Diagram showing the relationship between claims and XRs][claims-and-xrs]
-
-Claims may seem a little superfluous at first, but they enable some handy
-scenarios, including:
-
-- **Private XRs.** Sometimes a platform team might not want a type of XR to be
- directly consumed by their application teams. For example because the XR
- represents 'supporting' infrastructure - consider the above VPC `XNetwork` XR. App
- teams might create `PostgreSQLInstance` claims that _reference_ (i.e. consume)
- an `XNetwork`, but they shouldn't be _creating their own_. Similarly, some
- kinds of XR might be intended only for 'nested' use - intended only to be
- composed by other XRs.
-
-- **Global XRs**. Not all infrastructure is conceptually namespaced. Say your
- organisation uses team scoped namespaces. A `PostgreSQLInstance` that belongs
- to Team A should probably be part of the `team-a` namespace - you'd represent
- this by creating a `PostgreSQLInstance` claim in that namespace. On the other
- hand the `XNetwork` XR we mentioned previously could be referenced (i.e. used)
- by XRs from many different namespaces - it doesn't exist to serve a particular
- team.
-
-- **Pre-provisioned XRs**. Finally, separating claims from XRs allows a platform
- team to pre-provision certain kinds of XR. Typically an XR is created
- on-demand in response to the creation of a claim, but it's also possible for a
- claim to instead request an existing XR. This can allow application teams to
- instantly claim infrastructure like database instances that would otherwise
- take minutes to provision on-demand.
-
-
-This reference provides detailed examples of defining, configuring, and using
-Composite Resources in Crossplane. You can also refer to Crossplane's [API
-documentation][api-docs] for more details. If you're looking for a more general
-overview of Composite Resources and Composition in Crossplane, try the
-[Composite Resources][xr-concepts] page under Concepts.
-
-## Composite Resources and Claims
-
-The type and most of the schema of Composite Resources and claims are largely of
-your own choosing, but there is some common 'machinery' injected into them.
-Here's a hypothetical XR that doesn't have any user-defined fields and thus only
-includes the automatically injected Crossplane machinery:
-
-```yaml
-apiVersion: database.example.org/v1alpha1
-kind: XPostgreSQLInstance
-metadata:
- # This XR was created automatically by a claim, so its name is derived from
- # the claim's name.
- name: my-db-mfd1b
- annotations:
- # The external name annotation has special meaning in Crossplane. When a
- # claim creates an XR its external name will automatically be propagated to
- # the XR. Whether and how the external name is propagated to the resources
- # the XR composes is up to its Composition.
- crossplane.io/external-name: production-db-0
-spec:
- # XRs have a reference to the claim that created them (or, if the XR was
- # pre-provisioned, to the claim that later claimed them).
- claimRef:
- apiVersion: database.example.org/v1alpha1
- kind: PostgreSQLInstance
- name: my-db
- # The compositeDeletePolicy specifies the propagation policy that will be used by Crossplane
- # when deleting the Composite Resource that is associated with the Claim. The default
- # value is Background, which causes the Composite resource to be deleted using
- # the kubernetes default propagation policy of Background, and all associated
- # resources will be deleted simultaneously. The other value for this field is Foreground,
- # which will cause the Composite resource to be deleted using Foreground Cascading Deletion.
- # Kubernetes will add a foregroundDeletion finalizer to all of the resources in the
- # dependency graph, and they will be deleted starting with the edge or leaf nodes and
- # working back towards the root Composite. See https://kubernetes.io/docs/concepts/architecture/garbage-collection/#cascading-deletion
- # for more information on cascading deletion.
- compositeDeletePolicy: Background
- # The compositionRef specifies which Composition this XR will use to compose
- # resources when it is created, updated, or deleted. This can be omitted and
- # will be set automatically if the XRD has a default or enforced composition
- # reference, or if the below composition selector is set.
- compositionRef:
- name: production-us-east
- # The compositionSelector allows you to match a Composition by labels rather
- # than naming one explicitly. It is used to set the compositionRef if none is
- # specified explicitly.
- compositionSelector:
- matchLabels:
- environment: production
- region: us-east
- provider: gcp
- # The environment is an in-memory object that can be patched from / to during
- # rendering.
- # The environment is composed by merging the 'data' of all EnvironmentConfigs
- # referenced below. It is disposed after every reconcile.
- # NOTE: EnvironmentConfigs are an alpha feature and need to be enabled with
- # the '--enable-environment-configs' flag on startup.
- environment:
- # EnvironmentConfigs is a list of object references that is made up of
- # name references and label selectors
- environmentConfigs:
- - type: Reference # this is the default
- ref:
- name: example-environment
- - type: Selector
- selector:
- matchLabels:
- - key: stage
- type: FromCompositeFieldPath # this is the default
- valueFromFieldPath: spec.parameters.stage
- - key: provider
- type: Value
- value: "gcp"
- # The resourceRefs array contains references to all of the resources of which
- # this XR is composed. Despite being in spec this field isn't intended to be
- # configured by humans - Crossplane will take care of keeping it updated.
- resourceRefs:
- - apiVersion: database.gcp.crossplane.io/v1beta1
- kind: CloudSQLInstance
- name: my-db-mfd1b-md9ab
- # The writeConnectionSecretToRef field specifies a Kubernetes Secret that this
- # XR should write its connection details (if any) to.
- writeConnectionSecretToRef:
- namespace: crossplane-system
- name: my-db-connection-details
-status:
- # An XR's 'Ready' condition will become True when all of the resources it
- # composes are deemed ready. Refer to the Composition 'readinessChecks' field
- # for more information.
- conditions:
- - type: Ready
- statue: "True"
- reason: Available
- lastTransitionTime: 2021-10-02T07:20:50.52Z
- # The last time the XR published its connection details to a Secret.
- connectionDetails:
- lastPublishedTime: 2021-10-02T07:20:51.24Z
-```
-
-Similarly, here's an example of the claim that corresponds to the above XR:
-
-```yaml
-apiVersion: database.example.org/v1alpha1
-kind: PostgreSQLInstance
-metadata:
- # Claims are namespaced, unlike XRs.
- namespace: default
- name: my-db
- annotations:
- # The external name annotation has special meaning in Crossplane. When a
- # claim creates an XR its external name will automatically be propagated to
- # the XR. Whether and how the external name is propagated to the resources
- # the XR composes is up to its Composition.
- crossplane.io/external-name: production-db-0
-spec:
- # The resourceRef field references the XR this claim corresponds to. You can
- # either set it to an existing (compatible) XR that you'd like to claim or
- # (the more common approach) leave it blank and let Crossplane automatically
- # create and reference an XR for you.
- resourceRef:
- apiVersion: database.example.org/v1alpha1
- kind: XPostgreSQLInstance
- name: my-db-mfd1b
- # A claim's compositionRef and compositionSelector work the same way as an XR.
- compositionRef:
- name: production-us-east
- compositionSelector:
- matchLabels:
- environment: production
- region: us-east
- provider: gcp
- # A claim's writeConnectionSecretToRef mostly works the same way as an XR's.
- # The one difference is that the Secret is always written to the namespace of
- # the claim.
- writeConnectionSecretToRef:
- name: my-db-connection-details
-status:
- # A claim's 'Ready' condition will become True when its XR's 'Ready' condition
- # becomes True.
- conditions:
- - type: Ready
- statue: "True"
- reason: Available
- lastTransitionTime: 2021-10-02T07:20:50.52Z
- # The last time the claim published its connection details to a Secret.
- connectionDetails:
- lastPublishedTime: 2021-10-02T07:20:51.24Z
-```
-
-> If your XR or claim isn't working as you'd expect you can try running `kubectl
-> describe` against it for details - pay particular attention to any events and
-> status conditions. You may need to follow the references from claim to XR to
-> composed resources to find out what's happening.
-
-## CompositeResourceDefinitions
-
-Below is an example `CompositeResourceDefinition` that includes all configurable
-fields.
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-metadata:
- # XRDs must be named '.', per the plural and group names below.
- name: xpostgresqlinstances.example.org
-spec:
- # This XRD defines an XR in the 'example.org' API group.
- group: example.org
- # The kind of this XR will be 'XPostgreSQLInstance`. You may also optionally
- # specify a singular name and a listKind.
- names:
- kind: XPostgreSQLInstance
- plural: xpostgresqlinstances
- # This type of XR offers a claim. Omit claimNames if you don't want to do so.
- # The claimNames must be different from the names above - a common convention
- # is that names are prefixed with 'X' while claim names are not. This lets app
- # team members think of creating a claim as (e.g.) 'creating a
- # PostgreSQLInstance'.
- claimNames:
- kind: PostgreSQLInstance
- plural: postgresqlinstances
- # Each type of XR can declare any keys they write to their connection secret
- # which will act as a filter during aggregation of the connection secret from
- # composed resources. It's recommended to provide the set of keys here so that
- # consumers of claims and XRs can see what to expect in the connection secret.
- # If no key is given, then all keys in the aggregated connection secret will
- # be written to the connection secret of the XR.
- connectionSecretKeys:
- - hostname
- # Each type of XR may specify a default Composition to be used when none is
- # specified (e.g. when the XR has no compositionRef or selector). A similar
- # enforceCompositionRef field also exists to allow XRs to enforce a specific
- # Composition that should always be used.
- defaultCompositionRef:
- name: example
- # Each type of XR may be served at different versions - e.g. v1alpha1, v1beta1
- # and v1 - simultaneously. Currently Crossplane requires that all versions
- # have an identical schema, so this is mostly useful to 'promote' a type of XR
- # from alpha to beta to production ready.
- versions:
- - name: v1alpha1
- # Served specifies that XRs should be served at this version. It can be set
- # to false to temporarily disable a version, for example to test whether
- # doing so breaks anything before a version is removed wholesale.
- served: true
- # Referenceable denotes the version of a type of XR that Compositions may
- # use. Only one version may be referenceable.
- referenceable: true
- # Schema is an OpenAPI schema just like the one used by Kubernetes CRDs. It
- # determines what fields your XR and claim will have. Note that Crossplane
- # will automatically extend with some additional Crossplane machinery.
- schema:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- parameters:
- type: object
- properties:
- storageGB:
- type: integer
- required:
- - storageGB
- required:
- - parameters
- status:
- type: object
- properties:
- address:
- description: Address of this MySQL server.
- type: string
-```
-
-Take a look at the Kubernetes [CRD documentation][crd-docs] for a more detailed
-guide to writing OpenAPI schemas. Note that the following fields are reserved
-for Crossplane machinery, and will be ignored if your schema includes them:
-
-* `spec.resourceRef`
-* `spec.resourceRefs`
-* `spec.claimRef`
-* `spec.writeConnectionSecretToRef`
-* `status.conditions`
-* `status.connectionDetails`
-
-> If your `CompositeResourceDefinition` isn't working as you'd expect you can
-> try running `kubectl describe xrd` for details - pay particular attention to
-> any events and status conditions.
-
-## Compositions
-
-You'll encounter a lot of 'field paths' when reading or writing a `Composition`.
-Field paths reference a field within a Kubernetes object via a simple string
-'path'. [API conventions][field-paths] 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`.
-
- Valid field paths include:
-
-* `metadata.name` - The `name` field of the `metadata` object.
-* `spec.containers[0].name` - The `name` field of the 0th `containers` element.
-* `data[.config.yml]` - The `.config.yml` field of the `data` object.
-* `apiVersion` - The `apiVersion` field of the root object.
-
- While the following are invalid:
-
-* `.metadata.name` - Leading period.
-* `metadata..name` - Double period.
-* `metadata.name.` - Trailing period.
-* `spec.containers[]` - Empty brackets.
-* `spec.containers.[0].name` - Period before open bracket.
-
-Below is a detailed example of a `Composition`. While detailed, this example
-doesn't include every patch, transform, connection detail, and readiness check
-type. Keep reading below to discover those.
-
-```yaml
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-metadata:
- name: example
- labels:
- # An optional convention is to include a label of the XRD. This allows
- # easy discovery of compatible Compositions.
- crossplane.io/xrd: xpostgresqlinstances.database.example.org
- # The following label marks this Composition for GCP. This label can
- # be used in 'compositionSelector' in an XR or Claim.
- provider: gcp
-spec:
-
- # Each Composition must declare that it is compatible with a particular type
- # of Composite Resource using its 'compositeTypeRef' field. The referenced
- # version must be marked 'referenceable' in the XRD that defines the XR.
- compositeTypeRef:
- apiVersion: database.example.org/v1alpha1
- kind: XPostgreSQLInstance
-
- # When an XR is created in response to a claim Crossplane needs to know where
- # it should create the XR's connection secret. This is configured using the
- # 'writeConnectionSecretsToNamespace' field.
- writeConnectionSecretsToNamespace: crossplane-system
-
- # Each Composition must specify at least one composed resource template. In
- # this case the Composition tells Crossplane that it should create, update, or
- # delete a CloudSQLInstance whenever someone creates, updates, or deletes an
- # XPostgresSQLInstance.
- resources:
-
- # It's good practice to provide a unique name for each entry. Note that
- # this identifies the resources entry within the Composition - it's not
- # the name the CloudSQLInstance. The 'name' field will be required in a
- # future version of this API.
- - name: cloudsqlinstance
-
- # The 'base' template for the CloudSQLInstance Crossplane will create.
- # You can use the base template to specify fields that never change, or
- # default values for fields that may optionally be patched over. Bases must
- # be a valid Crossplane resource - a Managed Resource, Composite Resource,
- # or a ProviderConfig.
- base:
- apiVersion: database.gcp.crossplane.io/v1beta1
- kind: CloudSQLInstance
- spec:
- forProvider:
- databaseVersion: POSTGRES_12
- region: us-central1
- settings:
- dataDiskType: PD_SSD
- ipConfiguration:
- ipv4Enabled: true
- authorizedNetworks:
- - value: "0.0.0.0/0"
-
- # Each resource can optionally specify a set of 'patches' that copy fields
- # from (or to) the XR.
- patches:
- # FromCompositeFieldPath is the default when 'type' is omitted, but it's
- # good practice to always include the type for readability.
- - type: FromCompositeFieldPath
- fromFieldPath: spec.parameters.size
- toFieldPath: spec.forProvider.settings.tier
-
- # Each patch can optionally specify one or more 'transforms', which
- # transform the 'from' field's value before applying it to the 'to' field.
- # Transforms are applied in the order they are specified; each transform's
- # output is passed to the following transform's input.
- transforms:
- - type: map
- map:
- medium: db-custom-1-3840
-
- policy:
- # By default a patch from a field path that does not exist is simply
- # skipped until it does. Use the 'Required' policy to instead block and
- # return an error when the field path does not exist.
- fromFieldPath: Required
-
- # You can patch entire objects or arrays from one resource to another.
- # By default the 'to' object or array will be overwritten, not merged.
- # Use the 'mergeOptions' field to override this behaviour. Note that
- # these fields accidentally leak Go terminology - 'slice' means 'array'.
- # 'map' means 'map' in YAML or 'object' in JSON.
- mergeOptions:
- appendSlice: true
- keepMapValues: true
-
- # You can include connection details to propagate from this CloudSQLInstance
- # up to the XPostgreSQLInstance XR (and then on to the PostgreSQLInstance
- # claim). Remember that your XRD must declare which connection secret keys
- # it supports.
- connectionDetails:
- - name: hostname
- fromConnectionSecretKey: hostname
-
- # By default an XR's 'Ready' status condition will become True when the
- # 'Ready' status conditions of all of its composed resources become true.
- # You can optionally specify custom readiness checks to override this.
- readinessChecks:
- - type: None
-
-
- # If you find yourself repeating patches a lot you can group them as a named
- # 'patch set' then use a PatchSet type patch to reference them.
- patchSets:
- - name: metadata
- patches:
- - type: FromCompositeFieldPath
- # When both field paths are the same you can omit the 'toFieldPath' and it
- # will default to the 'fromFieldPath'.
- fromFieldPath: metadata.labels[some-important-label]
-```
-
-### Pause Annotation
-There is an annotation named `crossplane.io/paused` that you can use on
-Composite Resources and Composite Resource Claims to temporarily pause
-reconciliations of their respective controllers on them. An example
-for a Composite Resource Claim is as follows:
-```yaml
-apiVersion: test.com/v1alpha1
-kind: MyResource
-metadata:
- annotations:
- crossplane.io/paused: "true"
- namespace: upbound-system
- name: my-resource
-spec:
- parameters:
- tagValue: demo-test
- compositionRef:
- name: example
-```
-where `MyResource` is a Composite Resource Claim kind.
-When a Composite Resource or a Claim has the `crossplane.io/paused` annotation
-with its value set to `true`, the Composite Resource controller or the Claim
-controller pauses reconciliations on the resource until
-the annotation is removed or its value set to something other than `true`.
-Before temporarily pausing reconciliations, an event with the type `Synced`,
-the status `False`, and the reason `ReconcilePaused` is emitted
-on the resource.
-Please also note that annotations on a Composite Resource Claim are propagated
-to the associated Composite Resource but when the
-`crossplane.io/paused: "true"` annotation is added to a Claim, because
-reconciliations on the Claim are now paused, this newly added annotation
-will not be propagated. However, whenever the annotation's value is set to a
-non-`true` value, reconciliations on the Claim will now resume, and thus the
-annotation will now be propagated to the associated Composite Resource
-with a non-`true` value. An implication of the described behavior is that
-pausing reconciliations on the Claim will not inherently pause reconciliations
-on the associated Composite Resource.
-
-
-### Patch Types
-
-You can use the following types of patch in a `Composition`:
-
-`FromCompositeFieldPath`. The default if the `type` is omitted. This type
-patches from a field within the XR to a field within the composed resource. It's
-commonly used to expose a composed resource spec field as an XR spec field.
-
-```yaml
-# Patch from the XR's spec.parameters.size field to the composed resource's
-# spec.forProvider.settings.tier field.
-- type: FromCompositeFieldPath
- fromFieldPath: spec.parameters.size
- toFieldPath: spec.forProvider.settings.tier
-```
-
-`ToCompositeFieldPath`. The inverse of `FromCompositeFieldPath`. This type
-patches from a field within the composed resource to a field within the XR. It's
-commonly used to derive an XR status field from a composed resource status
-field.
-
-```yaml
-# Patch from the composed resource's status.atProvider.zone field to the XR's
-# status.zone field.
-- type: ToCompositeFieldPath
- fromFieldPath: status.atProvider.zone
- toFieldPath: status.zone
-```
-
-`FromCompositeFieldPath` and `ToCompositeFieldPath` patches can also take a wildcarded
-field path in the `toFieldPath` parameter and patch each array element in the `toFieldPath`
-with the singular value provided in the `fromFieldPath`.
-
-```yaml
-# Patch from the XR's spec.parameters.allowedIPs to the CIDRBlock elements
-# inside the array spec.forProvider.firewallRules on the composed resource.
-resources:
-- name: exampleFirewall
- base:
- apiVersion: firewall.example.crossplane.io/v1beta1
- kind: Firewall
- spec:
- forProvider:
- firewallRules:
- - Action: "Allow"
- Destination: "example1"
- CIDRBlock: ""
- - Action: "Allow"
- Destination: "example2"
- CIDRBlock: ""
-- type: FromCompositeFieldPath
- fromFieldPath: spec.parameters.allowedIP
- toFieldPath: spec.forProvider.firewallRules[*].CIDRBlock
-```
-
-`FromEnvironmentFieldPath`. This type patches from a field within the in-memory
-environment to a field within the composed resource. It's commonly used to
-expose a composed resource spec field as an XR spec field.
-Note that EnvironmentConfigs are an alpha feature and need to be enabled with
-the `--enable-environment-configs` flag on startup.
-
-```yaml
-# Patch from the environment's tier.name field to the composed resource's
-# spec.forProvider.settings.tier field.
-- type: FromEnvironmentFieldPath
- fromFieldPath: tier.name
- toFieldPath: spec.forProvider.settings.tier
-```
-
-`ToEnvironmentFieldPath`. This type patches from a composed field to the
-in-memory environment. Note that, unlike `ToCompositeFieldPath` patches, this
-is executed before the composed resource is applied on the cluster which means
-that the `status` is not available.
-Note that EnvironmentConfigs are an alpha feature and need to be enabled with
-the `--enable-environment-configs` flag on startup.
-
-```yaml
-# Patch from the environment's tier.name field to the composed resource's
-# spec.forProvider.settings.tier field.
-- type: ToEnvironmentFieldPath
- fromFieldPath: spec.forProvider.settings.tier
- toFieldPath: tier.name
-```
-
-Note that the field to be patched requires some initial value to be set.
-
-`CombineFromComposite`. Combines multiple fields from the XR to produce one
-composed resource field.
-
-```yaml
-# Patch from the XR's spec.parameters.location field and the
-# metadata.labels[crossplane.io/claim-name] label to the composed
-# resource's spec.forProvider.administratorLogin field.
-- type: CombineFromComposite
- combine:
- # The patch will only be applied when all variables have non-zero values.
- variables:
- - fromFieldPath: spec.parameters.location
- - fromFieldPath: metadata.labels[crossplane.io/claim-name]
- strategy: string
- string:
- fmt: "%s-%s"
- toFieldPath: spec.forProvider.administratorLogin
- # By default Crossplane will skip the patch until all of the variables to be
- # combined have values. Set the fromFieldPath policy to 'Required' to instead
- # abort composition and return an error if a variable has no value.
- policy:
- fromFieldPath: Required
-```
-
-`CombineFromEnvironment`. Combines multiple fields from the in-memory
-environment to produce one composed resource field.
-Note that EnvironmentConfigs are an alpha feature and need to be enabled with
-the `--enable-environment-configs` flag on startup.
-
-```yaml
-# Patch from the environments's location field and region to the composed
-# resource's spec.forProvider.administratorLogin field.
-- type: CombineFromEnvironment
- combine:
- # The patch will only be applied when all variables have non-zero values.
- variables:
- - fromFieldPath: location
- - fromFieldPath: region
- strategy: string
- string:
- fmt: "%s-%s"
- toFieldPath: spec.forProvider.administratorLogin
-```
-
-At the time of writing only the `string` combine strategy is supported. It uses
-[Go string formatting][pkg/fmt] to combine values, so if the XR's location was
-`us-west` and its claim name was `db` the composed resource's administratorLogin
-would be set to `us-west-db`.
-
-`CombineToComposite` is the inverse of `CombineFromComposite`.
-
-```yaml
-# Patch from the composed resource's spec.parameters.administratorLogin and
-# status.atProvider.fullyQualifiedDomainName fields back to the XR's
-# status.adminDSN field.
-- type: CombineToComposite
- combine:
- variables:
- - fromFieldPath: spec.parameters.administratorLogin
- - fromFieldPath: status.atProvider.fullyQualifiedDomainName
- strategy: string
- # Here, our administratorLogin parameter and fullyQualifiedDomainName
- # status are formatted to a single output string representing a DSN.
- string:
- fmt: "mysql://%s@%s:3306/my-database-name"
- toFieldPath: status.adminDSN
-```
-
-`CombineToEnvironment` is the inverse of `CombineFromEnvironment`.
-Note that EnvironmentConfigs are an alpha feature and need to be enabled with
-the `--enable-environment-configs` flag on startup.
-
-```yaml
-# Patch from the composed resource's spec.parameters.administratorLogin and
-# spec.forProvider.domainName fields back to the environment's adminDSN field.
-- type: CombineToEnvironment
- combine:
- variables:
- - fromFieldPath: spec.parameters.administratorLogin
- - fromFieldPath: spec.forProvider.domainName
- strategy: string
- # Here, our administratorLogin parameter and fullyQualifiedDomainName
- # status are formatted to a single output string representing a DSN.
- string:
- fmt: "mysql://%s@%s:3306/my-database-name"
- toFieldPath: adminDSN
-```
-
-`PatchSet`. References a named set of patches defined in the `spec.patchSets`
-array of a `Composition`.
-
-```yaml
-# This is equivalent to specifying all of the patches included in the 'metadata'
-# PatchSet.
-- type: PatchSet
- patchSetName: metadata
-```
-
-The `patchSets` array may not contain patches of `type: PatchSet`. The
-`transforms` and `patchPolicy` fields are ignored by `type: PatchSet`.
-
-### Transform Types
-
-You can use the following types of transform on a value being patched:
-
-`map`. Transforms values using a map.
-
-```yaml
-# If the value of the 'from' field is 'us-west', the value of the 'to' field
-# will be set to 'West US'.
-- type: map
- map:
- us-west: West US
- us-east: East US
- au-east: Australia East
-```
-
-`match`. A more complex version of `map` that can match different kinds of
-patterns. It should be used if more advanced pattern matchings than a simple
-string equality check are required.
-The result of the first matching pattern is used as the output of this
-transform.
-
-```yaml
-- type: match
- match:
- patterns:
- - type: literal # Not needed. This is the default.
- literal: us-west
- result: West US
- - type: regexp
- regexp: '^af-.*'
- result: Somewhere in Africa
- fallbackValue: Unknown
-```
-
-`math`. Transforms values using math. The input value must be an integer.
-Currently only `multiply` is supported.
-
-```yaml
-# If the value of the 'from' field is 2, the value of the 'to' field will be set
-# to 4.
-- type: math
- math:
- multiply: 2
-```
-
-`string`. Transforms string values.
-* string transform type `Format`, Currently only Go style fmt is supported. [Go style `fmt`][pkg/fmt] is supported.
-* string transform type `Convert`, accepts one of `ToUpper`, `ToLower`, `ToBase64`, `FromBase64`, `ToJson`, `ToSha1`, `ToSha256`, `ToSha512`.
-* string transform type `TrimPrefix`, accepts a string to be trimmed from the beginning of the input.
-* string transform type `TrimSuffix`, accepts a string to be trimmed from the end of the input.
-* string transform type `Regexp`, accepts a string for regexp to be applied to.
-
-```yaml
-# If you omit the field type, by default type is set to `Format`
-# If the value of the 'from' field is 'hello', the value of the 'to' field will
-# be set to 'hello-world'.
-- type: string
- string:
- fmt: "%s-world"
-
-# This is the same as above
-# the value of the 'to' field will be set to 'hello-world'.
-- type: string
- string:
- type: Format
- fmt: "%s-world"
-
-# If the value of the 'from' field is 'hello', the value of the 'to' field will
-# be set to 'HELLO'.
-- type: string
- string:
- type: Convert
- convert: ToUpper
-
-# If the value of the 'from' field is 'Hello', the value of the 'to' field will
-# be set to 'hello'.
-- type: string
- string:
- type: Convert
- convert: ToLower
-
-# If the value of the 'from' field is 'Hello', the value of the 'to' field will
-# be set to 'SGVsbG8='.
-- type: string
- string:
- type: Convert
- convert: ToBase64
-
-# If the value of the 'from' field is 'SGVsbG8=', the value of the 'to' field will
-# be set to 'Hello'.
-- type: string
- string:
- type: Convert
- convert: FromBase64
-
-# If the value of the 'from' field is not nil, the value of the 'to' field will be
-# set to raw JSON representation of the 'from' field.
-- type: string
- string:
- type: Convert
- convert: ToJson
-
-# The output will be the hash of the JSON representation of the 'from' field.
-- type: string
- string:
- type: Convert
- convert: ToSha1 # alternatives: 'ToSha256' or 'ToSha512'
-
-# If the value of the 'from' field is https://crossplane.io, the value of the 'to' field will
-# be set to crossplane.io
-- type: string
- string:
- type: TrimPrefix
- trim: 'https://'
-
-# If the value of the 'from' field is my-string-test, the value of the 'to' field will
-# be set to my-string
-- type: string
- string:
- type: TrimSuffix
- trim: '-test'
-
-# If the value of the 'from' field is 'arn:aws:iam::42:example, the value of the
-# 'to' field will be set to "42". Note that the 'to' field is always a string.
-- type: string
- string:
- type: Regexp
- regexp:
- match: 'arn:aws:iam::(\d+):.*'
- group: 1 # Optional capture group. Omit to match the entire regexp.
-```
-
-`convert`. Transforms values of one type to another, for example from a string
-to an integer. The following values are supported by the `from` and `to` fields:
-
-* `string`
-* `bool`
-* `int`
-* `int64`
-* `float64`
-
-The strings 1, t, T, TRUE, true, and True are considered 'true', while 0, f, F,
-FALSE, false, and False are considered 'false'. The integer 1 and float 1.0 are
-considered true, while all other values are considered false. Similarly, boolean
-true converts to integer 1 and float 1.0, while false converts to 0 and 0.0.
-
-```yaml
-# If the value to be converted is "1" (a string), the value of the 'toType'
-# field will be set to 1 (an integer).
-- type: convert
- convert:
- toType: int
-```
-
-Converting `string` to `float64` additionally supports parsing string in
-[K8s quantity format](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity),
-such as `1000m` or `500 Mi`:
-
-```yaml
-- type: convert
- convert:
- toType: float64
- format: quantity
-```
-
-### Connection Details
-
-Connection details secret of XR is an aggregated sum of the connection details
-of the composed resources. It's recommended that the author of XRD specify
-exactly which keys will be allowed in the XR connection secret by listing them
-in `spec.connectionSecretKeys` so that consumers of claims and XRs can see what
-they can expect in the connection details secret.
-
-If `spec.connectionSecretKeys` is empty, then all keys of the aggregated connection
-details secret will be propagated.
-
-You can derive the following types of connection details from a composed
-resource to be aggregated:
-
-`FromConnectionSecretKey`. Derives an XR connection detail from a connection
-secret key of a composed resource.
-
-```yaml
-# Derive the XR's 'user' connection detail from the 'username' key of the
-# composed resource's connection secret.
-- type: FromConnectionSecretKey
- name: user
- fromConnectionSecretKey: username
-```
-
-`FromFieldPath`. Derives an XR connection detail from a field path within the
-composed resource.
-
-```yaml
-# Derive the XR's 'user' connection detail from the 'adminUser' status field of
-# the composed resource.
-- type: FromFieldPath
- name: user
- fromFieldPath: status.atProvider.adminUser
-```
-
-`FromValue`. Derives an XR connection detail from a fixed value.
-
-```yaml
-# Always sets the XR's 'user' connection detail to 'admin'.
-- type: FromValue
- name: user
- value: admin
-```
-
-### Readiness Checks
-
-Crossplane can use the following types of readiness check to determine whether a
-composed resource is ready (and therefore whether the XR and claim should be
-considered ready). Specify multiple readiness checks if multiple conditions must
-be met for a composed resource to be considered ready.
-
-> Note that if you don't specify any readiness checks Crossplane will consider
-> the composed resource to be ready when its 'Ready' status condition becomes
-> 'True'.
-
-`MatchString`. Considers the composed resource to be ready when the value of a
-field within that resource matches a specified string.
-
-```yaml
-# The composed resource will be considered ready when the 'state' status field
-# matches the string 'Online'.
-- type: MatchString
- fieldPath: status.atProvider.state
- matchString: "Online"
-```
-
-`MatchInteger`. Considers the composed resource to be ready when the value of a
-field within that resource matches a specified integer.
-
-```yaml
-# The composed resource will be considered ready when the 'state' status field
-# matches the integer 4.
-- type: MatchInteger
- fieldPath: status.atProvider.state
- matchInteger: 4
-```
-
-`NonEmpty`. Considers the composed resource to be ready when a field exists in
-the composed resource. The name of this check can be a little confusing in that
-a field that exists with a zero value (e.g. an empty string or zero integer) is
-not considered to be 'empty', and thus will pass the readiness check.
-
-```yaml
-# The composed resource will be considered ready if and when 'online' status
-# field exists.
-- type: NonEmpty
- fieldPath: status.atProvider.online
-```
-
-`None`. Considers the composed resource to be ready as soon as it exists.
-
-### Missing Functionality
-
-You might find while reading through this reference that Crossplane is missing
-some functionality you need to compose resources. If that's the case, please
-[raise an issue] with as much detail **about your use case** as possible. Please
-understand that the Crossplane maintainers are growing the feature set of the
-`Composition` type conservatively. We highly value the input of our users and
-community, but we also feel it's critical to avoid bloat and complexity. We
-therefore wish to carefully consider each new addition. We feel some features
-may be better suited for a real, expressive programming language and intend to
-build an alternative to the `Composition` type as it is documented here per
-[this proposal][issue-2524].
-
-## Tips, Tricks, and Troubleshooting
-
-In this section we'll cover some common tips, tricks, and troubleshooting steps
-for working with Composite Resources. If you're trying to track down why your
-Composite Resources aren't working the [Troubleshooting][trouble-ref] page also
-has some useful information.
-
-### Troubleshooting Claims and XRs
-
-Crossplane relies heavily on status conditions and events for troubleshooting.
-You can see both using `kubectl describe` - for example:
-
-```console
-# Describe the PostgreSQLInstance claim named my-db
-kubectl describe postgresqlinstance.database.example.org my-db
-```
-
-Per Kubernetes convention, Crossplane keeps errors close to the place they
-happen. This means that if your claim is not becoming ready due to an issue with
-your `Composition` or with a composed resource you'll need to "follow the
-references" to find out why. Your claim will only tell you that the XR is not
-yet ready.
-
-To follow the references:
-
-1. Find your XR by running `kubectl describe` on your claim and looking for its
- "Resource Ref" (aka `spec.resourceRef`).
-1. Run `kubectl describe` on your XR. This is where you'll find out about issues
- with the `Composition` you're using, if any.
-1. If there are no issues but your XR doesn't seem to be becoming ready, take a
- look for the "Resource Refs" (or `spec.resourceRefs`) to find your composed
- resources.
-1. Run `kubectl describe` on each referenced composed resource to determine
- whether it is ready and what issues, if any, it is encountering.
-
-### Composite Resource Connection Secrets
-
-Claim and Composite Resource connection secrets are often derived from the
-connection secrets of the managed resources they compose. This is a common
-source of confusion because several things need to align for it to work:
-
-1. The **claim** must specify the secret where the aggregated connection details
- should be written
- * This is the `spec.writeConnectionSecretToRef` field in a claim
- * If creating a composite resource directly (without a claim) then this same
- field must be set on your composite resource instead
-1. The **composite resource definition** must state which connection details to
- aggregate from its children to publish to the claim
- * This is the `spec.connectionSecretKeys` field in a
- `CompositeResourceDefinition`
-1. The **composition** must define where to write its aggregated connection
- details
- * This is the `spec.writeConnectionSecretsToNamespace` field in the
- `Composition`
-1. Each child **composed resource** must define the connection details it
- publishes and where to write them
- * These are the `connectionDetails` and
- `base.spec.writeConnectionSecretToRef` fields of the composed resources
-
-Finally, you can't currently edit a XRD's supported connection details. The
-XRD's `spec.connectionSecretKeys` is effectively immutable. This may change in
-future per [this issue][issue-2024]
-
-### Claiming an Existing Composite Resource
-
-Most people create Composite Resources using a claim, but you can actually claim
-an existing Composite Resource as long as its a type of XR that offers a claim
-and no one else has already claimed it. To do so:
-
-1. Set the `spec.resourceRef` of your claim to reference the existing XR.
-1. Make sure the rest of your claim's spec fields match the XR's.
-
-If your claim's spec fields don't match the XR's Crossplane will still claim it
-but will then try to update the XR's spec fields to match the claim's.
-
-### Influencing External Names
-
-The `crossplane.io/external-name` annotation has special meaning to Crossplane
-managed resources - it specifies the name (or identifier) of the resource in the
-external system, for example the actual name of a `CloudSQLInstance` in the GCP
-API. Some managed resources don't let you specify an external name - in those
-cases Crossplane will set it for you to whatever the external system requires.
-
-If you add the `crossplane.io/external-name` annotation to a claim Crossplane
-will automatically propagate it when it creates an XR. It's good practice to
-have your `Composition` further propagate the annotation to one or more composed
-resources, but it's not required.
-
-### Mixing and Matching Providers
-
-Crossplane has providers for many things in addition to the big clouds. Take a
-look at the [Upbound Marketplace][upbound-marketplace] to find many of them.
-Keep in mind that you can mix and match managed resources from different
-providers within a `Composition` to create Composite Resources. For example you
-might use provider-aws and provider-sql to create an XR that provisions an
-`RDSInstance` then creates an SQL `Database` and `User`, or provider-gcp and
-provider-helm to create a `GKECluster` and deploy a Helm Chart `Release` to it.
-
-Often when mixing and matching providers you'll need to compose a
-`ProviderConfig` for one provider that loads credentials from the connection
-secret of a managed resource from another provider. Sometimes you may need to
-use an intermediary XR to mutate the connection details to suit your needs.
-[This example][helm-and-gcp] from provider-helm demonstrates using a GKE cluster
-connection secret as Helm `ProviderConfig` credentials.
-
-### Patching From One Composed Resource to Another or Itself
-
-It's not possible to patch _directly_ from one composed resource to another -
-i.e. from one entry in the `spec.resources` array of a `Composition` to another.
-It is however possible to achieve this by using the XR as an intermediary. To do
-so:
-
-1. Use a `ToCompositeFieldPath` patch to patch from your source composed
- resource to the XR. Typically you'll want to patch to a status field or an
- annotation.
-1. Use a `FromCompositeFieldPath` patch to patch from the 'intermediary' field
- you patched to in step 1 to a field on the destination composed resource.
-
-Note that the source and the target composed resource can be the same.
-
-[managed-resources]: {{][}}
-[crd-docs]: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
-[raise an issue]: https://github.com/crossplane/crossplane/issues/new?assignees=&labels=enhancement&template=feature_request.md
-[issue-2524]: https://github.com/crossplane/crossplane/issues/2524
-[field-paths]: https://github.com/kubernetes/community/blob/61f3d0/contributors/devel/sig-architecture/api-conventions.md#selecting-fields
-[pkg/fmt]: https://pkg.go.dev/fmt
-[upbound-marketplace]: https://marketplace.upbound.io
-[helm-and-gcp]: https://github.com/crossplane-contrib/provider-helm/blob/2dcbdd0/examples/in-composition/composition.yaml
-[issue-2024]: https://github.com/crossplane/crossplane/issues/2024
-[xrs-and-mrs]: /media/composition-xrs-and-mrs.svg
-[how-it-works]: /media/composition-how-it-works.svg
-[provider-kubernetes]: https://marketplace.upbound.io/providers/crossplane-contrib/provider-kubernetes
-[provider-helm]: https://marketplace.upbound.io/providers/crossplane-contrib/provider-helm/
-[claims-and-xrs]: /media/composition-claims-and-xrs.svg
-[xr-ref]: {{][}}
diff --git a/content/v1.11/concepts/packages.md b/content/v1.11/concepts/packages.md
deleted file mode 100644
index ccdb1a7cd..000000000
--- a/content/v1.11/concepts/packages.md
+++ /dev/null
@@ -1,509 +0,0 @@
----
-title: Crossplane Packages
-weight: 104
----
-
-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**: Crossplane resolves dependencies between packages,
- automatically installing a package's dependencies if they are not present in
- the cluster, and checking if dependency versions are valid if they are already
- installed.
-
-## Table of Contents
-
-The following packaging operations are covered in detail below:
-
-- [Table of Contents](#table-of-contents)
-- [Building a Package](#building-a-package)
- - [Provider Packages](#provider-packages)
- - [Configuration Packages](#configuration-packages)
-- [Pushing a Package](#pushing-a-package)
-- [Installing a Package](#installing-a-package)
- - [spec.package](#specpackage)
- - [spec.packagePullPolicy](#specpackagepullpolicy)
- - [spec.revisionActivationPolicy](#specrevisionactivationpolicy)
- - [spec.revisionHistoryLimit](#specrevisionhistorylimit)
- - [spec.packagePullSecrets](#specpackagepullsecrets)
- - [spec.skipDependencyResolution](#specskipdependencyresolution)
- - [spec.ignoreCrossplaneConstraints](#specignorecrossplaneconstraints)
- - [spec.controllerConfigRef](#speccontrollerconfigref)
-- [Upgrading a Package](#upgrading-a-package)
- - [Package Upgrade Issues](#package-upgrade-issues)
-- [The Package Cache](#the-package-cache)
- - [Pre-Populating the Package Cache](#pre-populating-the-package-cache)
-
-## 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/v1
-kind: Provider
-metadata:
- name: provider-gcp
-spec:
- crossplane:
- version: ">=v1.0.0"
- controller:
- image: crossplane/provider-gcp-controller:v0.14.0
- permissionRequests:
- - apiGroups:
- - apiextensions.crossplane.io
- resources:
- - compositions
- verbs:
- - get
- - list
- - create
- - update
- - patch
- - watch
-```
-
-See all available fields in the [official documentation][provider-docs].
-
-> Note: The `meta.pkg.crossplane.io` group does not contain custom resources
-> that may be installed into the cluster. They are strictly used as metadata in
-> a Crossplane package.
-
-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`.
-
-The `spec.controller.image` fields specifies that the `Provider` desires for the
-controller `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.
-
-The `spec.controller.permissionRequests` field allows a package author to
-request additional RBAC for the packaged controller. The controller's
-`ServiceAccount` will automatically give the controller permission to reconcile
-all types that its package installs, as well as `Secrets`, `ConfigMaps`, and
-`Events`. Any additional permissions must be explicitly requested.
-
-> Note that the Crossplane RBAC manager can be configured to reject permissions
-> for certain API groups. If a package requests permissions that Crossplane is
-> configured to reject, the package will fail to be installed.
-> Authorized permissions should be aggregated to the rbac manager clusterrole
-> (the cluster role defined by the provider-clusterrole flag in the rbac manager)
-> by using the label `rbac.crossplane.io/aggregate-to-allowed-provider-permissions: "true"`
-
-The `spec.crossplane.version` field specifies the version constraints for core
-Crossplane that the `Provider` is compatible with. It is advisable to use this
-field if a package relies on specific features in a minimum version of
-Crossplane.
-
-> All version constraints used in packages follow the [specification] outlined
-> in the `Masterminds/semver` repository.
-
-For an example Provider package, see [provider-gcp].
-
-To build a Provider package, navigate to the package root directory and execute
-the following command:
-
-```
-crossplane build provider
-```
-
-If the Provider package is valid, you will see a file with the `.xpkg`
-extension.
-
-> Note that the Crossplane CLI will not follow symbolic links for files in the
-> root package directory.
-
-### Configuration Packages
-
-A Configuration package contains a `crossplane.yaml` with the following format:
-
-```yaml
-apiVersion: meta.pkg.crossplane.io/v1
-kind: Configuration
-metadata:
- name: my-org-infra
-spec:
- crossplane:
- version: ">=v1.0.0"
- dependsOn:
- - provider: xpkg.upbound.io/crossplane-contrib/provider-gcp
- version: ">=v0.14.0"
-```
-
-See all available fields in the [official documentation][configuration-docs].
-
-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.
-
-The `spec.crossplane.version` field serves the same purpose that it does in a
-`Provider` package.
-
-The `spec.dependsOn` field specifies packages that this package depends on. When
-installed, the package manager will ensure that all dependencies are present and
-have a valid version given the constraint. If a dependency is not installed, the
-package manager will install it at the latest version that fits within the
-provided constraints.
-
-> Dependency resolution is a `beta` feature and depends on the `v1beta1`
-> [`Lock` API][lock-api].
-
-For an example Configuration package, see [getting-started-with-gcp](https://github.com/crossplane/docs/tree/master/content/media/snippets/package/gcp).
-
-To build a Configuration package, navigate to the package root directory and
-execute the following command:
-
-```
-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:
-
-```
-crossplane push provider xpkg.upbound.io/crossplane-contrib/provider-gcp:v0.22.0
-```
-
-To push a Configuration package, execute the following command:
-
-```
-crossplane push configuration xpkg.upbound.io/crossplane-contrib/my-org-infra:v0.1.0
-```
-
-> 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:
-
-```
-crossplane install provider xpkg.upbound.io/crossplane-contrib/provider-gcp:v0.22.0
-```
-
-To install a Configuration package, execute the following command:
-
-```
-crossplane install configuration xpkg.upbound.io/crossplane-contrib/my-org-infra:v0.1.0
-```
-
-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/v1
-kind: Provider
-metadata:
- name: provider-gcp
-spec:
- package: xpkg.upbound.io/crossplane-contrib/provider-gcp:v0.22.0
- packagePullPolicy: IfNotPresent
- revisionActivationPolicy: Automatic
- revisionHistoryLimit: 1
-```
-
-```yaml
-apiVersion: pkg.crossplane.io/v1
-kind: Configuration
-metadata:
- name: my-org-infra
-spec:
- package: xpkg.upbound.io/crossplane-contrib/my-org-infra:v0.1.0
- packagePullPolicy: IfNotPresent
- 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 default fields specified above can be configured with different values to
-modify the installation and upgrade behavior of a package. In addition, there
-are multiple other fields which can further customize how the package manager
-handles a specific revision.
-
-### 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.packagePullPolicy
-
-Valid values: `IfNotPresent`, `Always`, or `Never` (default: `IfNotPresent`)
-
-When a package is installed, Crossplane downloads the image contents into a
-cache. Depending on the image identifier (tag or digest) and the
-`packagePullPolicy`, the Crossplane package manager will decide if and when to
-check and see if newer package contents are available. The following table
-describes expected behavior based on the supplied fields:
-
-| | `IfNotPresent` | `Always` | `Never` |
-|---------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------|
-| Semver Tag (e.g. `v1.3.0`) | Package is downloaded when initially installed, and as long as it is present in the cache, it will not be downloaded again. If the cache is lost and the a new version of the package image has been pushed for the same tag, package could inadvertently be upgraded. ]
**Upgrade Safety: Strong** | Package is downloaded when initially installed, but Crossplane will check every minute if new content is available. New content would have to be pushed for the same semver tag for upgrade to take place.
**Upgrade Safety: Weak** | Crossplane will never download content. Must manually load package image in cache.
**Upgrade Safety: Strongest** |
-| Digest (e.g. `@sha256:28b6...`) | Package is downloaded when initially installed, and as long as it is present in the cache, it will not be downloaded again. If the cache is lost but an image with this digest is still available, it will be downloaded again. The package will never be upgraded without a user changing the digest.
**Upgrade Safety: Very Strong** | Package is downloaded when initially installed, but Crossplane will check every minute if new content is available. Because image digest is used, new content will never be downloaded.
**Upgrade Safety: Strong** | Crossplane will never download content. Must manually load package image in cache.
**Upgrade Safety: Strongest** |
-| Channel Tag (e.g. `latest`) | Package is downloaded when initially installed, and as long as it is present in the cache, it will not be downloaded again. If the cache is lost, the latest version of this package image will be downloaded again, which will frequently have different contents.
**Upgrade Safety: Weak** | Package is downloaded when initially installed, but Crossplane will check every minute if new content is available. When the image content is new, Crossplane will download the new contents and create a new revision.
**Upgrade Safety: Very Weak** | Crossplane will never download content. Must manually load package image in cache.
**Upgrade Safety: Strongest** |
-
-### spec.revisionActivationPolicy
-
-Valid values: `Automatic` or `Manual` (default: `Automatic`)
-
-When Crossplane downloads new contents for a package, regardless of whether it
-was a manual upgrade (i.e. user updating package image tag), or an automatic one
-(enabled by the `packagePullPolicy`), it will create a new package revision.
-However, the new objects and / or controllers will not be installed until the
-new revision is marked as `Active`. This activation process is configured by the
-`revisionActivationPolicy` field.
-
-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 resources
-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.
-
-With `revisionActivationPolicy: Automatic`, Crossplane will mark any new
-revision as `Active` when it is created, as well as transition any old revisions
-to `Inactive`. When `revisionActivationPolicy: Manual`, the user must manually
-edit a new revision and mark it as `Active`. This can be useful if you are using
-a `packagePullPolicy: Automatic` with a channel tag (e.g. `latest`) and you want
-Crossplane to create new revisions when a new version is available, but you
-don't want to automatically update to that newer revision.
-
-It is recommended for most users to use semver tags or image digests and
-manually update their packages, but use a `revisionActivationPolicy: Automatic`
-to avoid having to manually activate new versions. However, each user should
-consider their specific environment and choose a combination that makes sense
-for them.
-
-For security reasons, it's suggested using image digests instead or alongside
-tags (`vx.y.z@sha256:...`), to ensure that the package content wasn't tampered
-with.
-
-### 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`.
-
-### spec.packagePullSecrets
-
-Valid values: slice of `Secret` names (secrets must exist in `namespace`
-Crossplane was installed in, typically `crossplane-system`)
-
-This field allows a user to provide credentials required to pull a package from
-a private repository on a registry. The credentials are passed along to a
-packaged controller if the package is a `Provider`, but are not passed along to
-any dependencies.
-
-### spec.skipDependencyResolution
-
-Valid values: `true` or `false` (default: `false`)
-
-If `skipDependencyResolution: true`, the package manager will install a package
-without considering its dependencies.
-
-### spec.ignoreCrossplaneConstraints
-
-Valid values: `true` or `false` (default: `false`)
-
-If `ignoreCrossplaneConstraints: true`, the package manager will install a
-package without considering the version of Crossplane that is installed.
-
-### spec.controllerConfigRef
-
-{{< hint "warning" >}}
-The `ControllerConfig` API has been deprecated and will be removed in a future
-release when a comparable alternative is available.
-{{< /hint >}}
-
-Valid values: name of a `ControllerConfig` object
-
-Packaged `Provider` controllers are installed in the form of a `Deployment`.
-Crossplane populates the `Deployment` with default values that may not be
-appropriate for every use-case. In the event that a user wants to override some
-of the defaults that Crossplane has set, they may create and reference a
-`ControllerConfig`.
-
-An example of when this may be useful is when a user is running Crossplane on
-EKS and wants to take advantage of [IAM Roles for Service Accounts]. This
-requires setting an `fsGroup` and annotating the `ServiceAccount` that
-Crossplane creates for the controller. This could be accomplished with the
-following `ControllerConfig` and `Provider`:
-
-```yaml
-apiVersion: pkg.crossplane.io/v1alpha1
-kind: ControllerConfig
-metadata:
- name: aws-config
- annotations:
- eks.amazonaws.com/role-arn: arn:aws:iam::$AWS_ACCOUNT_ID\:role/$IAM_ROLE_NAME
-spec:
- podSecurityContext:
- fsGroup: 2000
----
-apiVersion: pkg.crossplane.io/v1
-kind: Provider
-metadata:
- name: provider-aws
-spec:
- package: xpkg.upbound.io/crossplane-contrib/provider-aws:v0.33.0
- controllerConfigRef:
- name: aws-config
-```
-
-You can find all configurable values in the [official `ControllerConfig`
-documentation][controller-config-docs].
-
-## Upgrading a Package
-
-Upgrading a `Provider` or `Configuration` to a new version can be accomplished
-by editing the existing manifest and applying it with a new version tag in
-`spec.package`. Crossplane will observe the updated manifest and create a new
-`ProviderRevision` or `ConfigurationRevision` for the specified version. The new
-revision will be activated in accordance with `spec.revisionActivationPolicy`.
-
-### Package Upgrade Issues
-
-Upgrading a package can require manual intervention in the event that the
-previous version of the package supported a version of a custom resource that
-has been dropped and replaced by a new version in the new package revision.
-Kubernetes does not allow for applying a `CustomResourceDefinition` (CRD) that
-drops a version in the `spec` that is in the current `status.storedVersions`
-list, meaning that a revision cannot update and become the _controller_ of all
-of its resources.
-
-This situation can be remedied by manually deleting the offending CRD and
-letting the new revision re-create it. In the event that custom resources exist
-for the given CRD, they must be deleted before the CRD can be removed.
-
-## The Package Cache
-
-When a package is installed into a cluster, Crossplane fetches the package image
-and stores its contents in a dedicated package cache. By default, this cache is
-backed by an [`emptyDir` Volume][emptyDir-volume], meaning that all cached data
-is lost when a `Pod` restarts. Users who wish for cache contents to be persisted
-between `Pod` restarts may opt to instead use a [`persistentVolumeClaim`
-(PVC)][pvc] by setting the `packageCache.pvc` Helm chart parameter to the name
-of the PVC.
-
-### Pre-Populating the Package Cache
-
-Because the package cache can be backed by any storage medium, users are able to
-optionally to pre-populate the cache with images that are not present on an
-external [OCI registry]. To utilize a package that has been manually stored in
-the cache, users must specify the name of the package in `spec.package` and use
-`packagePullPolicy: Never`. For instance, if a user built a `Configuration`
-package named `mycoolpkg.xpkg` and loaded it into the volume that was to be used
-for the package cache (i.e. copied the `.xpkg` file into the storage medium
-backing the PVC), the package could be utilized with the following manifest:
-
-```yaml
-apiVersion: pkg.crossplane.io/v1
-kind: Configuration
-metadata:
- name: my-cool-pkg
-spec:
- package: mycoolpkg
- packagePullPolicy: Never
-```
-
-Importantly, as long as a package is being used as the `spec.package` of a
-`Configuration` or `Provider`, it must remain in the cache. For this reason, it
-is recommended that users opt for a durable storage medium when manually loading
-packages into the cache.
-
-In addition, if manually loading a `Provider` package into the cache, users must
-ensure that the controller image that it references is able to be pulled by the
-cluster nodes. This can be accomplished either by pushing it to a registry, or
-by [pre-pulling images] onto nodes in the cluster.
-
-
-
-
-[OCI images]: https://github.com/opencontainers/image-spec
-[Providers]: {{[}}
-[provider-docs]: https://doc.crds.dev/github.com/crossplane/crossplane/meta.pkg.crossplane.io/Provider/v1
-[configuration-docs]: https://doc.crds.dev/github.com/crossplane/crossplane/meta.pkg.crossplane.io/Configuration/v1
-[lock-api]: https://doc.crds.dev/github.com/crossplane/crossplane/pkg.crossplane.io/Lock/v1beta1
-[specification]: https://github.com/Masterminds/semver#basic-comparisons
-[composition]: {{][}}
-[IAM Roles for Service Accounts]: https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html
-[controller-config-docs]: https://doc.crds.dev/github.com/crossplane/crossplane/pkg.crossplane.io/ControllerConfig/v1alpha1
-[package format]: https://github.com/crossplane/crossplane/blob/1aa83092172bdf0d2ed64754d33517c612ff7368/design/one-pager-package-format-v2.md
-[provider-gcp]: https://doc.crds.dev/github.com/crossplane/crossplane/meta.pkg.crossplane.io/Provider/v1
-[emptyDir-volume]: https://kubernetes.io/docs/concepts/storage/volumes/#emptydir
-[pvc]: https://kubernetes.io/docs/concepts/storage/volumes/#persistentvolumeclaim
-[OCI registry]: https://github.com/opencontainers/distribution-spec
-[pre-pulling images]: https://kubernetes.io/docs/concepts/containers/images/#pre-pulled-images
diff --git a/content/v1.11/concepts/providers.md b/content/v1.11/concepts/providers.md
deleted file mode 100644
index 61af5220b..000000000
--- a/content/v1.11/concepts/providers.md
+++ /dev/null
@@ -1,447 +0,0 @@
----
-title: Providers
-weight: 101
----
-
-Providers enable Crossplane to provision infrastructure on an
-external service. Providers create new Kubernetes APIs and map them to external
-APIs.
-
-Providers are responsible for all aspects of connecting to non-Kubernetes
-resources. This includes authentication, making external API calls and
-providing
-[Kubernetes Controller](https://kubernetes.io/docs/concepts/architecture/controller/)
-logic for any external resources.
-
-Examples of providers include:
-
-* [Provider AWS](https://github.com/upbound/provider-aws)
-* [Provider Azure](https://github.com/upbound/provider-azure)
-* [Provider GCP](https://github.com/upbound/provider-gcp)
-* [Provider Kubernetes](https://github.com/crossplane-contrib/provider-kubernetes)
-
-{{< hint "tip" >}}
-Find more providers in the [Upbound Marketplace](https://marketplace.upbound.io).
-{{< /hint >}}
-
-
-
-Providers define every external resource they can create in Kubernetes as a
-Kubernetes API endpoint. These endpoints are
-[_Managed Resources_]({{][}}).
-
-
-{{< hint "note" >}}
-Instructions on building your own Provider are outside of the scope of this
-document. Read the Crossplane contributing [Provider Development
-Guide](https://github.com/crossplane/crossplane/blob/master/contributing/guide-provider-development.md)
-for more information.
-{{< /hint >}}
-
-## Install a Provider
-
-Installing a provider creates a Provider pod that's responsible for installing
-the Provider's APIs into the Kubernetes cluster. Providers constantly watch the
-state of the desired managed resources and create any external resources that
-are missing.
-
-Install a Provider with a Crossplane
-{{}}Provider{{}} object setting the
-{{}}spec.package{{}} value to the
-location of the provider package.
-
-For example, to install the
-[AWS Community Provider](https://github.com/crossplane-contrib/provider-aws),
-
-```yaml {label="install"}
-apiVersion: pkg.crossplane.io/v1
-kind: Provider
-metadata:
- name: provider-aws
-spec:
- package: xpkg.upbound.io/crossplane-contrib/provider-aws:v0.39.0
-```
-
-{{< hint "tip" >}}
-Providers are Crossplane Packages. Read more about Packages in the
-[Packages documentation]({{][}}).
-{{< /hint >}}
-
-By default, the Provider pod installs in the same namespace as Crossplane
-(`crossplane-system`).
-
-### Install with Helm
-
-Crossplane supports installing Providers during an initial Crossplane
-installation with the Crossplane Helm chart.
-
-Use the
-{{}}--set provider.packages{{}}
-argument with `helm install`.
-
-For example, to install the AWS Community Provider,
-
-```shell {label="helm"}
-helm install crossplane \
-crossplane-stable/crossplane \
---namespace crossplane-system \
---create-namespace \
---set provider.packages='{xpkg.upbound.io/crossplane-contrib/provider-aws:v0.39.0}'
-```
-
-### Install from a private repository
-
-Installing a Provider from a private package repository requires a
-Kubernetes secret object. The Provider uses the secret with the
-{{}}packagePullSecrets{{}} option.
-
-```yaml {label="pps"}
-apiVersion: pkg.crossplane.io/v1
-kind: Provider
-metadata:
- name: private-provider
-spec:
- package: private-repo.example.org/providers/my-provider
- packagePullSecrets:
- - name: my-secret
-```
-
-{{< hint "note" >}}
-The Kubernetes secret object the Provider uses must be in the same namespace as
-the Crossplane pod.
-{{< /hint >}}
-
-## Upgrade a Provider
-
-To upgrade an existing Provider edit the installed Provider Package by either
-applying a new Provider manifest or with `kubectl edit providers`.
-
-Update the version number in the Provider's `spec.package` and apply the change.
-Crossplane installs the new image and creates a new `ProviderRevision`.
-
-## Remove a Provider
-
-Remove a Provider by deleting the Provider object with `kubectl delete
-provider`.
-
-{{< hint "warning" >}}
-Removing a Provider without first removing the Provider's managed resources
-may abandon the resources. The external resources aren't deleted.
-
-If you remove the Provider first, you must manually delete external resources
-through your cloud provider. Managed resources must be manually deleted by
-removing their finalizers.
-
-For more information on deleting abandoned resources read the [Crossplane
-troubleshooting guide]({{][}}).
-{{< /hint >}}
-
-## Verify a Provider
-
-Providers install their own APIs representing the managed resources they support.
-Providers may also create Deployments, Service Accounts or RBAC configuration.
-
-View the status of a Provider with
-
-`kubectl get providers`
-
-During the install a Provider report `INSTALLED` as `True` and `HEALTHY` as
-`Unknown`.
-
-```shell {copy-lines="1"}
-kubectl get providers
-NAME INSTALLED HEALTHY PACKAGE AGE
-crossplane-contrib-provider-aws True Unknown xpkg.upbound.io/crossplane-contrib/provider-aws:v0.39.0 63s
-```
-
-After the Provider install completes and it's ready for use the `HEALTHY` status
-reports `True`.
-
-```shell {copy-lines="1"}
-kubectl get providers
-NAME INSTALLED HEALTHY PACKAGE AGE
-crossplane-contrib-provider-aws True True xpkg.upbound.io/crossplane-contrib/provider-aws:v0.39.0 88s
-```
-
-{{}}
-Some Providers install hundreds of Kubernetes Custom Resource Definitions (`CRDs`).
-This can create significant strain on undersized API Servers, impacting Provider
-install times.
-
-The Crossplane community has more
-[details on scaling CRDs](https://github.com/crossplane/crossplane/blob/master/design/one-pager-crd-scaling.md).
-{{< /hint >}}
-
-### Provider conditions
-
-Crossplane uses a standard set of `Conditions` for Providers.
-View the conditions of a provider under their `Status` with
-`kubectl describe provider`.
-
-```yaml
-kubectl describe provider
-Name: my-provider
-API Version: pkg.crossplane.io/v1
-Kind: Provider
-# Removed for brevity
-Status:
- Conditions:
- Reason: HealthyPackageRevision
- Status: True
- Type: Healthy
- Reason: ActivePackageRevision
- Status: True
- Type: Installed
-# Removed for brevity
-```
-
-#### Types
-
-Provider `Conditions` support two `Types`:
-
-* `Type: Installed` - the Provider package installed but isn't ready for use.
-* `Type: Healthy` - The Provider package is ready to use.
-
-#### Reasons
-
-Each `Reason` relates to a specific `Type` and `Status`. Crossplane uses the
-following `Reasons` for Provider `Conditions`.
-
-
-##### InactivePackageRevision
-
-`Reason: InactivePackageRevision` indicates the Provider Package is using an
-inactive Provider Package Revision.
-
-
-```yaml
-Type: Installed
-Status: False
-Reason: InactivePackageRevision
-```
-
-
-##### ActivePackageRevision
-
-The Provider Package is the current Package Revision, but Crossplane hasn't
-finished installing the Package Revision yet.
-
-{{< hint "tip" >}}
-Providers stuck in this state are because of a problem with Package Revisions.
-
-Use `kubectl describe providerrevisions` for more details.
-{{< /hint >}}
-
-```yaml
-Type: Installed
-Status: True
-Reason: ActivePackageRevision
-```
-
-
-##### HealthyPackageRevision
-
-The Provider is fully installed and ready to use.
-
-{{}}
-`Reason: HealthyPackageRevision` is the normal state of a working Provider.
-{{< /hint >}}
-
-
-```yaml
-Type: Healthy
-Status: True
-Reason: HealthyPackageRevision
-```
-
-
-##### UnhealthyPackageRevision
-
-
-There was an error installing the Provider Package Revision, preventing
-Crossplane from installing the Provider Package.
-
-{{}}
-Use `kubectl describe providerrevisions` for more details on why the Package
-Revision failed.
-{{< /hint >}}
-
-```yaml
-Type: Healthy
-Status: False
-Reason: UnhealthyPackageRevision
-```
-
-##### UnknownPackageRevisionHealth
-
-
-The status of the Provider Package Revision is `Unknown`. The Provider Package
-Revision may be installing or has an issue.
-
-{{}}
-Use `kubectl describe providerrevisions` for more details on why the Package
-Revision failed.
-{{< /hint >}}
-
-```yaml
-Type: Healthy
-Status: Unknown
-Reason: UnknownPackageRevisionHealth
-```
-
-## Configure a Provider
-
-Providers have two different types of configurations:
-
-* _Controller configurations_ that change the settings of the Provider pod
- running inside the Kubernetes cluster. For example, Pod `toleration`.
-* _Provider configurations_ that change settings used when communicating with
- an external provider. For example, cloud provider authentication.
-
-{{}}
-Apply `ControllerConfig` objects to Providers.
-
-Apply `ProviderConfig` objects to managed resources.
-{{< /hint >}}
-
-### Controller configuration
-
-{{< hint "important" >}}
-The Crossplane community deprecated the `ControllerConfig` type in v1.11 to
-indicate that no further enhancements will be made to it.
-Applying a Controller configuration generates a deprecation warning.
-
-Controller configurations are still supported until there is a replacement type
-in a future Crossplane version. You can read more about the design of
-[Package Runtime Config](https://github.com/crossplane/crossplane/blob/master/design/one-pager-package-runtime-config.md)
-which will replace it in the future.
-{{< /hint >}}
-
-Applying a Crossplane `ControllerConfig` to a Provider changes the settings of
-the Provider's pod. The
-[Crossplane ControllerConfig schema](https://doc.crds.dev/github.com/crossplane/crossplane/pkg.crossplane.io/ControllerConfig/v1alpha1)
-defines the supported set of ControllerConfig settings.
-
-The most common use-case for ControllerConfigs are providing `args` to a
-Provider's pod enabling optional services. For example, enabling
-[external secret stores](https://docs.crossplane.io/knowledge-base/integrations/vault-as-secret-store/#enable-external-secret-stores-in-the-provider)
-for a Provider.
-
-Each Provider determines their supported set of `args`.
-
-### Provider configuration
-
-The `ProviderConfig` determines settings the Provider uses communicating to the
-external provider. Each Provider determines available settings of their
-`ProviderConfig`.
-
-
-
-Provider authentication is usually configured with a `ProviderConfig`. For
-example, to use basic key-pair authentication with Provider AWS a
-{{}}ProviderConfig{{}}
-{{}}spec{{}}
-defines the
-{{}}credentials{{}} and that
-the Provider pod should look in the Kubernetes
-{{}}Secrets{{}} objects and use
-the key named
-{{}}aws-creds{{}}.
-
-```yaml {label="providerconfig"}
-apiVersion: aws.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: aws-provider
-spec:
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: aws-creds
- key: creds
-```
-
-{{< hint "important" >}}
-Authentication configuration may be different across Providers.
-
-Read the documentation on a specific Provider for instructions on configuring
-authentication for that Provider.
-{{< /hint >}}
-
-
-
-ProviderConfig objects apply to individual Managed Resources. A single
-Provider can authenticate with multiple users or accounts through
-ProviderConfigs.
-
-
-Each account's credentials tie to a unique ProviderConfig. When creating a
-managed resource, attach the desired ProviderConfig.
-
-For example, two AWS ProviderConfigs, named
-{{}}user-keys{{}} and
-{{}}admin-keys{{}}
-use different Kubernetes secrets.
-
-```yaml {label="user"}
-apiVersion: aws.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: user-keys
-spec:
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: my-key
- key: secret-key
-```
-
-```yaml {label="admin"}
-apiVersion: aws.crossplane.io/v1beta1
-kind: ProviderConfig
-metadata:
- name: admin-keys
-spec:
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: admin-key
- key: admin-secret-key
-```
-
-Apply the ProviderConfig when creating a managed resource.
-
-This creates an AWS {{}}Bucket{{< /hover >}}
-resource using the
-{{}}user-keys{{< /hover >}} ProviderConfig.
-
-```yaml {label="user-bucket"}
-apiVersion: s3.aws.upbound.io/v1beta1
-kind: Bucket
-metadata:
- name: user-bucket
-spec:
- forProvider:
- region: us-east-2
- providerConfigRef:
- name: user-keys
-```
-
-This creates a second {{}}Bucket{{< /hover >}}
-resource using the
-{{}}admin-keys{{< /hover >}} ProviderConfig.
-
-```yaml {label="admin-bucket"}
-apiVersion: s3.aws.upbound.io/v1beta1
-kind: Bucket
-metadata:
- name: user-bucket
-spec:
- forProvider:
- region: us-east-2
- providerConfigRef:
- name: admin-keys
-```
diff --git a/content/v1.11/concepts/terminology.md b/content/v1.11/concepts/terminology.md
deleted file mode 100644
index 7b98f6410..000000000
--- a/content/v1.11/concepts/terminology.md
+++ /dev/null
@@ -1,211 +0,0 @@
----
-title: Terminology
-weight: 110
----
-## A Note on Style
-
-Each type of Kubernetes resource has a ‘Pascal case’ name - i.e. a title case
-name with no spaces between each word. Examples include ‘DaemonSet’ and
-‘PersistentVolumeClaim’. Often these names are written using fixed width fonts
-to draw attention to the fact that they’re a concrete type of resource within
-the API - e.g. `PersistentVolumeClaim`.
-
-Crossplane follows this convention. We often use names like RDSInstance or
-CompositeResourceDefinition when discussing Crossplane types. Crossplane also
-has “classes of types” - i.e. concepts that aren’t a distinct type of API
-resource, but rather describe a group of conceptually similar types. For example
-there is no ManagedResource type in Crossplane - instead types like RDSInstance
-and GKECluster are said to be “a managed resource”.
-
-Use your discretion as to whether you use pascal case when writing about a
-distinct type - e.g. “RDS Instance” and “RDSInstance” are both fine. The pascal
-case form makes more sense in contexts like documentation where you’re referring
-to Crossplane’s RDSInstance managed resource rather than the general concept of
-“an RDS instance”. Avoid using Pascal case when talking about classes of types -
-i.e. always write “managed resource”, not “ManagedResource”. Each of the below
-terms clarify whether they correspond to a single type, or a class of types.
-
-### Why 'X'?
-
-You may notice that Crossplane uses “X” as shorthand for “Crossplane” and/or
-“Composite”. This is because some of our concepts - specifically Composite
-Resources (XRs) and Composite Resource Definitions (XRDs) are modelled on
-similar Kubernetes concepts - Custom Resources (CRs) and Custom Resource
-Definitions (CRDs). We chose to abbreviate to (e.g.) XRD instead of CRD to avoid
-confusion.
-
-## Crossplane Terms
-
-The below terms are commonly used in the Crossplane ecosystem.
-
-### Composition
-
-The term Composition has two related but distinct meanings.
-
-“Composition” refers broadly to the feature of Crossplane that allows teams to
-define their own opinionated platform APIs.
-
-“A Composition” or `Composition` (fixed width) refers to the key Crossplane API
-type that configures how Crossplane should compose resources into a higher level
-“composite resource”. A Composition tells Crossplane “when someone creates
-composite resource X, you should respond by creating resources Y and Z”.
-
-The latter use of Composition represents a distinct Crossplane API type so
-Pascal case and fixed width fonts are appropriate. We also tend to capitalise
-the former use, representing the feature in general, but fixed width fonts are
-not appropriate in that context.
-
-> Folks accustomed to Terraform might think of a Composition as a Terraform
-> module; the HCL code that describes how to take input variables and use them
-> to create resources in some cloud API. Folks accustomed to Helm might think of
-> a Composition as a Helm chart’s templates; the moustache templated YAML files
-> that describe how to take Helm chart values and render Kubernetes resources.
-
-### Composite Resource
-
-A “Composite Resource” or “XR” is an API type defined using Crossplane. A
-composite resource’s API type is arbitrary - dictated by the concept the author
-wishes to expose as an API, for example an “AcmeCoDB”. A common convention is
-for types to start with "X" - e.g. "XAcmeCoDB".
-
-We talk about Crossplane being a tool teams can use to define their own
-opinionated platform APIs. Those APIs are made up of composite resources; when
-you are interacting with an API that your platform team has defined, you’re
-interacting with composite resources.
-
-A composite resource can be thought of as the interface to a Composition. It
-provides the inputs a Composition uses to compose resources into a higher level
-concept. In fact, the composite resource _is_ the high level concept.
-
-The term “Composite Resource” refers to a class of types, so avoid using Pascal
-case - “Composite Resource” not CompositeResource. Use pascal case when
-referring to a distinct type of composite resource - e.g. a XAcmeCoDB.
-
-> Folks accustomed to Terraform might think of a composite resource as a
-> `tfvars` file that supplies values for the variables a Terraform module uses
-> to create resources in some cloud API. Folks accustomed to Helm might think of
-> a composite resource as the `values.yaml` file that supplies inputs to a Helm
-> chart’s templates.
-
-### Composite Resource Claim
-
-A “Composite Resource Claim”, “XRC”, or just “a claim” is also an API type
-defined using Crossplane. Each type of claim corresponds to a type of composite
-resource, and the pair have nearly identical schemas. Like composite resources,
-the type of a claim is arbitrary.
-
-We talk about Crossplane being a tool platform teams can use to offer
-opinionated platform APIs to the application teams they support. The platform
-team offers those APIs using claims. It helps to think of the claim as an
-application team’s interface to a composite resource. You could also think of
-claims as the public (app team) facing part of the opinionated platform API,
-while composite resources are the private (platform team) facing part.
-
-A common convention is for a claim to be of the same type as its corresponding
-composite resource, but without the "X" prefix. So an "AcmeCoDB" would be a type
-of claim, and a "XAcmeCoDB" would be the corresponding type of composite
-resource. This allows claim consumers to be relatively ignorant of Crossplane
-and composition, and to instead simply think about managing “an AcmeCo DB” while
-the platform team worries about the implementation details.
-
-The term “Composite Resource Claim” refers to a class of types, so avoid using
-Pascal case - “Composite Resource Claim” not CompositeResourceClaim. Use Pascal
-case when referring to a distinct type of composite resource claim - e.g. an
-AcmeCoDB.
-
-> Claims map to the same concepts as described above under the composite
-> resource heading; i.e. `tfvars` files and Helm `values.yaml` files. Imagine
-> that some `tfvars` files and some `values.yaml` files were only accessible to
-> the platform team while others were offered to application teams; that’s the
-> difference between a composite resource and a claim.
-
-### Composite Resource Definition
-
-A “Composite Resource Definition” or “XRD” is the API type used to define new
-types of composite resources and claims. Types of composite resources and types
-of claims exist because they were defined into existence by an XRD. The XRD
-configures Crossplane with support for the composite resources and claims that
-make up a platform API.
-
-XRDs are often conflated with composite resources (XRs) - try to avoid this.
-When someone uses the platform API to create infrastructure they’re not creating
-XRDs but rather creating composite resources (XRs). It may help to think of a
-composite resource as a database entry, while an XRD is a database schema. For
-those familiar with Kubernetes, the relationship is very similar to that between
-a Custom Resource Definition (CRD) and a Custom Resource (CR).
-
-A `CompositeResourceDefinition` is a distinct Crossplane API type, so Pascal
-case and fixed width fonts are appropriate.
-
-> There isn’t a direct analog to XRDs in the Helm ecosystem, but they’re a
-> little bit like the variable blocks in a Terraform module that define which
-> variables exist, whether those variables are strings or integers, whether
-> they’re required or optional, etc.
-
-### Managed Resource
-
-Managed resources are granular, high fidelity Crossplane representations of a
-resource in an external system - i.e. resources that are managed by Crossplane.
-Managed resources are what Crossplane enables platform teams to compose into
-higher level composite resources, forming an opinionated platform API. They're
-the building blocks of Crossplane.
-
-You’ll often hear three related terms used in the Crossplane ecosystem; composed
-resource, managed resource, and external resource. While there are some subtle
-contextual differences, these all broadly refer to the same thing. Take an
-RDSInstance for example; it is a managed resource. A distinct resource within
-the Crossplane API that represents an AWS RDS instance. When we make a
-distinction between the managed resource and an external resource we’re simply
-making the distinction between Crossplane’s representation of the thing (the
-`RDSInstance` in the Kubernetes API), and the actual thing in whatever external
-system Crossplane is orchestrating (the RDS instance in AWS's API). When we
-mention composed resources, we mean a managed resource of which a composite
-resource is composed.
-
-Managed resources are a class of resource, so avoid using Pascal case - “managed
-resource” not “ManagedResource”.
-
-> Managed resources are similar to Terraform resource blocks, or a distinct
-> Kubernetes resource within a Helm chart.
-
-### Package
-
-Packages extend Crossplane, either with support for new kinds of composite
-resources and claims, or support for new kinds of managed resources. There are
-two types of Crossplane package; configurations and providers.
-
-A package is not a distinct type in the Crossplane API, but rather a class of
-types. Therefore Pascal case is not appropriate.
-
-### Configuration
-
-A configuration extends Crossplane by installing conceptually related groups of
-XRDs and Compositions, as well as dependencies like providers or further
-configurations. Put otherwise, it configures the opinionated platform API
-that Crossplane exposes.
-
-A `Configuration` is a distinct type in the Crossplane API, therefore Pascal
-case and fixed width fonts are appropriate.
-
-### Provider
-
-A provider extends Crossplane by installing controllers for new kinds of managed
-resources. Providers typically group conceptually related managed resources; for
-example the AWS provider installs support for AWS managed resources like
-RDSInstance and S3Bucket.
-
-A `Provider` is a distinct type in the Crossplane API, therefore Pascal case and
-fixed width fonts are appropriate. Note that each Provider package has its own
-configuration type, called a `ProviderConfig`. Don’t confuse the two; the former
-installs the provider while the latter specifies configuration that is relevant
-to all of its managed resources.
-
-> Providers are directly analogous to Terraform providers.
-
-### Crossplane Resource Model
-
-The Crossplane Resource Model or XRM is neither a distinct Crossplane API type,
-or a class of types. Rather it represents the fact that Crossplane has a
-consistent, opinionated API. The strict definition of the XRM is currently
-somewhat vague, but it could broadly be interpreted as a catchall term referring
-to all of the concepts mentioned on this page.
diff --git a/content/v1.11/getting-started/provider-aws-part-2.md b/content/v1.11/getting-started/provider-aws-part-2.md
deleted file mode 100644
index eae352b9a..000000000
--- a/content/v1.11/getting-started/provider-aws-part-2.md
+++ /dev/null
@@ -1,967 +0,0 @@
----
-title: AWS Quickstart Part 2
-weight: 120
-tocHidden: true
----
-
-{{< hint "important" >}}
-This guide is part 2 of a series. Follow **[part 1]({{][}})**
-to install Crossplane and connect your Kubernetes cluster to AWS.
-
-**[Part 3]({{][}})** covers patching _composite resources_
-and using Crossplane _packages_.
-{{< /hint >}}
-
-This section creates a _[Composition](#create-a-composition)_,
-_[Composite Resource Definition](#define-a-composite-resource)_ and a
-_[Claim](#create-a-claim)_
-to create a custom Kubernetes API to create AWS resources. This custom API is a
-_Composite Resource_ (XR) API.
-
-## Prerequisites
-* Complete [quickstart part 1]({{][}}) connecting Kubernetes
- to AWS.
-* an AWS account with permissions to create an AWS S3 storage bucket and a
-DynamoDB instance
-
-{{}}
-1. Add the Crossplane Helm repository and install Crossplane
-```shell
-helm repo add \
-crossplane-stable https://charts.crossplane.io/stable
-helm repo update
-&&
-helm install crossplane \
-crossplane-stable/crossplane \
---namespace crossplane-system \
---create-namespace
-```
-
-2. When the Crossplane pods finish installing and are ready, apply the AWS Provider
-
-```yaml {label="provider",copy-lines="all"}
-cat <}}
-```ini {copy-lines="all"}
-[default]
-aws_access_key_id = $@$@
-aws_secret_access_key = $@$@
-```
-{{ editCode >}}
-
-4. Create a Kubernetes secret from the AWS keys
-```shell {label="kube-create-secret",copy-lines="all"}
-kubectl create secret \
-generic aws-secret \
--n crossplane-system \
---from-file=creds=./aws-credentials.txt
-```
-
-5. Create a _ProviderConfig_
-```yaml {label="providerconfig",copy-lines="all"}
-cat <}}
-
-## Create a composition
-[Part 1]({{][}}) created a single _managed resource_.
-A _Composition_ is a template to create one or more _managed resource_ at the same time.
-
-This sample _composition_ creates an DynamoDB instance and associated S3 storage
-bucket.
-
-{{< hint "note" >}}
-This example comes from the AWS recommendation for
-[storing large DynamoDB attributes in S3](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-use-s3-too.html#bp-use-s3-too-large-values).
-{{< /hint >}}
-
-To create a _composition_, first define each individual managed resource.
-
-### Create an S3 bucket object
-Define a `bucket` resource using the configuration from the previous section:
-
-{{< hint "note" >}}
-Don't apply this configuration. This YAML is part of a larger
-definition.
-{{< /hint >}}
-
-```yaml
-apiVersion: s3.aws.upbound.io/v1beta1
-kind: Bucket
-metadata:
- name: crossplane-quickstart-bucket
-spec:
- forProvider:
- region: "us-east-2"
- providerConfigRef:
- name: default
-```
-
-### Create a DynamoDB table resource
-Next, define a DynamoDB `table` resource.
-
-{{< hint "tip" >}}
-The [Upbound Marketplace](https://marketplace.upbound.io/) provides
-[schema
-documentation](https://marketplace.upbound.io/providers/upbound/provider-aws/v0.27.0/resources/dynamodb.aws.upbound.io/Table/v1beta1)
-for a `Table` resource.
-{{< /hint >}}
-
-The _AWS Provider_ defines the
-{{}}apiVersion{{}}
-and
-{{}}kind{{}}.
-
-DynamoDB instances require a
-{{}}region{{}},
-{{}}writeCapacity{{}}
-and
-{{}}readCapacity{{}}
-parameters.
-
-The {{}}attribute{{}} section creates
-the database "Partition key" and "Hash key."
-
-This example creates a single key named
-{{}}S3ID{{}} of type
-{{}}S{{}} for "string"
-```yaml {label="dynamoMR"}
-apiVersion: dynamodb.aws.upbound.io/v1beta1
-kind: Table
-metadata:
- name: crossplane-quickstart-database
-spec:
- forProvider:
- region: "us-east-2"
- writeCapacity: 1
- readCapacity: 1
- attribute:
- - name: S3ID
- type: S
- hashKey: S3ID
-```
-
-{{< hint "note" >}}
-DynamoDB specifics are beyond the scope of this guide. Read the
-[DynamoDB Developer Guide](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html)
-for more information.
-{{]}}
-
-### Create the composition object
-The _composition_ combines the two resource definitions.
-
-A
-{{}}Composition{{ hover>}} comes from the
-{{}}Crossplane{{ hover>}}
-API resources.
-
-Create any {{}}name{{ hover>}} for this _composition_.
-
-```yaml {label="compName"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-metadata:
- name: dynamodb-with-bucket
-```
-
-Add the resources to the
-{{}}spec.resources{{ hover>}}
-section of the _composition_.
-
-Give each resource a
-{{}}name{{ hover>}}
-and put the resource definition under the
-{{}}base{{ hover>}}
-key.
-
-```yaml {label="specResources"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-metadata:
- name: dynamodb-with-bucket
-spec:
- resources:
- - name: s3-bucket
- base:
- apiVersion: s3.aws.upbound.io/v1beta1
- kind: Bucket
- spec:
- forProvider:
- region: "us-east-2"
- providerConfigRef:
- name: default
- - name: dynamodb
- base:
- apiVersion: dynamodb.aws.upbound.io/v1beta1
- kind: Table
- spec:
- forProvider:
- region: "us-east-2"
- writeCapacity: 1
- readCapacity: 1
- attribute:
- - name: S3ID
- type: S
- hashKey: S3ID
-```
-
-_Compositions_ are a template for generating resources. A _composite
-resource_ actually creates the resources.
-
-A _composition_ defines what _composite resources_ can use this
-template.
-
-_Compositions_ do this with the
-{{}}spec.compositeTypeRef{{ hover>}}
-definition.
-
-{{< hint "tip" >}}
-Crossplane recommends prefacing the `kind` with an `X` to show it's a Composition.
-{{< /hint >}}
-
-```yaml {label="compRef"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-metadata:
- name: dynamodb-with-bucket
-spec:
- compositeTypeRef:
- apiVersion: custom-api.example.org/v1alpha1
- kind: XDatabase
- resources:
- # Removed for Brevity
-```
-
-A _composite resource_ is actually a custom Kubernetes API type you define. The
-platform team controls the kind, API endpoint and version.
-
-
-
-With this {{}}spec.compositeTypeRef{{ hover>}}
-Crossplane only allows _composite resources_ from the API group
-{{}}custom-api.example.org{{ hover>}}
-that are of
-{{}}kind: XDatabase{{ hover>}}
-to use this template to create resources.
-
-
-### Apply the composition
-Apply the full _Composition_ to your Kubernetes cluster.
-
-```yaml
-cat <}}
-_Composite resource definitions_ are also called `XRDs` for short.
-{{< /hint >}}
-
-Just like a _composition_ the
-{{}}composite resource definition{{}}
-is part of the
-{{}}Crossplane{{}}
-API group.
-
-The _XRD_ {{}}name{{}} is the new
-API endpoint.
-
-{{< hint "tip" >}}
-Crossplane recommends using a plural name for the _XRD_
-{{}}name{{}}.
-{{< /hint >}}
-
-```yaml {label="xrdName"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-metadata:
- name: xdatabases.custom-api.example.org
-```
-
-The _XRD's_
-{{}}spec{{}} defines the new custom
-API.
-
-### Define the API endpoint and kind
-First, define the new API
-{{}}group{{}}.
-Next, create the API {{}}kind{{}} and
-{{}}plural{{}}.
-
-```yaml {label="xrdGroup"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-metadata:
- name: xdatabases.custom-api.example.org
-spec:
- group: custom-api.example.org
- names:
- kind: XDatabase
- plural: xdatabases
-```
-
-{{}}
-The _XRD_ {{}}group{{}} matches the _composition_ {{}}apiVersion{{}} and the
-_XRD_ {{}}kind{{}} matches the _composition_
-{{}}compositeTypeRef.kind{{}}.
-
-```yaml {label="noteComp"}
-kind: Composition
-# Removed for brevity
-spec:
- compositeTypeRef:
- apiVersion: custom-api.example.org/v1alpha1
- kind: XDatabase
-```
-{{< /hint >}}
-
-### Set the API version
-In Kubernetes, all API endpoints have a version to show the stability of the API
-and track revisions.
-
-Apply a version to the _XRD_ with a
-{{}}versions.name{{}}.
-This matches the
-{{}}compositeTypeRef.apiVersion{{}}
-
-_XRDs_ require both
-{{}}versions.served{{}}
-and
-{{}}versions.referenceable{{}}.
-
-```yaml {label="xrdVersion"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-metadata:
- name: xdatabases.custom-api.example.org
-spec:
- group: custom-api.example.org
- names:
- kind: XDatabase
- plural: xdatabases
- versions:
- - name: v1alpha1
- served: true
- referenceable: true
-```
-
-{{}}
-For more information on defining versions in Kubernetes read the
-[API versioning](https://kubernetes.io/docs/reference/using-api/#api-versioning) section of the Kubernetes documentation.
-{{< /hint >}}
-
-### Create the API schema
-With an API endpoint named, now define the API schema, or what's allowed
-inside the `spec` of the new Kubernetes object.
-
-{{< hint "note" >}}
-_XRDs_ follow the Kubernetes
-[_custom resource definition_ rules for schemas](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema).
-{{}}
-
-Place the API
-{{< hover label="xrdSchema" line="8" >}}schema{{}}
-under the
-{{< hover label="xrdSchema" line="7" >}}version.name{{}}
-
-The _XRD_ type defines the next lines. They're always the same.
-
-
-
-{{< hover label="xrdSchema" line="9" >}}openAPIV3Schema{{}} specifies
-how the schema gets validated.
-
-
-Next, the entire API is an
-{{< hover label="xrdSchema" line="10" >}}object{{}}
-with a
-{{< hover label="xrdSchema" line="11" >}}property{{}} of
-{{< hover label="xrdSchema" line="12" >}}spec{{}}.
-
-The
-{{< hover label="xrdSchema" line="12" >}}spec{{}} is also an
-{{< hover label="xrdSchema" line="13" >}}object{{}} with
-{{< hover label="xrdSchema" line="14" >}}properties{{}}.
-
-```yaml {label="xrdSchema"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-# Removed for brevity
-spec:
- # Removed for brevity
- versions:
- - name: v1alpha1
- schema:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
-```
-
-{{< hint "tip" >}}
-For more information on the values allowed in a _composite resource definition_ view its schema with
-`kubectl explain xrd`
-{{< /hint >}}
-
-Now, define the custom API. Your custom API continues under the last
-{{}}properties{{}} definition in the
-previous example.
-
-This custom API has only one setting:
-
-* {{}}region{{}} - where to deploy
-the resources, a choice of "EU" or "US"
-
-
-Users can't change any other settings of the S3 bucket or DynamoDB instance.
-
-The{{}}region{{}}
-is a {{}}string{{}}
-and can match the regular expression that's
-{{}}oneOf{{}}
-{{}}EU{{}}
-or
-{{}}US{{}}.
-
-This API requires the setting
-{{}}region{{}}.
-
-
-```yaml {label="customAPI"}
-# Removed for brevity
-# schema.openAPIV3Schema.type.properties.spec
-properties:
- region:
- type: string
- oneOf:
- - pattern: '^EU$'
- - pattern: '^US$'
-required:
- - region
-```
-
-### Enable claims to the API
-Tell this _XRD_ to offer a _claim_ by defining the _claim_ API endpoint under
-the _XRD_ {{}}spec{{< /hover >}}.
-
-{{< hint "tip" >}}
-Crossplane recommends a _Claim_ {{}}kind{{ hover>}} match the _Composite Resource_ (XR)
-{{}}kind{{ hover>}},
-without the preceding `X`.
-{{< /hint >}}
-
-
-```yaml {label="XRDclaim"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-# Removed for brevity
-spec:
-# Removed for brevity
- names:
- kind: XDatabase
- plural: xdatabases
- claimNames:
- kind: Database
- plural: databases
-```
-
-{{}}
-The [Claims](#create-a-claim) section later in this guide discusses _claims_.
-{{< /hint >}}
-
-### Apply the composite resource definition
-Apply the complete _XRD_ to your Kubernetes cluster.
-
-
-```yaml
-cat <}}group{{}}
-becomes the _composite resource_
-{{}}apiVersion{{}}.
-
-The _XRD_ {{}}kind{{}}
-is the _composite resource_
-{{}}kind{{}}
-
-The _XRD_ API {{}}spec{{}} defines the
-_composite resource_ {{}}spec{{}}.
-
-The _XRD_ {{}}properties{{}} section
-defines the options for the _composite resource_
-{{}}spec{{}}.
-
-The one option is {{}}region{{}} and it
-can be either {{}}EU{{}} or
-{{}}US{{}}.
-
-This _composite resource_ uses
-{{}}region: US{{}}.
-
-### Apply the composite resource
-
-Apply the composite resource to the Kubernetes cluster.
-
-```yaml {label="xr"}
-cat <}}
-Use `kubectl get ` to view a specific `kind` of _composite resource_.
-View all _composite resources_ with `kubectl get composite`.
-{{< /hint >}}
-
-```shell {copy-lines="1"}
-kubectl get xdatabase
-NAME SYNCED READY COMPOSITION AGE
-my-composite-resource True True dynamo-with-bucket 31s
-```
-
-Both `SYNCED` and `READY` are `True` when Crossplane created the AWS resources.
-
-Now look at the S3 `bucket` and DynmoDB `table` _managed resources_ with
-`kubectl get bucket` and `kubectl get table`.
-
-{{< hint "important" >}}
-This guide uses Upbound AWS provider v0.27.0. AWS Provider v0.30.0 and later
-requires the full CRD name `bucket.s3.aws.upbound.io` instead of `buckets`.
-{{}}
-
-```shell {copy-lines="1"}
-kubectl get bucket
-NAME READY SYNCED EXTERNAL-NAME AGE
-my-composite-resource-8b6tx True True my-composite-resource-8b6tx 56s
-```
-
-```shell {copy-lines="1"}
-kubectl get table
-NAME READY SYNCED EXTERNAL-NAME AGE
-my-composite-resource-m6vk6 True True my-composite-resource-m6vk6 59s
-```
-
-The _composite resource_ automatically generated both _managed resources_.
-
-Using `kubectl describe` on a _managed resource_ shows the `Owner References` is
-the _composite resource_.
-
-```yaml {copy-lines="1"}
-kubectl describe bucket | grep "Owner References" -A5
- Owner References:
- API Version: custom-api.example.org/v1alpha1
- Block Owner Deletion: true
- Controller: true
- Kind: XDatabase
- Name: my-composite-resource
-```
-
-Each _composite resource_ creates and owns a unique set of _managed resources_.
-If you create a second _composite resource_ Crossplane creates a new S3 `bucket`
-and DynamoDB `table`.
-
-```yaml {label="xr"}
-cat <}}
-Delete a specific _composite resource_ with `kubectl delete ` or
-`kubectl delete composite`.
-{{< /hint >}}
-
-Delete the second composition
-```shell
-kubectl delete xdatabase my-second-composite-resource
-```
-
-{{}}
-There may a delay in deleting the _managed resources_. Crossplane is making API
-calls to AWS and waits for AWS to confirm they deleted the resources before
-updating the state in Kubernetes.
-{{}}
-
-Now only one bucket and table exist.
-
-```shell {copy-lines="1"}
-kubectl get bucket
-NAME READY SYNCED EXTERNAL-NAME AGE
-my-composite-resource-8b6tx True True my-composite-resource-8b6tx 7m34s
-```
-
-```shell {copy-lines="1"}
-kubectl get table
-NAME READY SYNCED EXTERNAL-NAME AGE
-my-composite-resource-m6vk6 True True my-composite-resource-m6vk6 7m37s
-```
-
-Delete the other _composite resource_ to remove the last `bucket` and `table`
-_managed resources_.
-
-```shell
-kubectl delete xdatabase my-composite-resource
-```
-
-_Composite resources_ are great for creating one or more related resources against
-a template, but all _composite resources_ exist at the Kubernetes "cluster
-level." There's no isolation between _composite resources_. Crossplane uses
-_claims_ to create resources with namespace isolation.
-
-## Create a claim
-
-_Claims_, just like _composite resources_ use the custom API defined in the
-_XRD_. Unlike a _composite resource_, Crossplane can create _claims_ in a
-namespace.
-
-### Create a new Kubernetes namespace
-Create a new namespace with `kubectl create namespace`.
-
-```shell
-kubectl create namespace test
-```
-
-Look at the _XRD_ to see the parameters for the _claim_.
-A _claim_ uses the same {{}}group{{}}
-a _composite resource_ uses but a different
-{{}}kind{{}}.
-
-```yaml {label="XRDclaim2"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-# Removed for brevity
-spec:
-# Removed for brevity
- group: custom-api.example.org
- claimNames:
- kind: Database
- plural: databases
-```
-
-Like the _composite resource_, create a new object with the
-{{}}custom-api.example.org{{}} API
-endpoint.
-
-The _XRD_
-{{}}claimNames.kind{{}} defines the
-{{}}kind{{}}.
-
-The {{}}spec{{}} uses the same
-API options as the _composite resource_.
-
-### Apply the claim
-Apply the _claim_ to your Kubernetes cluster.
-
-```yaml {label="claim"}
-cat <}}
-View claims with `kubectl get ` or use `kubectl get claim` to view all
-_claims_.
-{{}}
-
-```shell {copy-lines="1"}
-kubectl get database -n test
-NAME SYNCED READY CONNECTION-SECRET AGE
-claimed-database True True 35s
-```
-
-When Crossplane creates a _claim_, a unique _composite resource_ is also
-created. View the new _composite resource_ with `kubectl get xdatabase`.
-
-```shell {copy-lines="1"}
-kubectl get xdatabase
-NAME SYNCED READY COMPOSITION AGE
-claimed-database-6xsgq True True dynamo-with-bucket 46s
-```
-
-The _composite resource_ exists at the "cluster scope" while the _claim_ exists
-at the "namespace scope."
-
-Create a second namespace and a second claim.
-
-```shell
-kubectl create namespace test2
-cat <}}) of this guide covers _composition
-patches_ and making all this configuration portable in Crossplane _packages_.
-
-## Next steps
-* **[Continue to part 3]({{< ref "provider-aws-part-3">}})** to create a learn
- about _patching_ resources and creating Crossplane _packages_.
-* Explore AWS resources that Crossplane can configure in the [Provider CRD reference](https://marketplace.upbound.io/providers/upbound/provider-family-aws/).
-* Join the [Crossplane Slack](https://slack.crossplane.io/) and connect with Crossplane users and contributors.
\ No newline at end of file
diff --git a/content/v1.11/getting-started/provider-aws-part-3.md b/content/v1.11/getting-started/provider-aws-part-3.md
deleted file mode 100644
index 12d68896a..000000000
--- a/content/v1.11/getting-started/provider-aws-part-3.md
+++ /dev/null
@@ -1,639 +0,0 @@
----
-title: AWS Quickstart Part 3
-weight: 120
-tocHidden: true
----
-
-{{< hint "important" >}}
-This guide is part 3 of a series.
-
-Follow **[part 1]({{[}})**
-to install Crossplane and connect your Kubernetes cluster to AWS.
-
-Follow **[part 2]({{][}})** to create a _composition_,
-_custom resource definition_ and a _claim_.
-{{< /hint >}}
-
-[Part 2]({{][}}) created a _composite resource
-definition_ to define the schema of the custom API. Users create a _claim_ to
-use the custom API and apply their options. Part 2 didn't show how the options
-set in a _claim_ change or get applied the associated _composite resources_.
-
-## Prerequisites
-* Complete quickstart [part 1]({{][}}) and [Part 2]({{][}}) to install Crossplane and the quickstart
- configurations.
-
-{{}}
-1. Add the Crossplane Helm repository and install Crossplane
-```shell
-helm repo add \
-crossplane-stable https://charts.crossplane.io/stable
-helm repo update
-&&
-helm install crossplane \
-crossplane-stable/crossplane \
---namespace crossplane-system \
---create-namespace
-```
-
-2. When the Crossplane pods finish installing and are ready, apply the AWS Provider
-
-```yaml {label="provider",copy-lines="all"}
-cat <}}
-```ini {copy-lines="all"}
-[default]
-aws_access_key_id = $@$@
-aws_secret_access_key = $@$@
-```
-{{ editCode >}}
-
-4. Create a Kubernetes secret from the AWS keys
-```shell {label="kube-create-secret",copy-lines="all"}
-kubectl create secret \
-generic aws-secret \
--n crossplane-system \
---from-file=creds=./aws-credentials.txt
-```
-
-5. Create a _ProviderConfig_
-```yaml {label="providerconfig",copy-lines="all"}
-cat <}}
-
-## Enable composition patches
-In a _composition_ `patches` map fields in the custom API to fields inside the
-_managed resources_.
-
-The example _composition_ has two _managed resources_, a
-{{}}bucket{{}} and a
-{{}}table{{}}.
-
-```yaml {label="compResources"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-# Removed for Brevity
-resources:
- - name: s3-bucket
- base:
- apiVersion: s3.aws.upbound.io/v1beta1
- kind: Bucket
- spec:
- forProvider:
- region: "us-east-2"
- - name: dynamodb
- base:
- apiVersion: dynamodb.aws.upbound.io/v1beta1
- kind: Table
- spec:
- forProvider:
- region: "us-east-2"
- writeCapacity: 1
- readCapacity: 1
- attribute:
- - name: S3ID
- type: S
- hashKey: S3ID
-```
-
-The custom API defined a single option,
-{{}}region{{}}. A
-{{}}region{{}} can be either
-{{}}EU{{}} or
-{{}}US{{}}.
-
-
-```yaml {label="xrdSnip"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-# Removed for brevity
-spec:
- group: custom-api.example.org
- names:
- kind: XDatabase
-# Removed for brevity
- spec:
- type: object
- properties:
- region:
- type: string
- oneOf:
- - pattern: '^EU$'
- - pattern: '^US$'
-```
-
-Creating a _composition_ `patch` allows Crossplane to update the settings of the
-_composite resource_. Patches apply to the individual _managed resources_
-inside the _composition_.
-
-A {{}}patch{{}} has a
-{{}}fromField{{}} and a
-{{}}toField{{}} specifying which value
-_from_ the custom API should apply _to_ the _managed resource_.
-Patches can create a
-{{}}transform{{}} to change the _from_
-field before it's applied.
-
-The transform
-{{}}type{{}} is what kind of change to
-make on the _from_ field. Types of changes could include appending a string,
-preforming a math operation or mapping one value to another.
-
-Applying a {{}}patch{{}} to the
-{{}}Bucket{{}} uses the custom API
-{{}}region{{}} to use as the _managed resource_
-{{}}region{{}}.
-
-
-The custom API value "EU" is
-{{}}mapped{{}} to the value "eu-north-1"
-and "US" is {{}}mapped{{}} to the value
-"us-east-2."
-
-
-
-```yaml {label="patch"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-# Removed for Brevity
-resources:
- - name: s3-bucket
- base:
- apiVersion: s3.aws.upbound.io/v1beta1
- kind: Bucket
- spec:
- forProvider:
- region: "us-east-2"
- patches:
- - fromFieldPath: "region"
- toFieldPath: "spec.forProvider.region"
- transforms:
- - type: map
- map:
- EU: "eu-north-1"
- US: "us-east-2"
-```
-
-Patching is a powerful tool enabling simpler or abstracted APIs. A developer
-isn't required to know the specific AWS region identifier, only the abstracted
-option of "EU" or "US."
-
-
-### Apply the updated composition
-Apply the same `patch` to the `Table` _managed resource_ and apply the updated
-_composition_.
-
-```yaml
-cat <}}region{{}} to "EU."
-
-```yaml {label="claim"}
-cat <
-Using {{}}region: "EU"{{}} patches the
-_composite resource_, updating the AWS region from `us-east-2` to `eu-north-1`.
-The developer creating the claim isn't required to know which specific AWS
-region or the naming conventions. Using the abstract API options of "EU" or "US"
-the developer places their resources in the desired location.
-
-
-Deleting the claim removes the _managed resources_.
-
-{{}}
-The _managed resources_ take up to 5 minutes to delete.
-{{< /hint >}}
-
-```shell
-kubectl delete database claimed-eu-database -n test
-```
-
-## Create a Crossplane configuration package
-
-Crossplane _configuration packages_ allow users to combine their _custom
-resource definition_ and _composition_ files into an OCI image.
-
-{{< hint "note" >}}
-The [Open Container Initiative](https://opencontainers.org/faq/)
-defines the OCI image standard.
-An OCI images is a standard way to package data.
-{{< /hint >}}
-
-You can host configuration packages in image registries like
-[Docker Hub](https://hub.docker.com/) or the
-[Upbound Marketplace](https://marketplace.upbound.io/).
-
-Crossplane can download and install configuration packages into a Kubernetes
-cluster.
-
-Creating a configuration package makes your Crossplane custom APIs portable
-and versioned.
-
-Building and installing configuration packages requires an OCI image compatible
-tool.
-
-{{< hint "note" >}}
-You can use any software that builds OCI images. This includes
-[Docker](https://www.docker.com/) or
-[Upbound's Up CLI)](https://github.com/upbound/up).
-{{< /hint >}}
-
-A configuration package includes three files:
-* `crossplane.yaml` defines the metadata of the package.
-* `definition.yaml` is the _composite resource definition_ for the package.
-* `composition.yaml` is the _composition_ template for the package.
-
-
-
-### Create a crossplane.yaml file
-
-Configuration packages describe their contents and requirements with a
-`crossplane.yaml` file.
-
-The `crossplane.yaml` file lists the required Crossplane _providers_ and their
-compatible versions as well as the required Crossplane version.
-
-The Crossplane
-{{}}meta.pkg{{}} API defines the schema
-for a
-{{}}Configuration{{}}.
-
-Inside the {{}}spec{{}} define the
-required Crossplane
-{{}}version{{}}.
-
-The {{}}dependsOn{{}} section lists the
-dependencies for a package.
-
-This package lists the Upbound
-{{}}provider-aws{{}}
-version {{}}0.27.0{{}} or later as a
-dependency.
-
-{{}}
-Crossplane automatically installs dependencies. Dependencies can include other
-configuration packages.
-{{< /hint >}}
-
-```yaml {label="xpyaml"}
-apiVersion: meta.pkg.crossplane.io/v1
-kind: Configuration
-metadata:
- name: crossplane-aws-quickstart
-spec:
- crossplane:
- version: ">=v1.11.0"
- dependsOn:
- - provider: xpkg.upbound.io/upbound/provider-aws
- version: ">=v0.27.0"
-```
-
-Create a new directory and save the `crossplane.yaml` file.
-
-```yaml
-mkdir crossplane-aws-quickstart
-cat < crossplane-aws-quickstart/crossplane.yaml
-apiVersion: meta.pkg.crossplane.io/v1
-kind: Configuration
-metadata:
- name: crossplane-aws-quickstart
-spec:
- crossplane:
- version: ">=v1.11.0"
- dependsOn:
- - provider: xpkg.upbound.io/upbound/provider-aws
- version: ">=v0.27.0"
-EOF
-```
-
-
-
-### Create a definition.yaml file
-
-
-A configuration package requires a _composite resource definition_ (XRD) to define the
-custom API.
-
-Save the _XRD_ as `definition.yaml` in the same directory as the
-`crossplane.yaml` file.
-
-```yaml
-cat < crossplane-aws-quickstart/definition.yaml
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-metadata:
- name: xdatabases.custom-api.example.org
-spec:
- group: custom-api.example.org
- names:
- kind: XDatabase
- plural: xdatabases
- versions:
- - name: v1alpha1
- served: true
- referenceable: true
- schema:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- region:
- type: string
- oneOf:
- - pattern: '^EU$'
- - pattern: '^US$'
- required:
- - region
- claimNames:
- kind: Database
- plural: databases
-EOF
-```
-
-
-
-### Create a composition.yaml file
-
-
-The _composition_ template creates the _managed resources_ and allows _patches_
-to customize the _managed resources_.
-
-Copy the _composition_ into the `composition.yaml` file in the same directory as
-`crossplane.yaml`.
-
-```yaml
-cat < crossplane-aws-quickstart/composition.yaml
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-metadata:
- name: dynamodb-with-bucket
-spec:
- compositeTypeRef:
- apiVersion: custom-api.example.org/v1alpha1
- kind: XDatabase
- resources:
- - name: s3-bucket
- base:
- apiVersion: s3.aws.upbound.io/v1beta1
- kind: Bucket
- spec:
- providerConfigRef:
- name: default
- patches:
- - fromFieldPath: "spec.region"
- toFieldPath: "spec.forProvider.region"
- transforms:
- - type: map
- map:
- EU: "eu-north-1"
- US: "us-east-1"
- - name: dynamodb
- base:
- apiVersion: dynamodb.aws.upbound.io/v1beta1
- kind: Table
- spec:
- forProvider:
- writeCapacity: 1
- readCapacity: 1
- attribute:
- - name: S3ID
- type: S
- hashKey: S3ID
- patches:
- - fromFieldPath: "spec.region"
- toFieldPath: "spec.forProvider.region"
- transforms:
- - type: map
- map:
- EU: "eu-north-1"
- US: "us-east-1"
-EOF
-```
-
-### Install the Crossplane command-line
-To build a configuration package install the Crossplane Kubernetes command-line
-extension.
-
-```shell
-wget "https://raw.githubusercontent.com/crossplane/crossplane/master/install.sh"
-chmod +x install.sh
-./install.sh
-sudo mv crossplane /usr/local/bin
-```
-
-Verify the Crossplane command-line installed with `crossplane --help`
-
-```shell
-crossplane --help
-Usage: crossplane
-
-A command line tool for interacting with Crossplane.
-
-Flags:
- -h, --help Show context-sensitive help.
- -v, --version Print version and quit.
- --verbose Print verbose logging statements.
-# Ouptut removed for brevity
-```
-
-### Build a configuration package
-
-Use the `crossplane` CLI to create an `.xpkg` file containing the
-custom APIs and Crossplane configuration.
-
-```shell
-crossplane build configuration -f crossplane-aws-quickstart/ --name="crossplane-aws-quickstart"
-```
-
-Now an `.xpkg` OCI image is inside the `crossplane-aws-quickstart` directory.
-
-```shell
-ls crossplane-aws-quickstart/
-composition.yaml crossplane-aws-quickstart.xpkg crossplane.yaml definition.yaml
-```
-
-## Next steps
-* Explore AWS resources that Crossplane can configure in the [Provider CRD reference](https://marketplace.upbound.io/providers/upbound/provider-family-aws/).
-* Join the [Crossplane Slack](https://slack.crossplane.io/) and connect with Crossplane users and contributors.
-* Read more about [Crossplane concepts]({{][}})
\ No newline at end of file
diff --git a/content/v1.11/getting-started/provider-azure-part-2.md b/content/v1.11/getting-started/provider-azure-part-2.md
deleted file mode 100644
index ea8446d89..000000000
--- a/content/v1.11/getting-started/provider-azure-part-2.md
+++ /dev/null
@@ -1,1056 +0,0 @@
----
-title: Azure Quickstart Part 2
-weight: 120
-tocHidden: true
----
-
-{{< hint "important" >}}
-This guide is part 2 of a series. Follow **[part 1]({{][}})**
-to install Crossplane and connect your Kubernetes cluster to Azure.
-
-**[Part 3]({{][}})** covers patching _CompositeResources_
-and using Crossplane _Packages_.
-{{< /hint >}}
-
-This section creates a _[Composition](#create-a-composition)_,
-_[CompositeResourceDefinition](#define-a-composite-resource)_ and a
-_[Claim](#create-a-claim)_
-to create a custom Kubernetes API to create Azure resources. This custom API
-is a _composite resource_ (XR) API.
-
-## Prerequisites
-* Complete [quickstart part 1]({{][}}) connecting
- Kubernetes to Azure.
-* an Azure account with permissions to create an Azure Virtual Machine and
- Virtual Networking
-
-{{}}
-1. Add the Crossplane Helm repository and install Crossplane
-```shell
-helm repo add \
-crossplane-stable https://charts.crossplane.io/stable
-helm repo update
-&&
-helm install crossplane \
-crossplane-stable/crossplane \
---namespace crossplane-system \
---create-namespace
-```
-
-2. When the Crossplane pods finish installing and are ready, apply the Azure
- Provider
-
-```yaml {label="provider",copy-lines="all"}
-cat <}}
-```console
-az ad sp create-for-rbac \
---sdk-auth \
---role Owner \
---scopes /subscriptions/$$$$
-```
-{{ editCode >}}
-
-4. Create a Kubernetes secret from the Azure JSON file.
-```shell {label="kube-create-secret",copy-lines="all"}
-kubectl create secret \
-generic azure-secret \
--n crossplane-system \
---from-file=creds=./azure-credentials.json
-```
-
-5. Create a _ProviderConfig_
-```yaml {label="providerconfig",copy-lines="all"}
-cat <}}
-
-## Create a composition
-[Part 1]({{][}}) created a single _managed resource_.
-A _Composition_ is a template to create one or more _managed resource_ at the
-same time.
-
-This sample _composition_ creates an Linux Virtual Machine and the required
-networking components.
-
-Compositions have multiple components:
-* The individual managed resources.
-* The Composition kind and version.
-* A Composite type reference.
-
-The following steps describe each of these components before
-[applying the final Composition](#apply-the-composition).
-
-### Define a virtual network
-Define a `virtualnetwork` resource using the configuration from the previous
-section:
-
-{{< hint "note" >}}
-Don't apply this configuration. This YAML is part of a larger
-definition.
-{{< /hint >}}
-
-```yaml {copy-lines="none"}
-apiVersion: network.azure.upbound.io/v1beta1
-kind: VirtualNetwork
-metadata:
- name: crossplane-quickstart-network
-spec:
- forProvider:
- addressSpace:
- - 10.0.0.0/16
- location: "Central US"
- resourceGroupName:
-```
-
-### Define a subnet resource
-Next, define a `Subnet` resource.
-
-{{< hint "note" >}}
-Don't apply this configuration. This YAML is part of a larger
-definition.
-{{< /hint >}}
-
-```yaml {label="subnet",copy-lines="none"}
-apiVersion: network.azure.upbound.io/v1beta1
-kind: Subnet
-metadata:
- name: crossplane-quickstart-subnet
-spec:
- forProvider:
- addressPrefixes:
- - 10.0.1.0/24
- resourceGroupName:
-```
-
-### Define a network interface
-Define a network interface to attach to the virtual machine.
-
-{{< hint "note" >}}
-Don't apply this configuration. This YAML is part of a larger
-definition.
-{{< /hint >}}
-
-```yaml {label="nic",copy-lines="none"}
-apiVersion: network.azure.upbound.io/v1beta1
-kind: NetworkInterface
-metadata:
- name: crossplane-quickstart-nic
-spec:
- forProvider:
- ipConfiguration:
- - name: crossplane-quickstart-configuration
- privateIpAddressAllocation: Dynamic
- location: "Central US"
- resourceGroupName:
-```
-
-### Define a virtual machine
-Define the `LinuxVirtualMachine` with its settings.
-
-{{< hint "note" >}}
-Don't apply this configuration. This YAML is part of a larger
-definition.
-{{< /hint >}}
-
-```yaml {label="vm",copy-lines="none"}
-apiVersion: compute.azure.upbound.io/v1beta1
-kind: LinuxVirtualMachine
-metadata:
- name: crossplane-quickstart-vm
-spec:
- forProvider:
- adminUsername: adminuser
- adminSshKey:
- - publicKey: ssh-rsa
- AAAAB3NzaC1yc2EAAAADAQABAAABAQC+wWK73dCr+jgQOAxNsHAnNNNMEMWOHYEccp6wJm2gotpr9katuF/ZAdou5AaW1C61slRkHRkpRRX9FA9CYBiitZgvCCz+3nWNN7l/Up54Zps/pHWGZLHNJZRYyAB6j5yVLMVHIHriY49d/GZTZVNB8GoJv9Gakwc/fuEZYYl4YDFiGMBP///TzlI4jhiJzjKnEvqPFki5p2ZRJqcbCiF4pJrxUQR/RXqVFQdbRLZgYfJ8xGB878RENq3yQ39d8dVOkq4edbkzwcUmwwwkYVPIoDGsYLaRHnG+To7FvMeyO7xDVQkMKzopTQV8AuKpyvpqu0a9pWOMaiCyDytO7GGN
- example@docs.crossplane.io
- username: adminuser
- location: "Central US"
- osDisk:
- - caching: ReadWrite
- storageAccountType: Standard_LRS
- size: Standard_B1ms
- sourceImageReference:
- - offer: debian-11
- publisher: Debian
- sku: 11-backports-gen2
- version: latest
- resourceGroupName:
-```
-
-### Create the composition object
-The _Composition_ combines all the managed resources into a single object.
-
-A
-{{}}Composition{{ hover>}} comes from the
-{{}}Crossplane{{ hover>}}
-API resources.
-
-Create any {{}}name{{ hover>}} for this _Composition_.
-
-```yaml {label="compName",copy-lines="none"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-metadata:
- name: crossplane-quickstart-vm-with-network
-```
-
-Add all the defined resources to the
-{{}}spec.resources{{ hover>}}
-section of the _Composition_.
-
-Give each resource a
-{{}}name{{ hover>}}
-and put the resource definition under the
-{{}}base{{ hover>}}
-key.
-
-Add your {{}}resourceGroupName{{< /hover >}}
-for each resource in the Composition.
-
-{{}}
-The contents of the
-{{}}base{{ hover>}} key
-doesn't include the `metadata` field from the managed resources.
-{{< /hint >}}
-
-```yaml {label="specResources",copy-lines="none"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-metadata:
- name: crossplane-quickstart-vm-with-network
-spec:
- resources:
- - name: quickstart-subnet
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: Subnet
- spec:
- forProvider:
- addressPrefixes:
- - 10.0.1.0/24
- virtualNetworkNameSelector:
- matchControllerRef: true
- resourceGroupName:
-# Removed for brevity
-```
-
-{{}}
-Crossplane provides the
-{{}}matchControllerRef{{}} value
-to automatically link resources created by the same _Composition_.
-{{}}
-
-_Compositions_ are a template for generating resources. A _composite
-resource_ actually creates the resources.
-
-A _Composition_ defines what _composite resources_ can use this
-template.
-
-_Compositions_ do this with the
-{{}}spec.compositeTypeRef{{ hover>}}
-definition.
-
-{{< hint "tip" >}}
-Crossplane recommends prefacing the `kind` with an `X` to show it's a Composition.
-{{< /hint >}}
-
-```yaml {label="compRef",copy-lines="none"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-metadata:
- name: crossplane-quickstart-vm-with-network
-spec:
- compositeTypeRef:
- apiVersion: custom-api.example.org/v1alpha1
- kind: XVirtualMachine
- resources:
- # Removed for Brevity
-```
-
-A _composite resource_ is actually a custom Kubernetes API type you define. The
-platform team controls the kind, API endpoint and version.
-
-
-
-With this {{}}spec.compositeTypeRef{{ hover>}}
-Crossplane only allows _composite resources_ from the API group
-{{}}custom-api.example.org{{ hover>}}
-that are of
-{{}}kind: XVirtualMachine{{ hover>}}
-to use this template to create resources.
-
-
-### Apply the composition
-Apply the full _Composition_ to your Kubernetes cluster.
-
-{{}}
-Add your {{}}resourceGroupName{{}} to
-each resource.
-{{< /hint >}}
-
-{{< editCode >}}
-```yaml {label="fullComp"}
-cat <$$
- size: Standard_B1ms
- sourceImageReference:
- - offer: debian-11
- publisher: Debian
- sku: 11-backports-gen2
- version: latest
- networkInterfaceIdsSelector:
- matchControllerRef: true
- - name: quickstart-nic
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: NetworkInterface
- spec:
- forProvider:
- ipConfiguration:
- - name: crossplane-quickstart-configuration
- privateIpAddressAllocation: Dynamic
- subnetIdSelector:
- matchControllerRef: true
- location: "Central US"
- resourceGroupName: $$$$
- - name: quickstart-subnet
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: Subnet
- spec:
- forProvider:
- addressPrefixes:
- - 10.0.1.0/24
- virtualNetworkNameSelector:
- matchControllerRef: true
- resourceGroupName: $$$$
- - name: quickstart-network
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: VirtualNetwork
- spec:
- forProvider:
- addressSpace:
- - 10.0.0.0/16
- location: "Central US"
- resourceGroupName: $$$$
-EOF
-```
-{{< /editCode >}}
-
-Confirm the _Composition_ exists with `kubectl get composition`
-
-```shell {copy-lines="1"}
-kubectl get composition
-NAME XR-KIND XR-APIVERSION AGE
-crossplane-quickstart-vm-with-network XVirtualMachine custom-api.example.org/v1alpha1 5s
-```
-
-Again, the _Composition_ is only a template. At this point, Crossplane hasn't
-created any resources inside of Azure.
-
-## Define a composite resource
-
-The _Composition_ that was just created limited which _composite resources_ can
-use that template.
-
-A _composite resource_ is a custom API defined by the platform teams.
-A _CompositeResourceDefinition_ defines the schema for a _composite resource_.
-
-
-A _CompositeResourceDefinition_ installs the custom API type into Kubernetes
-and defines what `spec` keys and values are valid when calling this new custom API.
-
-Before creating a _composite resource_ Crossplane requires a _CompositeResourceDefinition_.
-
-{{< hint "tip" >}}
-_CompositeResourceDefinitions_ are also called `XRDs` for short.
-{{< /hint >}}
-
-Just like a _Composition_ the
-{{}}CompositeResourceDefinition{{}}
-is part of the
-{{}}Crossplane{{}}
-API group.
-
-The _XRD_ {{}}name{{}} is the new
-API endpoint.
-
-{{< hint "tip" >}}
-Crossplane recommends using a plural name for the _XRD_
-{{}}name{{}}.
-{{< /hint >}}
-
-```yaml {label="xrdName",copy-lines="none"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-metadata:
- name: xvirtualmachines.custom-api.example.org
-```
-
-The _XRD's_
-{{}}spec{{}} defines the new custom
-API.
-
-### Define the API endpoint and kind
-First, define the new API
-{{}}group{{}}.
-Next, create the API {{}}kind{{}} and
-{{}}plural{{}}.
-
-```yaml {label="xrdGroup",copy-lines="none"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-metadata:
- name: xvirtualmachines.custom-api.example.org
-spec:
- group: custom-api.example.org
- names:
- kind: XVirtualMachine
- plural: xvirtualmachines
-```
-
-{{}}
-The _XRD_ {{}}group{{}} matches the _composition_ {{}}apiVersion{{}} and the
-_XRD_ {{}}kind{{}} matches the _composition_
-{{}}compositeTypeRef.kind{{}}.
-
-```yaml {label="noteComp",copy-lines="none"}
-kind: Composition
-# Removed for brevity
-spec:
- compositeTypeRef:
- apiVersion: custom-api.example.org/v1alpha1
- kind: XVirtualMachine
-```
-{{< /hint >}}
-
-### Set the API version
-In Kubernetes, all API endpoints have a version to show the stability of the API
-and track revisions.
-
-Apply a version to the _XRD_ with a
-{{}}versions.name{{}}.
-This matches the
-{{}}compositeTypeRef.apiVersion{{}}
-
-_XRDs_ require both
-{{}}versions.served{{}}
-and
-{{}}versions.referenceable{{}}.
-
-```yaml {label="xrdVersion",copy-lines="none"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-metadata:
- name: xvirtualmachines.custom-api.example.org
-spec:
- group: custom-api.example.org
- names:
- kind: XVirtualMachine
- plural: xvirtualmachines
- versions:
- - name: v1alpha1
- served: true
- referenceable: true
-```
-
-{{}}
-For more information on defining versions in Kubernetes read the
-[API versioning](https://kubernetes.io/docs/reference/using-api/#api-versioning) section of the Kubernetes documentation.
-{{< /hint >}}
-
-### Create the API schema
-With an API endpoint named, now define the API schema, or what's allowed
-inside the `spec` of the new Kubernetes object.
-
-{{< hint "note" >}}
-_XRDs_ follow the Kubernetes
-[_CustomResourceDefinition_ rules for schemas](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema).
-{{}}
-
-Place the API
-{{< hover label="xrdSchema" line="8" >}}schema{{}}
-under the
-{{< hover label="xrdSchema" line="7" >}}version.name{{}}
-
-The _XRD_ type defines the next lines. They're always the same.
-
-
-
-{{< hover label="xrdSchema" line="9" >}}openAPIV3Schema{{}} specifies
-how the schema gets validated.
-
-
-Next, the entire API is an
-{{< hover label="xrdSchema" line="10" >}}object{{}}
-with a
-{{< hover label="xrdSchema" line="11" >}}property{{}} of
-{{< hover label="xrdSchema" line="12" >}}spec{{}}.
-
-The
-{{< hover label="xrdSchema" line="12" >}}spec{{}} is also an
-{{< hover label="xrdSchema" line="13" >}}object{{}} with
-{{< hover label="xrdSchema" line="14" >}}properties{{}}.
-
-```yaml {label="xrdSchema",copy-lines="none"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-# Removed for brevity
-spec:
- # Removed for brevity
- versions:
- - name: v1alpha1
- schema:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
-```
-
-{{< hint "tip" >}}
-For more information on the values allowed in a _CompositeResourceDefinition_ view its schema with
-`kubectl explain xrd`
-{{< /hint >}}
-
-Now, define the custom API. Your custom API continues under the last
-{{}}properties{{}} definition in the
-previous example.
-
-This custom API has only one setting:
-
-* {{}}region{{}} - where to deploy
-the resources, a choice of "EU" or "US"
-
-Users can't change any other settings of the VM or its network.
-
-The{{}}region{{}}
-is a {{}}string{{}}
-and can match the regular expression that's
-{{}}oneOf{{}}
-{{}}EU{{}}
-or
-{{}}US{{}}.
-
-This API requires the setting
-{{}}region{{}}.
-
-
-```yaml {label="customAPI",copy-lines="none"}
-# Removed for brevity
-# schema.openAPIV3Schema.type.properties.spec
-properties:
- region:
- type: string
- oneOf:
- - pattern: '^EU$'
- - pattern: '^US$'
-required:
- - region
-```
-
-### Enable claims to the API
-Tell this _XRD_ to offer a _claim_ by defining the _claim_ API endpoint under
-the _XRD_ {{}}spec{{< /hover >}}.
-
-{{< hint "tip" >}}
-Crossplane recommends a _Claim_ {{}}kind{{ hover>}} match the _Composite Resource_ (XR)
-{{}}kind{{ hover>}},
-without the preceding `X`.
-{{< /hint >}}
-
-
-```yaml {label="XRDclaim",copy-lines="none"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-# Removed for brevity
-spec:
-# Removed for brevity
- names:
- kind: XVirtualMachine
- plural: xvirtualmachines
- claimNames:
- kind: VirtualMachine
- plural: virtualmachines
-```
-
-{{}}
-The [Claims](#create-a-claim) section later in this guide discusses _claims_.
-{{< /hint >}}
-
-### Apply the CompositeResourceDefinition
-Apply the complete _XRD_ to your Kubernetes cluster.
-
-
-```yaml
-cat <}}group{{}}
-becomes the _composite resource_
-{{}}apiVersion{{}}.
-
-The _XRD_ {{}}kind{{}}
-is the _composite resource_
-{{}}kind{{}}
-
-The _XRD_ API {{}}spec{{}} defines the
-_composite resource_ {{}}spec{{}}.
-
-The _XRD_ {{}}properties{{}} section
-defines the options for the _composite resource_
-{{}}spec{{}}.
-
-The one option is {{}}region{{}} and it
-can be either {{}}EU{{}} or
-{{}}US{{}}.
-
-This _composite resource_ uses
-{{}}region: US{{}}.
-
-### Apply the composite resource
-
-Apply the composite resource to the Kubernetes cluster.
-
-```yaml {label="xr"}
-cat <}}
-It may take up to 10 minutes for Azure to create the Virtual Machine resources.
-{{< /hint >}}
-
-```shell {copy-lines="1"}
-kubectl get xvirtualmachine
-NAME SYNCED READY COMPOSITION AGE
-my-composite-resource True True crossplane-quickstart-vm-with-network 5m2s
-```
-
-{{}}
-Use `kubectl get ` to view a specific `kind` of _composite resource_.
-View all _composite resources_ with `kubectl get composite`.
-{{< /hint >}}
-
-
-Both `SYNCED` and `READY` are `True` when Crossplane created the Azure
-resources.
-
-Now look at the `linuxvirtualmachine` and `networkinterface`
-_managed resources_ with
-`kubectl get linuxvirtualmachine` and `kubectl get networkinterface`.
-
-```shell {copy-lines="1"}
-kubectl get linuxvirtualmachine
-NAME READY SYNCED EXTERNAL-NAME AGE
-my-composite-resource-w564c True True my-composite-resource-w564c 8m33s
-```
-
-```shell {copy-lines="1"}
-kubectl get networkinterface
-NAME READY SYNCED EXTERNAL-NAME AGE
-my-composite-resource-72ft8 True True my-composite-resource-72ft8 8m54s
-```
-
-The _composite resource_ automatically generated the _managed resources_.
-
-Using `kubectl describe` on a _managed resource_ shows the `Owner References` is
-the _composite resource_.
-
-```yaml {copy-lines="1"}
- kubectl describe linuxvirtualmachine | grep "Owner References" -A5
- Owner References:
- API Version: custom-api.example.org/v1alpha1
- Block Owner Deletion: true
- Controller: true
- Kind: XVirtualMachine
- Name: my-composite-resource
-```
-
-Each _composite resource_ creates and owns a unique set of _managed resources_.
-If you create a second _composite resource_ Crossplane creates a new
-`LinuxVirtualMachine` and new networking resources.
-
-```yaml {label="xr"}
-cat <}}
-Delete a specific _composite resource_ with `kubectl delete ` or
-`kubectl delete composite`.
-{{< /hint >}}
-
-Delete the second composition
-```shell
-kubectl delete xvirtualmachine my-second-composite-resource
-```
-
-{{}}
-It may take up to five minutes before Crossplane finishes deleting resources.
-{{}}
-
-Now only one virtual machine and network interface exist.
-
-```shell {copy-lines="1"}
-kubectl get linuxvirtualmachines
-NAME READY SYNCED EXTERNAL-NAME AGE
-my-composite-resource-w564c True True my-composite-resource-w564c 28m
-```
-
-```shell {copy-lines="1"}
-kubectl get networkinterface
-NAME READY SYNCED EXTERNAL-NAME AGE
-my-composite-resource-72ft8 True True my-composite-resource-72ft8 29m
-```
-
-Delete the other _composite resource_ to remove the last `linuxvirtualmachines`
-and `networkinterface` _managed resources_.
-
-```shell
-kubectl delete xvirtualmachine my-composite-resource
-```
-
-_Composite resources_ are great for creating one or more related resources against
-a template, but all _composite resources_ exist at the Kubernetes "cluster
-level." There's no isolation between _composite resources_. Crossplane uses
-_Claims_ to create resources with namespace isolation.
-
-## Create a claim
-
-_Claims_, just like _composite resources_ use the custom API defined in the
-_XRD_. Unlike a _composite resource_, Crossplane can create _Claims_ in a
-namespace.
-
-### Create a new Kubernetes namespace
-Create a new namespace with `kubectl create namespace`.
-
-```shell
-kubectl create namespace test
-```
-
-Look at the _XRD_ to see the parameters for the _Claim_.
-A _Claim_ uses the same {{}}group{{}}
-a _composite resource_ uses but a different
-{{}}kind{{}}.
-
-```yaml {label="XRDclaim2",copy-lines="none"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-# Removed for brevity
-spec:
-# Removed for brevity
- group: custom-api.example.org
- claimNames:
- kind: VirtualMachine
- plural: virtualmachines
-```
-
-Like the _composite resource_, create a new object with the
-{{}}custom-api.example.org{{}} API
-endpoint.
-
-The _XRD_
-{{}}claimNames.kind{{}} defines the
-{{}}kind{{}}.
-
-The {{}}spec{{}} uses the same
-API options as the _composite resource_.
-
-### Apply the claim
-Apply the _claim_ to your Kubernetes cluster.
-
-```yaml {label="claim"}
-cat <}}
-View claims with `kubectl get ` or use `kubectl get claim` to view all
-_Claims_.
-{{}}
-
-```shell {copy-lines="1"}
-kubectl get virtualmachine -n test
-NAME SYNCED READY CONNECTION-SECRET AGE
-claimed-virtualmachine True True 3m40s
-```
-
-When Crossplane creates a _Claim_, a unique _composite resource_ is also
-created. View the new _composite resource_ with `kubectl get xvirtualmachine`.
-
-```shell {copy-lines="1"}
-kubectl get xvirtualmachine
-NAME SYNCED READY COMPOSITION AGE
-claimed-virtualmachine-cw6cv True True crossplane-quickstart-vm-with-network 3m57s
-```
-
-The _composite resource_ exists at the "cluster scope" while the _Claim_ exists
-at the "namespace scope."
-
-Create a second namespace and a second claim.
-
-```yaml
-kubectl create namespace test2
-cat <}}) of this guide covers _composition
-patches_ and making all this configuration portable in Crossplane _Packages_.
-
-## Next steps
-* **[Continue to part 3]({{< ref "provider-azure-part-3">}})** to learn
- about _patching_ resources and creating Crossplane _Packages_.
-* Explore Azure resources that Crossplane can configure in the
- [Provider CRD reference](https://marketplace.upbound.io/providers/upbound/provider-family-azure/).
-* Join the [Crossplane Slack](https://slack.crossplane.io/) and connect with Crossplane users and contributors.
\ No newline at end of file
diff --git a/content/v1.11/getting-started/provider-azure-part-3.md b/content/v1.11/getting-started/provider-azure-part-3.md
deleted file mode 100644
index b5583feda..000000000
--- a/content/v1.11/getting-started/provider-azure-part-3.md
+++ /dev/null
@@ -1,811 +0,0 @@
----
-title: Azure Quickstart Part 3
-weight: 120
-tocHidden: true
----
-
-{{< hint "important" >}}
-This guide is part 3 of a series.
-
-Follow **[part 1]({{][}})**
-to install Crossplane and connect your Kubernetes cluster to Azure.
-
-Follow **[part 2]({{][}})** to create a _composition_,
-_custom resource definition_ and a _claim_.
-{{< /hint >}}
-
-[Part 2]({{][}}) created a
-_CompositeResourceDefinition_ to define the schema of the custom API.
-Users create a _Claim_ to use the custom API and apply their options.
-Part 2 didn't show how the options set in a _Claim_ change or get
-applied to the associated _composite resources_.
-
-## Prerequisites
-* Complete quickstart [part 1]({{][}}) and [part 2]({{][}}) to install Crossplane and the quickstart
- configurations.
-
-{{}}
-1. Add the Crossplane Helm repository and install Crossplane
-```shell
-helm repo add \
-crossplane-stable https://charts.crossplane.io/stable
-helm repo update
-&&
-helm install crossplane \
-crossplane-stable/crossplane \
---namespace crossplane-system \
---create-namespace
-```
-
-2. When the Crossplane pods finish installing and are ready, apply the Azure
- Provider
-
-```yaml {label="provider",copy-lines="all"}
-cat <}}
-```console
-az ad sp create-for-rbac \
---sdk-auth \
---role Owner \
---scopes /subscriptions/$$$$
-```
-{{ editCode >}}
-
-4. Create a Kubernetes secret from the Azure JSON file.
-```shell {label="kube-create-secret",copy-lines="all"}
-kubectl create secret \
-generic azure-secret \
--n crossplane-system \
---from-file=creds=./azure-credentials.json
-```
-
-5. Create a _ProviderConfig_
-```yaml {label="providerconfig",copy-lines="all"}
-cat <}}
-Apply your
-{{}}resourceGroupName{{}} to each resource.
-{{< /hint >}}
-
-{{< editCode >}}
-```yaml {label="Composition"}
-cat <$$
- size: Standard_B1ms
- sourceImageReference:
- - offer: debian-11
- publisher: Debian
- sku: 11-backports-gen2
- version: latest
- networkInterfaceIdsSelector:
- matchControllerRef: true
- - name: quickstart-nic
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: NetworkInterface
- spec:
- forProvider:
- ipConfiguration:
- - name: crossplane-quickstart-configuration
- privateIpAddressAllocation: Dynamic
- subnetIdSelector:
- matchControllerRef: true
- location: "Central US"
- resourceGroupName: $$$$
- - name: quickstart-subnet
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: Subnet
- spec:
- forProvider:
- addressPrefixes:
- - 10.0.1.0/24
- virtualNetworkNameSelector:
- matchControllerRef: true
- resourceGroupName: $$$$
- - name: quickstart-network
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: VirtualNetwork
- spec:
- forProvider:
- addressSpace:
- - 10.0.0.0/16
- location: "Central US"
- resourceGroupName: $$$$
-EOF
-```
-{{< /editCode >}}
-
-7. Create a _CompositeResourceDefinition_
-```yaml
-cat <}}
-
-## Enable composition patches
-In a _Composition_ `patches` map fields in the custom API to fields inside the
-_managed resources_.
-
-The example _Composition_ has four _managed resources_. A {{}}LinuxVirtualMachine{{}},
-{{}}NetworkInterface{{}},
-{{}}Subnet{{}} and a
-{{}}VirtualNetwork{{}}.
-
-
-```yaml {label="compResources",copy-lines="none"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-# Removed for Brevity
-resources:
- - name: quickstart-vm
- base:
- apiVersion: compute.azure.upbound.io/v1beta1
- kind: LinuxVirtualMachine
- - name: quickstart-nic
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: NetworkInterface
- - name: quickstart-subnet
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: Subnet
- - name: quickstart-network
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: VirtualNetwork
-```
-
-The custom API defined a single option,
-{{}}region{{}}. A
-{{}}region{{}} can be either
-{{}}EU{{}} or
-{{}}US{{}}.
-
-
-```yaml {label="xrdSnip",copy-lines="none"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-# Removed for brevity
-spec:
- group: custom-api.example.org
- names:
- kind: XVirtualMachine
-# Removed for brevity
- spec:
- type: object
- properties:
- region:
- type: string
- oneOf:
- - pattern: '^EU$'
- - pattern: '^US$'
-```
-
-Creating a _composition_ `patch` allows Crossplane to update the settings of the
-_composite resource_. Patches apply to the individual _managed resources_
-inside the _Composition_.
-
-A {{}}patch{{}} has a
-{{}}fromField{{}} and a
-{{}}toField{{}} specifying which value
-_from_ the custom API should apply _to_ a field in the _managed resource_.
-Patches can create a
-{{}}transform{{}} to change the _from_
-field before it's applied.
-
-The transform
-{{}}type{{}} is what kind of change to
-make on the _from_ field. Types of changes could include appending a string,
-preforming a math operation or mapping one value to another.
-
-Applying a {{}}patch{{}} to the
-{{}}LinuxVirtualMachine{{}} uses the
-custom API
-{{}}region{{}} to use as the
-_managed resource_
-{{}}location{{}}.
-
-
-The custom API value "EU" is
-{{}}mapped{{}} to the value
-"Sweden Central"
-and "US" is {{}}mapped{{}} to the value
-"Central US."
-
-
-
-```yaml {label="patch",copy-lines="none"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-# Removed for Brevity
- resources:
- - name: quickstart-vm
- base:
- apiVersion: compute.azure.upbound.io/v1beta1
- kind: LinuxVirtualMachine
- spec:
- forProvider:
- location: "Central US"
- # Removed for Brevity
- patches:
- - fromFieldPath: "spec.region"
- toFieldPath: "spec.forProvider.location"
- transforms:
- - type: map
- map:
- EU: "Sweden Central"
- US: "Central US"
-```
-
-Patching is a powerful tool enabling simpler or abstracted APIs. A developer
-isn't required to know the specific Azure location names, only the abstracted
-option of "EU" or "US."
-
-
-### Apply the updated composition
-Apply the same `patch` to all other _managed resource_
-and apply the updated _Composition_.
-
-{{< hint "tip" >}}
-Update each `resourceGroupName` with your Azure Resource Group.
-{{< /hint >}}
-
-{{< editCode >}}
-```yaml
-cat <$$
- size: Standard_B1ms
- sourceImageReference:
- - offer: debian-11
- publisher: Debian
- sku: 11-backports-gen2
- version: latest
- networkInterfaceIdsSelector:
- matchControllerRef: true
- patches:
- - fromFieldPath: "spec.region"
- toFieldPath: "spec.forProvider.location"
- transforms:
- - type: map
- map:
- EU: "Sweden Central"
- US: "Central US"
- - name: quickstart-nic
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: NetworkInterface
- spec:
- forProvider:
- ipConfiguration:
- - name: crossplane-quickstart-configuration
- privateIpAddressAllocation: Dynamic
- subnetIdSelector:
- matchControllerRef: true
- location: "Central US"
- resourceGroupName: $$$$
- patches:
- - fromFieldPath: "spec.region"
- toFieldPath: "spec.forProvider.location"
- transforms:
- - type: map
- map:
- EU: "Sweden Central"
- US: "Central US"
- - name: quickstart-subnet
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: Subnet
- spec:
- forProvider:
- addressPrefixes:
- - 10.0.1.0/24
- virtualNetworkNameSelector:
- matchControllerRef: true
- resourceGroupName: $$$$
- patches:
- - fromFieldPath: "spec.region"
- toFieldPath: "spec.forProvider.location"
- transforms:
- - type: map
- map:
- EU: "Sweden Central"
- US: "Central US"
- - name: quickstart-network
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: VirtualNetwork
- spec:
- forProvider:
- addressSpace:
- - 10.0.0.0/16
- location: "Sweden Central"
- resourceGroupName: $$$$
- patches:
- - fromFieldPath: "spec.region"
- toFieldPath: "spec.forProvider.location"
- transforms:
- - type: map
- map:
- EU: "Sweden Central"
- US: "Central US"
-EOF
-```
-{{< /editCode >}}
-
-### Create a claim
-Create a new _claim_ and set the
-{{}}region{{}} to "EU."
-
-```yaml {label="claim"}
-cat <}}
-It may take up to 10 minutes for the Claim to be `READY`.
-{{< /hint >}}
-
-```shell {copy-lines="1"}
-kubectl get claim -n test
-NAME SYNCED READY CONNECTION-SECRET AGE
-claimed-eu-virtualmachine True True 6m2s
-```
-
-The claim reports `SYNCED` and `READY` as `True` after Crossplane creates
-all the _managed resources_.
-
-Describe the `LinuxVirtualMachine` resource to see the Azure location is `Sweden
-Central`.
-
-```shell {copy-lines="1"}
-kubectl describe linuxvirtualmachine | grep "At Provider\|Location"
- Location: Sweden Central
- At Provider:
- Location: swedencentral
-```
-
-
-Using {{}}region: "EU"{{}} patches the
-_composite resource_, updating the Azure location from `Central US` to
-`Sweden Central`.
-The developer creating the claim isn't required to know which specific Azure
-location or the location naming conventions. Using the abstract API options of
-"EU" or "US" the developer places their resources in the desired location.
-
-
-Deleting the claim removes the _managed resources_.
-
-{{}}
-The _managed resources_ take up to 5 minutes to delete.
-{{< /hint >}}
-
-```shell
-kubectl delete virtualmachine claimed-eu-virtualmachine -n test
-```
-
-## Create a Crossplane configuration package
-
-Crossplane _configuration packages_ allow users to combine their
-_CustomResourceDefinition_ and _Composition_ files into a single OCI image.
-
-{{< hint "note" >}}
-The [Open Container Initiative](https://opencontainers.org/faq/)
-defines the OCI image standard.
-An OCI images is a standard way to package data.
-{{< /hint >}}
-
-You can host configuration packages in image registries like
-[Docker Hub](https://hub.docker.com/) or the
-[Upbound Marketplace](https://marketplace.upbound.io/).
-
-Crossplane can download and install configuration packages into a Kubernetes
-cluster.
-
-Creating a configuration package makes your Crossplane custom APIs portable
-and versioned.
-
-Building and installing configuration packages requires an OCI image compatible
-tool.
-
-{{< hint "note" >}}
-You can use any software that builds OCI images. This includes
-[Docker](https://www.docker.com/) or
-[Upbound's Up CLI](https://github.com/upbound/up).
-{{< /hint >}}
-
-A configuration package includes at least three files:
-* `crossplane.yaml` defines the metadata of the package.
-* `definition.yaml` is the _CompositeResourceDefinition_ for the package.
-* `composition.yaml` is the _Composition_ template for the package.
-
-
-
-### Create a crossplane.yaml file
-
-Configuration packages describe their contents and requirements with a
-`crossplane.yaml` file.
-
-The `crossplane.yaml` file lists the required Crossplane _Providers_ and their
-compatible versions as well as the required Crossplane version.
-
-The Crossplane
-{{}}meta.pkg{{}} API defines the schema
-for a
-{{}}Configuration{{}}.
-
-Inside the {{}}spec{{}} define the
-required Crossplane
-{{}}version{{}}.
-
-The {{}}dependsOn{{}} section lists the
-dependencies for a package.
-
-This package lists the Upbound
-{{}}provider-azure{{}}
-version {{}}0.32.0{{}} or later as a
-dependency.
-
-{{}}
-Crossplane automatically installs dependencies. Dependencies can include other
-configuration packages.
-{{< /hint >}}
-
-Create a new directory and save the `crossplane.yaml` file.
-
-```yaml {label="xpyaml"}
-mkdir crossplane-azure-quickstart
-cat < crossplane-azure-quickstart/crossplane.yaml
-apiVersion: meta.pkg.crossplane.io/v1
-kind: Configuration
-metadata:
- name: crossplane-azure-quickstart
-spec:
- crossplane:
- version: ">=v1.11.0"
- dependsOn:
- - provider: xpkg.upbound.io/upbound/provider-azure
- version: ">=v0.32.0"
-EOF
-```
-
-
-
-### Create a definition.yaml file
-
-
-A configuration package requires a _CompositeResourceDefinition_ (XRD) to
-define the custom API.
-
-Save the _XRD_ as `definition.yaml` in the same directory as the
-`crossplane.yaml` file.
-
-```yaml
-cat < crossplane-azure-quickstart/definition.yaml
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-metadata:
- name: xvirtualmachines.custom-api.example.org
-spec:
- group: custom-api.example.org
- names:
- kind: XVirtualMachine
- plural: xvirtualmachines
- versions:
- - name: v1alpha1
- served: true
- referenceable: true
- schema:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- region:
- type: string
- oneOf:
- - pattern: '^EU$'
- - pattern: '^US$'
- required:
- - region
- claimNames:
- kind: VirtualMachine
- plural: virtualmachines
-EOF
-```
-
-
-
-### Create a composition.yaml file
-
-
-The _Composition_ template creates the _managed resources_ and allows _patches_
-to customize the _managed resources_.
-
-Copy the _Composition_ into the `composition.yaml` file in the same directory as
-`crossplane.yaml`.
-
-{{< hint "tip" >}}
-Update each `resourceGroupName` with your Azure Resource Group.
-{{< /hint >}}
-
-{{< editCode >}}
-```yaml
-cat < crossplane-azure-quickstart/composition.yaml
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-metadata:
- name: crossplane-quickstart-vm-with-network
-spec:
- compositeTypeRef:
- apiVersion: custom-api.example.org/v1alpha1
- kind: XVirtualMachine
- resources:
- - name: quickstart-vm
- base:
- apiVersion: compute.azure.upbound.io/v1beta1
- kind: LinuxVirtualMachine
- spec:
- forProvider:
- adminUsername: adminuser
- adminSshKey:
- - publicKey: ssh-rsa
- AAAAB3NzaC1yc2EAAAADAQABAAABAQC+wWK73dCr+jgQOAxNsHAnNNNMEMWOHYEccp6wJm2gotpr9katuF/ZAdou5AaW1C61slRkHRkpRRX9FA9CYBiitZgvCCz+3nWNN7l/Up54Zps/pHWGZLHNJZRYyAB6j5yVLMVHIHriY49d/GZTZVNB8GoJv9Gakwc/fuEZYYl4YDFiGMBP///TzlI4jhiJzjKnEvqPFki5p2ZRJqcbCiF4pJrxUQR/RXqVFQdbRLZgYfJ8xGB878RENq3yQ39d8dVOkq4edbkzwcUmwwwkYVPIoDGsYLaRHnG+To7FvMeyO7xDVQkMKzopTQV8AuKpyvpqu0a9pWOMaiCyDytO7GGN
- example@docs.crossplane.io
- username: adminuser
- location: "Central US"
- osDisk:
- - caching: ReadWrite
- storageAccountType: Standard_LRS
- resourceGroupName: $$$$
- size: Standard_B1ms
- sourceImageReference:
- - offer: debian-11
- publisher: Debian
- sku: 11-backports-gen2
- version: latest
- networkInterfaceIdsSelector:
- matchControllerRef: true
- patches:
- - fromFieldPath: "spec.region"
- toFieldPath: "spec.forProvider.location"
- transforms:
- - type: map
- map:
- EU: "Sweden Central"
- US: "Central US"
- - name: quickstart-nic
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: NetworkInterface
- spec:
- forProvider:
- ipConfiguration:
- - name: crossplane-quickstart-configuration
- privateIpAddressAllocation: Dynamic
- subnetIdSelector:
- matchControllerRef: true
- location: "Central US"
- resourceGroupName: $$$$
- patches:
- - fromFieldPath: "spec.region"
- toFieldPath: "spec.forProvider.location"
- transforms:
- - type: map
- map:
- EU: "Sweden Central"
- US: "Central US"
- - name: quickstart-subnet
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: Subnet
- spec:
- forProvider:
- addressPrefixes:
- - 10.0.1.0/24
- virtualNetworkNameSelector:
- matchControllerRef: true
- resourceGroupName: $$$$
- patches:
- - fromFieldPath: "spec.region"
- toFieldPath: "spec.forProvider.location"
- transforms:
- - type: map
- map:
- EU: "Sweden Central"
- US: "Central US"
- - name: quickstart-network
- base:
- apiVersion: network.azure.upbound.io/v1beta1
- kind: VirtualNetwork
- spec:
- forProvider:
- addressSpace:
- - 10.0.0.0/16
- location: "Sweden Central"
- resourceGroupName: $$$$
- patches:
- - fromFieldPath: "spec.region"
- toFieldPath: "spec.forProvider.location"
- transforms:
- - type: map
- map:
- EU: "Sweden Central"
- US: "Central US"
-EOF
-```
-{{< /editCode >}}
-
-### Install the Crossplane command-line
-To build a configuration package install the Crossplane Kubernetes command-line
-extension.
-
-```shell
-wget "https://raw.githubusercontent.com/crossplane/crossplane/master/install.sh"
-chmod +x install.sh
-./install.sh
-sudo mv crossplane /usr/local/bin
-```
-
-Follow the directions and move the `crossplane` binary to the correct
-directory.
-
-Verify the Crossplane command-line installed with `crossplane --help`
-
-```shell {copy-lines="1"}
-crossplane --help
-Usage: crossplane
-
-A command line tool for interacting with Crossplane.
-
-Flags:
- -h, --help Show context-sensitive help.
- -v, --version Print version and quit.
- --verbose Print verbose logging statements.
-# Ouptut removed for brevity
-```
-
-### Build a configuration package
-
-Use the `crossplane` CLI to create an `.xpkg` file containing the
-custom APIs and Crossplane configuration.
-
-```shell
-crossplane build configuration -f crossplane-azure-quickstart/ --name="crossplane-azure-quickstart"
-```
-
-Now an `.xpkg` OCI image is inside the `crossplane-azure-quickstart` directory.
-
-```shell {copy-lines="1"}
-ls crossplane-azure-quickstart/
-composition.yaml crossplane-azure-quickstart.xpkg crossplane.yaml definition.yaml
-```
-
-## Next steps
-* Explore Azure resources that Crossplane can configure in the [Provider CRD reference](https://marketplace.upbound.io/providers/upbound/provider-family-azure/).
-* Join the [Crossplane Slack](https://slack.crossplane.io/) and connect with Crossplane users and contributors.
-* Read more about [Crossplane concepts]({{][}})
\ No newline at end of file
diff --git a/content/v1.11/getting-started/provider-azure.md b/content/v1.11/getting-started/provider-azure.md
deleted file mode 100644
index 5a71015c5..000000000
--- a/content/v1.11/getting-started/provider-azure.md
+++ /dev/null
@@ -1,1250 +0,0 @@
----
-title: Azure Quickstart
-weight: 110
----
-
-Connect Crossplane to Azure to create and manage cloud resources from Kubernetes
-with the
-[Upbound Azure Provider](https://marketplace.upbound.io/providers/upbound/provider-azure).
-
-This guide is in three parts:
-* Part 1 walks through installing Crossplane, configuring the provider to
-authenticate to Azure and creating a _Managed Resource_ in Azure directly from
-your Kubernetes cluster. This shows Crossplane can communicate with Azure.
-* [Part 2]({{< ref "provider-azure-part-2" >}}) creates a
-_Composite Resource Definition_ (XRD), _Composite Resource_ (XR) and a _Claim_
-(XRC) to show how to create and use custom APIs.
-* [Part 3]({{< ref "provider-azure-part-3" >}}) demonstrates how to patch
-_Compositions_ with values used in a _Claim_ and how to build a Crossplane
-_Package_ to make a Crossplane platform portable and reusable.
-
-## Prerequisites
-This quickstart requires:
-* a Kubernetes cluster with at least 6 GB of RAM
-* permissions to create pods and secrets in the Kubernetes cluster
-* [Helm](https://helm.sh/) version `v3.2.0` or later
-* an Azure account with permissions to create an
- [Azure Virtual Machine](https://learn.microsoft.com/en-us/azure/virtual-machines/)
- and
- [Virtual Network](https://learn.microsoft.com/en-us/azure/virtual-network/)
-* an Azure account with permissions to create an Azure [service principal](https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals#service-principal-object) and an [Azure resource group](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal)
-
-## Install Crossplane
-
-Crossplane installs into an existing Kubernetes cluster.
-
-{{< hint type="tip" >}}
-If you don't have a Kubernetes cluster create one locally with
-[Kind](https://kind.sigs.k8s.io/).
-{{< /hint >}}
-
-
-### Install the Crossplane Helm chart
-
-Helm enables Crossplane to install all its Kubernetes components through a
-_Helm Chart_.
-
-Enable the Crossplane Helm Chart repository:
-
-```shell
-helm repo add \
-crossplane-stable https://charts.crossplane.io/stable && helm repo update
-```
-
-Run the Helm dry-run to see all the Crossplane components Helm installs.
-
-```shell
-helm install crossplane \
-crossplane-stable/crossplane \
---dry-run --debug \
---namespace crossplane-system \
---create-namespace
-```
-{{}}
-```shell
-helm install crossplane \
-crossplane-stable/crossplane \
---dry-run --debug \
---namespace crossplane-system \
---create-namespace
-install.go:193: [debug] Original chart version: ""
-install.go:210: [debug] CHART PATH: /home/vagrant/.cache/helm/repository/crossplane-1.10.1.tgz
-
-NAME: crossplane
-LAST DEPLOYED: Thu Jan 19 15:52:08 2023
-NAMESPACE: crossplane-system
-STATUS: pending-install
-REVISION: 1
-TEST SUITE: None
-USER-SUPPLIED VALUES:
-{}
-
-COMPUTED VALUES:
-affinity: {}
-args: {}
-configuration:
- packages: []
-customAnnotations: {}
-customLabels: {}
-deploymentStrategy: RollingUpdate
-extraEnvVarsCrossplane: {}
-extraEnvVarsRBACManager: {}
-image:
- pullPolicy: IfNotPresent
- repository: crossplane/crossplane
- tag: v1.10.1
-imagePullSecrets: {}
-leaderElection: true
-metrics:
- enabled: false
-nodeSelector: {}
-packageCache:
- medium: ""
- pvc: ""
- sizeLimit: 5Mi
-podSecurityContextCrossplane: {}
-podSecurityContextRBACManager: {}
-priorityClassName: ""
-provider:
- packages: []
-rbacManager:
- affinity: {}
- args: {}
- deploy: true
- leaderElection: true
- managementPolicy: All
- nodeSelector: {}
- replicas: 1
- skipAggregatedClusterRoles: false
- tolerations: {}
-registryCaBundleConfig: {}
-replicas: 1
-resourcesCrossplane:
- limits:
- cpu: 100m
- memory: 512Mi
- requests:
- cpu: 100m
- memory: 256Mi
-resourcesRBACManager:
- limits:
- cpu: 100m
- memory: 512Mi
- requests:
- cpu: 100m
- memory: 256Mi
-securityContextCrossplane:
- allowPrivilegeEscalation: false
- readOnlyRootFilesystem: true
- runAsGroup: 65532
- runAsUser: 65532
-securityContextRBACManager:
- allowPrivilegeEscalation: false
- readOnlyRootFilesystem: true
- runAsGroup: 65532
- runAsUser: 65532
-serviceAccount:
- customAnnotations: {}
-tolerations: {}
-webhooks:
- enabled: false
-
-HOOKS:
-MANIFEST:
----
-# Source: crossplane/templates/rbac-manager-serviceaccount.yaml
-apiVersion: v1
-kind: ServiceAccount
-metadata:
- name: rbac-manager
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
----
-# Source: crossplane/templates/serviceaccount.yaml
-apiVersion: v1
-kind: ServiceAccount
-metadata:
- name: crossplane
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
----
-# Source: crossplane/templates/clusterrole.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-aggregationRule:
- clusterRoleSelectors:
- - matchLabels:
- rbac.crossplane.io/aggregate-to-crossplane: "true"
----
-# Source: crossplane/templates/clusterrole.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:system:aggregate-to-crossplane
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
- crossplane.io/scope: "system"
- rbac.crossplane.io/aggregate-to-crossplane: "true"
-rules:
-- apiGroups:
- - ""
- resources:
- - events
- verbs:
- - create
- - update
- - patch
- - delete
-- apiGroups:
- - apiextensions.k8s.io
- resources:
- - customresourcedefinitions
- verbs:
- - "*"
-- apiGroups:
- - ""
- resources:
- - secrets
- verbs:
- - get
- - list
- - watch
- - create
- - update
- - patch
- - delete
-- apiGroups:
- - ""
- resources:
- - serviceaccounts
- - services
- verbs:
- - "*"
-- apiGroups:
- - apiextensions.crossplane.io
- - pkg.crossplane.io
- - secrets.crossplane.io
- resources:
- - "*"
- verbs:
- - "*"
-- apiGroups:
- - extensions
- - apps
- resources:
- - deployments
- verbs:
- - get
- - list
- - create
- - update
- - patch
- - delete
- - watch
-- apiGroups:
- - ""
- - coordination.k8s.io
- resources:
- - configmaps
- - leases
- verbs:
- - get
- - list
- - create
- - update
- - patch
- - watch
- - delete
-- apiGroups:
- - admissionregistration.k8s.io
- resources:
- - validatingwebhookconfigurations
- - mutatingwebhookconfigurations
- verbs:
- - get
- - list
- - create
- - update
- - patch
- - watch
- - delete
----
-# Source: crossplane/templates/rbac-manager-allowed-provider-permissions.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:allowed-provider-permissions
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-aggregationRule:
- clusterRoleSelectors:
- - matchLabels:
- rbac.crossplane.io/aggregate-to-allowed-provider-permissions: "true"
----
-# Source: crossplane/templates/rbac-manager-clusterrole.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane-rbac-manager
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-- apiGroups:
- - ""
- resources:
- - events
- verbs:
- - create
- - update
- - patch
- - delete
-- apiGroups:
- - ""
- resources:
- - namespaces
- - serviceaccounts
- verbs:
- - get
- - list
- - watch
-- apiGroups:
- - apiextensions.crossplane.io
- resources:
- - compositeresourcedefinitions
- verbs:
- - get
- - list
- - watch
-- apiGroups:
- - pkg.crossplane.io
- resources:
- - providerrevisions
- verbs:
- - get
- - list
- - watch
-- apiGroups:
- - apiextensions.k8s.io
- resources:
- - customresourcedefinitions
- verbs:
- - get
- - list
- - watch
-- apiGroups:
- - rbac.authorization.k8s.io
- resources:
- - clusterroles
- - roles
- verbs:
- - get
- - list
- - watch
- - create
- - update
- - patch
- # The RBAC manager may grant access it does not have.
- - escalate
-- apiGroups:
- - rbac.authorization.k8s.io
- resources:
- - clusterroles
- verbs:
- - bind
-- apiGroups:
- - rbac.authorization.k8s.io
- resources:
- - clusterrolebindings
- verbs:
- - "*"
-- apiGroups:
- - ""
- - coordination.k8s.io
- resources:
- - configmaps
- - leases
- verbs:
- - get
- - list
- - create
- - update
- - patch
- - watch
- - delete
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane-admin
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-aggregationRule:
- clusterRoleSelectors:
- - matchLabels:
- rbac.crossplane.io/aggregate-to-admin: "true"
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane-edit
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-aggregationRule:
- clusterRoleSelectors:
- - matchLabels:
- rbac.crossplane.io/aggregate-to-edit: "true"
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane-view
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-aggregationRule:
- clusterRoleSelectors:
- - matchLabels:
- rbac.crossplane.io/aggregate-to-view: "true"
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane-browse
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-aggregationRule:
- clusterRoleSelectors:
- - matchLabels:
- rbac.crossplane.io/aggregate-to-browse: "true"
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:aggregate-to-admin
- labels:
- rbac.crossplane.io/aggregate-to-admin: "true"
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-# Crossplane administrators have access to view events.
-- apiGroups: [""]
- resources: [events]
- verbs: [get, list, watch]
-# Crossplane administrators must create provider credential secrets, and may
-# need to read or otherwise interact with connection secrets. They may also need
-# to create or annotate namespaces.
-- apiGroups: [""]
- resources: [secrets, namespaces]
- verbs: ["*"]
-# Crossplane administrators have access to view the roles that they may be able
-# to grant to other subjects.
-- apiGroups: [rbac.authorization.k8s.io]
- resources: [clusterroles, roles]
- verbs: [get, list, watch]
-# Crossplane administrators have access to grant the access they have to other
-# subjects.
-- apiGroups: [rbac.authorization.k8s.io]
- resources: [clusterrolebindings, rolebindings]
- verbs: ["*"]
-# Crossplane administrators have full access to built in Crossplane types.
-- apiGroups:
- - apiextensions.crossplane.io
- resources: ["*"]
- verbs: ["*"]
-- apiGroups:
- - pkg.crossplane.io
- resources: [providers, configurations, providerrevisions, configurationrevisions]
- verbs: ["*"]
-# Crossplane administrators have access to view CRDs in order to debug XRDs.
-- apiGroups: [apiextensions.k8s.io]
- resources: [customresourcedefinitions]
- verbs: [get, list, watch]
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:aggregate-to-edit
- labels:
- rbac.crossplane.io/aggregate-to-edit: "true"
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-# Crossplane editors have access to view events.
-- apiGroups: [""]
- resources: [events]
- verbs: [get, list, watch]
-# Crossplane editors must create provider credential secrets, and may need to
-# read or otherwise interact with connection secrets.
-- apiGroups: [""]
- resources: [secrets]
- verbs: ["*"]
-# Crossplane editors may see which namespaces exist, but not edit them.
-- apiGroups: [""]
- resources: [namespaces]
- verbs: [get, list, watch]
-# Crossplane editors have full access to built in Crossplane types.
-- apiGroups:
- - apiextensions.crossplane.io
- resources: ["*"]
- verbs: ["*"]
-- apiGroups:
- - pkg.crossplane.io
- resources: [providers, configurations, providerrevisions, configurationrevisions]
- verbs: ["*"]
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:aggregate-to-view
- labels:
- rbac.crossplane.io/aggregate-to-view: "true"
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-# Crossplane viewers have access to view events.
-- apiGroups: [""]
- resources: [events]
- verbs: [get, list, watch]
-# Crossplane viewers may see which namespaces exist.
-- apiGroups: [""]
- resources: [namespaces]
- verbs: [get, list, watch]
-# Crossplane viewers have read-only access to built in Crossplane types.
-- apiGroups:
- - apiextensions.crossplane.io
- resources: ["*"]
- verbs: [get, list, watch]
-- apiGroups:
- - pkg.crossplane.io
- resources: [providers, configurations, providerrevisions, configurationrevisions]
- verbs: [get, list, watch]
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:aggregate-to-browse
- labels:
- rbac.crossplane.io/aggregate-to-browse: "true"
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-# Crossplane browsers have access to view events.
-- apiGroups: [""]
- resources: [events]
- verbs: [get, list, watch]
-# Crossplane browsers have read-only access to compositions and XRDs. This
-# allows them to discover and select an appropriate composition when creating a
-# resource claim.
-- apiGroups:
- - apiextensions.crossplane.io
- resources: ["*"]
- verbs: [get, list, watch]
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-# The below ClusterRoles are aggregated to the namespaced RBAC roles created by
-# the Crossplane RBAC manager when it is running in --manage=All mode.
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:aggregate-to-ns-admin
- labels:
- rbac.crossplane.io/aggregate-to-ns-admin: "true"
- rbac.crossplane.io/base-of-ns-admin: "true"
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-# Crossplane namespace admins have access to view events.
-- apiGroups: [""]
- resources: [events]
- verbs: [get, list, watch]
-# Crossplane namespace admins may need to read or otherwise interact with
-# resource claim connection secrets.
-- apiGroups: [""]
- resources: [secrets]
- verbs: ["*"]
-# Crossplane namespace admins have access to view the roles that they may be
-# able to grant to other subjects.
-- apiGroups: [rbac.authorization.k8s.io]
- resources: [roles]
- verbs: [get, list, watch]
-# Crossplane namespace admins have access to grant the access they have to other
-# subjects.
-- apiGroups: [rbac.authorization.k8s.io]
- resources: [rolebindings]
- verbs: ["*"]
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:aggregate-to-ns-edit
- labels:
- rbac.crossplane.io/aggregate-to-ns-edit: "true"
- rbac.crossplane.io/base-of-ns-edit: "true"
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-# Crossplane namespace editors have access to view events.
-- apiGroups: [""]
- resources: [events]
- verbs: [get, list, watch]
-# Crossplane namespace editors may need to read or otherwise interact with
-# resource claim connection secrets.
-- apiGroups: [""]
- resources: [secrets]
- verbs: ["*"]
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:aggregate-to-ns-view
- labels:
- rbac.crossplane.io/aggregate-to-ns-view: "true"
- rbac.crossplane.io/base-of-ns-view: "true"
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-# Crossplane namespace viewers have access to view events.
-- apiGroups: [""]
- resources: [events]
- verbs: [get, list, watch]
----
-# Source: crossplane/templates/clusterrolebinding.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
- name: crossplane
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-roleRef:
- apiGroup: rbac.authorization.k8s.io
- kind: ClusterRole
- name: crossplane
-subjects:
-- kind: ServiceAccount
- name: crossplane
- namespace: crossplane-system
----
-# Source: crossplane/templates/rbac-manager-clusterrolebinding.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
- name: crossplane-rbac-manager
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-roleRef:
- apiGroup: rbac.authorization.k8s.io
- kind: ClusterRole
- name: crossplane-rbac-manager
-subjects:
-- kind: ServiceAccount
- name: rbac-manager
- namespace: crossplane-system
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
- name: crossplane-admin
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-roleRef:
- apiGroup: rbac.authorization.k8s.io
- kind: ClusterRole
- name: crossplane-admin
-subjects:
-- apiGroup: rbac.authorization.k8s.io
- kind: Group
- name: crossplane:masters
----
-# Source: crossplane/templates/deployment.yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- name: crossplane
- labels:
- app: crossplane
- release: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-spec:
- replicas: 1
- selector:
- matchLabels:
- app: crossplane
- release: crossplane
- strategy:
- type: RollingUpdate
- template:
- metadata:
- labels:
- app: crossplane
- release: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
- spec:
- securityContext:
- {}
- serviceAccountName: crossplane
- initContainers:
- - image: crossplane/crossplane:v1.10.1
- args:
- - core
- - init
- imagePullPolicy: IfNotPresent
- name: crossplane-init
- resources:
- limits:
- cpu: 100m
- memory: 512Mi
- requests:
- cpu: 100m
- memory: 256Mi
- securityContext:
- allowPrivilegeEscalation: false
- readOnlyRootFilesystem: true
- runAsGroup: 65532
- runAsUser: 65532
- env:
- - name: POD_NAMESPACE
- valueFrom:
- fieldRef:
- fieldPath: metadata.namespace
- - name: POD_SERVICE_ACCOUNT
- valueFrom:
- fieldRef:
- fieldPath: spec.serviceAccountName
- containers:
- - image: crossplane/crossplane:v1.10.1
- args:
- - core
- - start
- imagePullPolicy: IfNotPresent
- name: crossplane
- resources:
- limits:
- cpu: 100m
- memory: 512Mi
- requests:
- cpu: 100m
- memory: 256Mi
- securityContext:
- allowPrivilegeEscalation: false
- readOnlyRootFilesystem: true
- runAsGroup: 65532
- runAsUser: 65532
- env:
- - name: POD_NAMESPACE
- valueFrom:
- fieldRef:
- fieldPath: metadata.namespace
- - name: LEADER_ELECTION
- value: "true"
- volumeMounts:
- - mountPath: /cache
- name: package-cache
- volumes:
- - name: package-cache
- emptyDir:
- medium:
- sizeLimit: 5Mi
----
-# Source: crossplane/templates/rbac-manager-deployment.yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- name: crossplane-rbac-manager
- labels:
- app: crossplane-rbac-manager
- release: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-spec:
- replicas: 1
- selector:
- matchLabels:
- app: crossplane-rbac-manager
- release: crossplane
- strategy:
- type: RollingUpdate
- template:
- metadata:
- labels:
- app: crossplane-rbac-manager
- release: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
- spec:
- securityContext:
- {}
- serviceAccountName: rbac-manager
- initContainers:
- - image: crossplane/crossplane:v1.10.1
- args:
- - rbac
- - init
- imagePullPolicy: IfNotPresent
- name: crossplane-init
- resources:
- limits:
- cpu: 100m
- memory: 512Mi
- requests:
- cpu: 100m
- memory: 256Mi
- securityContext:
- allowPrivilegeEscalation: false
- readOnlyRootFilesystem: true
- runAsGroup: 65532
- runAsUser: 65532
- containers:
- - image: crossplane/crossplane:v1.10.1
- args:
- - rbac
- - start
- - --manage=All
- - --provider-clusterrole=crossplane:allowed-provider-permissions
- imagePullPolicy: IfNotPresent
- name: crossplane
- resources:
- limits:
- cpu: 100m
- memory: 512Mi
- requests:
- cpu: 100m
- memory: 256Mi
- securityContext:
- allowPrivilegeEscalation: false
- readOnlyRootFilesystem: true
- runAsGroup: 65532
- runAsUser: 65532
- env:
- - name: LEADER_ELECTION
- value: "true"
-
-NOTES:
-Release: crossplane
-
-Chart Name: crossplane
-Chart Description: Crossplane is an open source Kubernetes add-on that enables platform teams to assemble infrastructure from multiple vendors, and expose higher level self-service APIs for application teams to consume.
-Chart Version: 1.10.1
-Chart Application Version: 1.10.1
-
-Kube Version: v1.24.9
-```
-{{< /expand >}}
-
-Install the Crossplane components using `helm install`.
-
-```shell
-helm install crossplane \
-crossplane-stable/crossplane \
---namespace crossplane-system \
---create-namespace
-```
-
-Verify Crossplane installed with `kubectl get pods`.
-
-```shell {copy-lines="1"}
-kubectl get pods -n crossplane-system
-NAME READY STATUS RESTARTS AGE
-crossplane-d4cd8d784-ldcgb 1/1 Running 0 54s
-crossplane-rbac-manager-84769b574-6mw6f 1/1 Running 0 54s
-```
-
-Installing Crossplane creates new Kubernetes API end-points. Look at the new API
-end-points with `kubectl api-resources | grep crossplane`.
-
-```shell {label="grep",copy-lines="1"}
-kubectl api-resources | grep crossplane
-compositeresourcedefinitions xrd,xrds apiextensions.crossplane.io/v1 false CompositeResourceDefinition
-compositionrevisions apiextensions.crossplane.io/v1alpha1 false CompositionRevision
-compositions apiextensions.crossplane.io/v1 false Composition
-configurationrevisions pkg.crossplane.io/v1 false ConfigurationRevision
-configurations pkg.crossplane.io/v1 false Configuration
-controllerconfigs pkg.crossplane.io/v1alpha1 false ControllerConfig
-locks pkg.crossplane.io/v1beta1 false Lock
-providerrevisions pkg.crossplane.io/v1 false ProviderRevision
-providers pkg.crossplane.io/v1 false Provider
-storeconfigs secrets.crossplane.io/v1alpha1 false StoreConfig
-```
-
-## Install the Azure provider
-
-Install the provider into the Kubernetes cluster with a Kubernetes configuration
-file.
-
-```yaml {label="provider",copy-lines="all"}
-cat <}}Provider{{]}}
-Custom Resource Definitions tells Kubernetes how to
-connect to the provider.
-
-Verify the provider installed with `kubectl get providers`.
-
-{{< hint type="note" >}}
-It may take up to five minutes for the provider to list `HEALTHY` as `True`.
-{{< /hint >}}
-
-```shell {copy-lines="1"}
-kubectl get providers
-NAME INSTALLED HEALTHY PACKAGE AGE
-upbound-provider-azure True True xpkg.upbound.io/upbound/provider-azure:v0.32.0 22m
-```
-
-A provider installs their own Kubernetes _Custom Resource Definitions_ (CRDs).
-These CRDs allow you to create Azure resources directly inside Kubernetes.
-
-You can view the new CRDs with `kubectl get crds`. Every CRD maps to a unique
-Azure service Crossplane can provision and manage.
-
-
-{{< hint type="tip" >}}
-See details about all the supported CRDs in the
-[Upbound Marketplace](https://marketplace.upbound.io/providers/upbound/provider-family-azure/).
-{{< /hint >}}
-
-## Create a Kubernetes secret for Azure
-The provider requires credentials to create and manage Azure resources.
-Providers use a Kubernetes _Secret_ to connect the credentials to the provider.
-
-This guide generates an Azure service principal JSON file and saves it as a
-Kubernetes _Secret_.
-
-{{< hint type="note" >}}
-Other authentication methods exist and are beyond the scope of this guide. The
-[Provider documentation](https://github.com/upbound/provider-azure/blob/main/AUTHENTICATION.md)
-contains information on alternative authentication methods.
-{{< /hint >}}
-
-### Install the Azure command-line
-Generating an [authentication file](https://docs.microsoft.com/en-us/azure/developer/go/azure-sdk-authorization#use-file-based-authentication) requires the Azure command-line.
-Follow the documentation from Microsoft to [Download and install the Azure command-line](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli).
-
-Log in to the Azure command-line.
-
-```command
-az login
-```
-### Create an Azure service principal
-Follow the Azure documentation to [find your Subscription ID](https://docs.microsoft.com/en-us/azure/azure-portal/get-subscription-tenant-id) from the Azure Portal.
-
-Using the Azure command-line and provide your Subscription ID create a service principal and authentication file.
-
-{{< editCode >}}
-```console {copy-lines="all"}
-az ad sp create-for-rbac \
---sdk-auth \
---role Owner \
---scopes /subscriptions/$$$$
-```
-{{< /editCode >}}
-
-Save your Azure JSON output as `azure-credentials.json`.
-
-{{< hint type="note" >}}
-The Azure Provider
-[Authentication documentation](https://github.com/upbound/provider-azure/blob/main/AUTHENTICATION.md)
-describes other authentication methods.
-{{< /hint >}}
-
-### Create a Kubernetes secret with the Azure credentials
-A Kubernetes generic secret has a name and contents. Use {{< hover label="kube-create-secret" line="1">}}kubectl create secret{{< /hover >}} to generate the secret object named {{< hover label="kube-create-secret" line="2">}}azure-secret{{< /hover >}} in the {{< hover label="kube-create-secret" line="3">}}crossplane-system{{ hover >}} namespace.
-
-
-
-Use the {{< hover label="kube-create-secret" line="4">}}--from-file={{}} argument to set the value to the contents of the {{< hover label="kube-create-secret" line="4">}}azure-credentials.json{{< /hover >}} file.
-
-```shell {label="kube-create-secret",copy-lines="all"}
-kubectl create secret \
-generic azure-secret \
--n crossplane-system \
---from-file=creds=./azure-credentials.json
-```
-
-View the secret with `kubectl describe secret`
-
-{{< hint type="note" >}}
-The size may be larger if there are extra blank spaces in your text file.
-{{< /hint >}}
-
-```shell {copy-lines="1"}
-kubectl describe secret azure-secret -n crossplane-system
-Name: azure-secret
-Namespace: crossplane-system
-Labels:
-Annotations:
-
-Type: Opaque
-
-Data
-====
-creds: 629 bytes
-```
-
-## Create a ProviderConfig
-A `ProviderConfig` customizes the settings of the Azure Provider.
-
-Apply the {{< hover label="providerconfig" line="5">}}ProviderConfig{{ hover >}} with the command:
-```yaml {label="providerconfig",copy-lines="all"}
-cat <}}secretRef{{ hover>}}.
-
-The {{< hover label="providerconfig" line="11">}}spec.credentials.secretRef.name{{< /hover >}} value is the name of the Kubernetes secret containing the Azure credentials in the {{< hover label="providerconfig" line="10">}}spec.credentials.secretRef.namespace{{< /hover >}}.
-
-
-## Create a managed resource
-A _managed resource_ is anything Crossplane creates and manages outside of the
-Kubernetes cluster. This example creates an Azure Virtual Network with
-Crossplane. The Virtual Network is a _managed resource_.
-
-{{< hint type="note" >}}
-Add your Azure Resource Group name. Follow the Azure documentation to
-[create a resource group](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal)
-if you don't have one.
-{{< /hint >}}
-
-{{< editCode >}}
-```yaml {label="xr"}
-cat <}}
-
-The {{< hover label="xr" line="2">}}apiVersion{{< /hover >}} and
-{{< hover label="xr" line="3">}}kind{{}} are from the provider's CRDs.
-
-The {{< hover label="xr" line="10">}}spec.forProvider.location{{< /hover >}}
-tells Azure which location to use when deploying the resource.
-
-Use `kubectl get virtualnetwork.network` to verify Crossplane created the
-Azure Virtual Network.
-
-{{< hint type="tip" >}}
-Crossplane created the virtual network when the values `READY` and `SYNCED` are `True`.
-This may take up to 5 minutes.
-{{< /hint >}}
-
-```shell {copy-lines="1"}
-kubectl get virtualnetwork.network
-NAME READY SYNCED EXTERNAL-NAME AGE
-crossplane-quickstart-network True True crossplane-quickstart-network 10m
-```
-
-## Delete the managed resource
-Before shutting down your Kubernetes cluster, delete the virtual network just
-created.
-
-Use `kubectl delete virtualnetwork.network` to delete the virtual network.
-
-
-```shell {copy-lines="1"}
-kubectl delete virtualnetwork.network crossplane-quickstart-network
-virtualnetwork.network.azure.upbound.io "crossplane-quickstart-network" deleted
-```
-
-## Next steps
-* **[Continue to part 2]({{< ref "provider-azure-part-2">}})** to create a
- Crossplane _Composite Resource_ and _Claim_.
-* Explore Azure resources that Crossplane can configure in the
- [Provider CRD reference](https://marketplace.upbound.io/providers/upbound/provider-family-azure/).
-* Join the [Crossplane Slack](https://slack.crossplane.io/) and connect with
- Crossplane users and contributors.
\ No newline at end of file
diff --git a/content/v1.11/getting-started/provider-gcp-part-2.md b/content/v1.11/getting-started/provider-gcp-part-2.md
deleted file mode 100644
index bdcfedd43..000000000
--- a/content/v1.11/getting-started/provider-gcp-part-2.md
+++ /dev/null
@@ -1,967 +0,0 @@
----
-title: GCP Quickstart Part 2
-weight: 120
-tocHidden: true
----
-
-{{< hint "important" >}}
-This guide is part 2 of a series. Follow **[part 1]({{[}})**
-to install Crossplane and connect your Kubernetes cluster to GCP.
-
-**[Part 3]({{][}})** covers patching
-_composite resources_ and using Crossplane _packages_.
-{{< /hint >}}
-
-This section creates a _[Composition](#create-a-composition)_,
-_[Composite Resource Definition](#define-a-composite-resource)_ and a
-_[Claim](#create-a-claim)_
-to create a custom Kubernetes API to create GCP resources. This custom API is a
-_Composite Resource_ (XR) API.
-
-## Prerequisites
-* Complete [quickstart part 1]({{][}}) connecting Kubernetes
- to GCP.
-* a GCP account with permissions to create a GCP
- [storage bucket](https://cloud.google.com/storage) and a
- [Pub/Sub topic](https://cloud.google.com/pubsub).
-
-{{}}
-1. Add the Crossplane Helm repository and install Crossplane.
-```shell
-helm repo add \
-crossplane-stable https://charts.crossplane.io/stable
-helm repo update
-&&
-helm install crossplane \
-crossplane-stable/crossplane \
---namespace crossplane-system \
---create-namespace
-```
-
-2. When the Crossplane pods finish installing and are ready, apply the GCP Provider.
-
-```yaml {label="provider",copy-lines="all"}
-cat <}}
-The
-[GCP documentation](https://cloud.google.com/iam/docs/creating-managing-service-account-keys)
-provides information on how to generate a service account JSON file.
-{{< /hint >}}
-
-4. Create a Kubernetes secret from the GCP JSON file
-```shell {label="kube-create-secret",copy-lines="all"}
-kubectl create secret \
-generic gcp-secret \
--n crossplane-system \
---from-file=creds=./gcp-credentials.json
-```
-
-5. Create a _ProviderConfig_
-Include your
-{{< hover label="providerconfig" line="7" >}}GCP project ID{{< /hover >}} in the
-_ProviderConfig_ settings.
-
-{{< hint type="warning" >}}
-Find your GCP project ID from the `project_id` field of the
-`gcp-credentials.json` file.
-{{< /hint >}}
-
-{{< editCode >}}
-```yaml {label="providerconfig",copy-lines="all"}
-cat <$@
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: gcp-secret
- key: creds
-EOF
-```
-{{< /editCode >}}
-
-{{}}
-
-## Create a composition
-[Part 1]({{][}}) created a single _managed resource_.
-A _Composition_ is a template to create one or more _managed resources_ at the
-same time.
-
-This sample _composition_ creates a Pub/Sub instance and associated GCP storage
-bucket.
-
-{{< hint "note" >}}
-This example comes from part of the GCP
-[Stream messages from Pub/Sub by using Dataflow](https://cloud.google.com/pubsub/docs/stream-messages-dataflow)
-guide.
-{{< /hint >}}
-
-To create a _composition_, first define each individual managed resource.
-
-### Create a storage bucket object
-Define a `bucket` resource using the configuration from the previous section:
-
-{{< hint "note" >}}
-Don't apply this configuration. This YAML is part of a larger
-definition.
-{{< /hint >}}
-
-```yaml
-apiVersion: storage.gcp.upbound.io/v1beta1
-kind: Bucket
-metadata:
- name: crossplane-quickstart-bucket
-spec:
- forProvider:
- location: US
- providerConfigRef:
- name: default
-```
-
-### Create a Pub/Sub topic resource
-Next, define a Pub/Sub `topic` resource.
-
-{{< hint "tip" >}}
-The [Upbound Marketplace](https://marketplace.upbound.io/) provides
-[schema documentation](https://marketplace.upbound.io/providers/upbound/provider-gcp/v0.28.0/resources/pubsub.gcp.upbound.io/Topic/v1beta1)
-for a `topic` resource.
-{{< /hint >}}
-
-The _GCP Provider_ defines the
-{{}}apiVersion{{}}
-and
-{{}}kind{{}}.
-
-A Pub/Sub topic doesn't have requirements but using
-{{}}messageStoragePolicy.allowedPersistenceRegions{{< /hover >}}
-can keep messages stored in the same location as the storage bucket.
-
-```yaml {label="topicMR"}
-apiVersion: pubsub.gcp.upbound.io/v1beta1
-kind: Topic
-metadata:
- name: crossplane-quickstart-topic
-spec:
- forProvider:
- messageStoragePolicy:
- - allowedPersistenceRegions:
- - "us-central1"
-```
-
-{{< hint "note" >}}
-Pub/Sub topic specifics are beyond the scope of this guide. Read the GCP
-[Pub/Sub API reference](https://cloud.google.com/compute/docs/apis)
-for more information.
-{{]}}
-
-### Create the composition object
-The _composition_ combines the two resource definitions.
-
-A
-{{}}Composition{{ hover>}} comes from the
-{{}}Crossplane{{ hover>}}
-API resources.
-
-Create any {{}}name{{ hover>}} for this _composition_.
-
-```yaml {label="compName"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-metadata:
- name: topic-with-bucket
-```
-
-Add the resources to the
-{{}}spec.resources{{ hover>}}
-section of the _composition_.
-
-Give each resource a
-{{}}name{{ hover>}}
-and put the resource definition under the
-{{}}base{{ hover>}}
-key.
-
-{{< hint "note" >}}
-Don't include resource `metadata` under the
-{{}}base{{ hover>}} key.
-{{< /hint >}}
-
-```yaml {label="specResources"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-metadata:
- name: topic-with-bucket
-spec:
- resources:
- - name: crossplane-quickstart-bucket
- base:
- apiVersion: storage.gcp.upbound.io/v1beta1
- kind: Bucket
- spec:
- forProvider:
- location: US
- - name: crossplane-quickstart-topic
- base:
- apiVersion: pubsub.gcp.upbound.io/v1beta1
- kind: Topic
- spec:
- forProvider:
- messageStoragePolicy:
- - allowedPersistenceRegions:
- - "us-central1"
-```
-
-_Compositions_ are a template for generating resources. A
-_composite resource_ actually creates the resources.
-
-A _composition_ defines which _composite resources_ can use this
-template.
-
-_Compositions_ do this with the
-{{}}spec.compositeTypeRef{{ hover>}}
-definition.
-
-{{< hint "tip" >}}
-Crossplane recommends prefacing the `kind` with an `X` to show it's a
-Composition.
-{{< /hint >}}
-
-```yaml {label="compRef"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-metadata:
- name: topic-with-bucket
-spec:
- compositeTypeRef:
- apiVersion: custom-api.example.org/v1alpha1
- kind: XTopicBucket
- resources:
- # Removed for Brevity
-```
-
-A _composite resource_ is actually a custom Kubernetes API type you define. The
-platform team controls the kind, API endpoint and version.
-
-
-
-With this {{}}spec.compositeTypeRef{{ hover>}}
-Crossplane allows _composite resources_ from the API group
-{{}}custom-api.example.org{{ hover>}}
-that are of
-{{}}kind: XTopicBucket{{ hover>}}
-to use this template to create resources. No other API group or kind can use
-this template.
-
-
-### Apply the composition
-Apply the full _Composition_ to your Kubernetes cluster.
-
-```yaml {copy-lines="all"}
-cat <}}
-_Composite resource definitions_ are also called `XRDs` for short.
-{{< /hint >}}
-
-Just like a _composition_ the
-{{}}composite resource definition{{}}
-is part of the
-{{}}Crossplane{{}}
-API group.
-
-The _XRD_ {{}}name{{}} is the new
-API endpoint.
-
-{{< hint "tip" >}}
-Crossplane recommends using a plural name for the _XRD_
-{{}}name{{}}.
-{{< /hint >}}
-
-```yaml {label="xrdName"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-metadata:
- name: xtopicbuckets.custom-api.example.org
-```
-
-The _XRD's_
-{{}}spec{{}} defines the new custom
-API.
-
-### Define the API endpoint and kind
-First, define the new API
-{{}}group{{}}.
-Next, create the API {{}}kind{{}} and
-{{}}plural{{}}.
-
-```yaml {label="xrdGroup"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-metadata:
- name: xtopicbuckets.custom-api.example.org
-spec:
- group: custom-api.example.org
- names:
- kind: XTopicBucket
- plural: xtopicbuckets
-```
-
-{{}}
-The _XRD_ {{}}group{{}} matches the _composition_ {{}}apiVersion{{}} and the
-_XRD_ {{}}kind{{}} matches the _composition_
-{{}}compositeTypeRef.kind{{}}.
-
-```yaml {label="noteComp"}
-kind: Composition
-# Removed for brevity
-spec:
- compositeTypeRef:
- apiVersion: custom-api.example.org/v1alpha1
- kind: XTopicBucket
-```
-{{< /hint >}}
-
-### Set the API version
-In Kubernetes, all API endpoints have a version to show the stability of the API
-and track revisions.
-
-Apply a version to the _XRD_ with a
-{{}}versions.name{{}}.
-This matches the
-{{}}compositeTypeRef.apiVersion{{}}
-
-_XRDs_ require both
-{{}}versions.served{{}}
-and
-{{}}versions.referenceable{{}}.
-
-```yaml {label="xrdVersion"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-metadata:
- name: xtopicbuckets.custom-api.example.org
-spec:
- group: custom-api.example.org
- names:
- kind: XTopicBucket
- plural: xtopicbuckets
- versions:
- - name: v1alpha1
- served: true
- referenceable: true
-```
-
-{{}}
-For more information on defining versions in Kubernetes read the
-[API versioning](https://kubernetes.io/docs/reference/using-api/#api-versioning)
-section of the Kubernetes documentation.
-{{< /hint >}}
-
-### Create the API schema
-With an API endpoint named, now define the API schema, or what's allowed
-inside the `spec` of the new Kubernetes object.
-
-{{< hint "note" >}}
-_XRDs_ follow the Kubernetes
-[_custom resource definition_ rules for schemas](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema).
-{{}}
-
-Place the API
-{{< hover label="xrdSchema" line="8" >}}schema{{}}
-under the
-{{< hover label="xrdSchema" line="7" >}}version.name{{}}
-
-The _XRD_ type defines the next lines. They're always the same.
-
-
-
-{{< hover label="xrdSchema" line="9" >}}openAPIV3Schema{{}} specifies
-how the schema gets validated.
-
-
-Next, the entire API is an
-{{< hover label="xrdSchema" line="10" >}}object{{}}
-with a
-{{< hover label="xrdSchema" line="11" >}}property{{}} of
-{{< hover label="xrdSchema" line="12" >}}spec{{}}.
-
-The
-{{< hover label="xrdSchema" line="12" >}}spec{{}} is also an
-{{< hover label="xrdSchema" line="13" >}}object{{}} with
-{{< hover label="xrdSchema" line="14" >}}properties{{}}.
-
-```yaml {label="xrdSchema"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-# Removed for brevity
-spec:
- # Removed for brevity
- versions:
- - name: v1alpha1
- schema:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
-```
-
-{{< hint "tip" >}}
-For more information on the values allowed in a _composite resource definition_ view its schema with
-`kubectl explain xrd`
-{{< /hint >}}
-
-Now, define the custom API. Your custom API continues under the last
-{{}}properties{{}} definition in the
-previous example.
-
-This custom API has one setting:
-
-* {{}}location{{}} - where to deploy
-the resources, a choice of "EU" or "US."
-
-
-Users can't change any other settings of the storage bucket or Pub/Sub topic.
-
-The{{}}location{{}}
-is a {{}}string{{}}
-and matches the regular expression that's
-{{}}oneOf{{}}
-{{}}EU{{}}
-or
-{{}}US{{}}.
-
-This API requires the setting
-{{}}location{{}}.
-
-
-```yaml {label="customAPI"}
-# Removed for brevity
-# schema.openAPIV3Schema.type.properties.spec
-properties:
- location:
- type: string
- oneOf:
- - pattern: '^EU$'
- - pattern: '^US$'
-required:
- - location
-```
-
-### Enable claims to the API
-Tell this _XRD_ to offer a _claim_ by defining the _claim_ API endpoint under
-the _XRD_ {{}}spec{{< /hover >}}.
-
-{{< hint "tip" >}}
-Crossplane recommends a _Claim_
-{{}}kind{{}} match the
-_Composite Resource Definition_ (XRD)
-{{}}kind{{ hover>}},
-without the preceding `X`.
-{{< /hint >}}
-
-
-```yaml {label="XRDclaim"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-# Removed for brevity
-spec:
-# Removed for brevity
- names:
- kind: XTopicBucket
- plural: xtopicbuckets
- claimNames:
- kind: TopicBucket
- plural: topicbuckets
-```
-
-{{}}
-The [Claims](#create-a-claim) section later in this guide discusses _claims_.
-{{< /hint >}}
-
-### Apply the composite resource definition
-Apply the complete _XRD_ to your Kubernetes cluster.
-
-
-```yaml {copy-lines="all"}
-cat <}}group{{}}
-becomes the _composite resource_
-{{}}apiVersion{{}}.
-
-The _XRD_ {{}}kind{{}}
-is the _composite resource_
-{{}}kind{{}}
-
-The _XRD_ API {{}}spec{{}} defines the
-_composite resource_ {{}}spec{{}}.
-
-The _XRD_ {{}}properties{{}} section
-defines the options for the _composite resource_
-{{}}spec{{}}.
-
-The one option is {{}}location{{}}
-and it can be either {{}}EU{{}} or
-{{}}US{{}}.
-
-This _composite resource_ uses
-{{}}location: US{{}}.
-
-### Apply the composite resource
-
-Apply the composite resource to the Kubernetes cluster.
-
-```yaml {label="xr", copy-lines="all"}
-cat <}}
-Use `kubectl get ` to view a specific `kind` of _composite resource_.
-View all _composite resources_ with `kubectl get composite`.
-{{< /hint >}}
-
-```shell {copy-lines="1"}
-kubectl get XTopicBucket
-NAME SYNCED READY COMPOSITION AGE
-my-composite-resource True True topic-with-bucket 2m3s
-```
-
-Both `SYNCED` and `READY` are `True` when Crossplane created the GCP resources.
-
-Now look at the GCP storage `bucket` and Pub/Sub `topic` _managed resources_
-with `kubectl get bucket` and `kubectl get topic`.
-
-```shell {copy-lines="1"}
-kubectl get bucket
-NAME READY SYNCED EXTERNAL-NAME AGE
-my-composite-resource-m6lbx True True my-composite-resource-m6lbx 4m34s
-```
-
-```shell {copy-lines="1"}
-kubectl get topics
-NAME READY SYNCED EXTERNAL-NAME AGE
-my-composite-resource-88vzp True True my-composite-resource-88vzp 4m48s
-```
-
-The _composite resource_ automatically generated both _managed resources_.
-
-Using `kubectl describe` on a _managed resource_ shows the `Owner References` is
-the _composite resource_.
-
-```yaml {copy-lines="1"}
-kubectl describe bucket | grep "Owner References" -A5
- Owner References:
- API Version: custom-api.example.org/v1alpha1
- Block Owner Deletion: true
- Controller: true
- Kind: XTopicBucket
- Name: my-composite-resource
-```
-
-Each _composite resource_ creates and owns a unique set of _managed resources_.
-If you create a second _composite resource_ Crossplane creates a new storage
-`bucket` and Pub/Sub `topic`.
-
-```yaml {label="xr", copy-lines="all"}
-cat <}}
-Delete a specific _composite resource_ with
-`kubectl delete ` or
-`kubectl delete composite `.
-{{< /hint >}}
-
-Delete the second composition
-```shell
-kubectl delete XTopicBucket my-second-composite-resource
-```
-
-{{}}
-There may a delay in deleting the _managed resources_. Crossplane is making API
-calls to GCP and waits for GCP to confirm they deleted the resources before
-updating the state in Kubernetes.
-{{}}
-
-Now a single bucket and topic exist.
-
-```shell {copy-lines="1"}
-kubectl get bucket
-NAME READY SYNCED EXTERNAL-NAME AGE
-my-composite-resource-m6lbx True True my-composite-resource-m6lbx 11m
-```
-
-```shell {copy-lines="1"}
-kubectl get topic
-NAME READY SYNCED EXTERNAL-NAME AGE
-my-composite-resource-88vzp True True my-composite-resource-88vzp 11m
-```
-
-Delete the other _composite resource_ to remove the last `bucket` and `table`
-_managed resources_.
-
-```shell
-kubectl delete xtopicbucket my-composite-resource
-```
-
-_Composite resources_ are great for creating one or more related resources against
-a template, but all _composite resources_ exist at the Kubernetes "cluster
-level." There's no isolation between _composite resources_. Crossplane uses
-_claims_ to create resources with namespace isolation.
-
-## Create a claim
-
-_Claims_, just like _composite resources_ use the custom API defined in the
-_XRD_. Unlike a _composite resource_, Crossplane can create _claims_ in a
-namespace.
-
-### Create a new Kubernetes namespace
-Create a new namespace with `kubectl create namespace`.
-
-```shell
-kubectl create namespace test
-```
-
-Look at the _XRD_ to see the parameters for the _claim_.
-A _claim_ uses the same {{}}group{{}}
-a _composite resource_ uses but a different
-{{}}kind{{}}.
-
-```yaml {label="XRDclaim2"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-# Removed for brevity
-spec:
-# Removed for brevity
- group: custom-api.example.org
- claimNames:
- kind: TopicBucket
- plural: topicbuckets
-```
-
-Like the _composite resource_, create a new object with the
-{{}}custom-api.example.org{{}} API
-endpoint.
-
-The _XRD_
-{{}}claimNames.kind{{}} defines the
-{{}}kind{{}}.
-
-The {{}}spec{{}} uses the same
-API options as the _composite resource_.
-
-### Apply the claim
-Apply the _claim_ to your Kubernetes cluster.
-
-```yaml {label="claim", copy-lines="all"}
-cat <}}
-View claims with `kubectl get ` or use `kubectl get claim` to view all
-_claims_.
-{{}}
-
-```shell {copy-lines="1"}
-kubectl get TopicBucket -n test
-NAME SYNCED READY CONNECTION-SECRET AGE
-claimed-topic-with-bucket True True 4m37s
-```
-
-When Crossplane creates a _claim_, a unique _composite resource_ is also
-created. View the new _composite resource_ with `kubectl get xtopicbucket`.
-
-```shell {copy-lines="1"}
-kubectl get xtopicbucket
-NAME SYNCED READY COMPOSITION AGE
-claimed-topic-with-bucket-7k2lj True True topic-with-bucket 4m58s
-```
-
-The _composite resource_ exists at the "cluster scope" while the _claim_ exists
-at the "namespace scope."
-
-Create a second namespace and a second claim.
-
-```shell {copy-lines="all"}
-kubectl create namespace test2
-cat <}}) of this guide covers
-_composition patches_ and making all this configuration portable in Crossplane
-_packages_.
-
-## Next steps
-* **[Continue to part 3]({{< ref "provider-gcp-part-3">}})** to create a learn
- about _patching_ resources and creating Crossplane _packages_.
-* Explore GCP resources that Crossplane can configure in the
- [Provider CRD reference](https://marketplace.upbound.io/providers/upbound/provider-family-gcp/).
-* Join the [Crossplane Slack](https://slack.crossplane.io/) and connect with Crossplane users and contributors.
\ No newline at end of file
diff --git a/content/v1.11/getting-started/provider-gcp-part-3.md b/content/v1.11/getting-started/provider-gcp-part-3.md
deleted file mode 100644
index a6253fa9f..000000000
--- a/content/v1.11/getting-started/provider-gcp-part-3.md
+++ /dev/null
@@ -1,659 +0,0 @@
----
-title: GCP Quickstart Part 3
-weight: 120
-tocHidden: true
----
-
-{{< hint "important" >}}
-This guide is part 3 of a series.
-
-Follow **[part 1]({{[}})**
-to install Crossplane and connect your Kubernetes cluster to GCP.
-
-Follow **[part 2]({{][}})** to create a _composition_,
-_custom resource definition_ and a _claim_.
-{{< /hint >}}
-
-[Part 2]({{][}}) created a _composite resource
-definition_ to define the schema of the custom API. Users create a _claim_ to
-use the custom API and apply their options. Part 2 didn't show how the options
-set in a _claim_ change or get applied the associated _composite resources_.
-
-## Prerequisites
-* Complete quickstart [part 1]({{][}}) and [Part 2]({{][}}) to install Crossplane and the quickstart
- configurations.
-
-{{}}
-
-1. Add the Crossplane Helm repository and install Crossplane.
-```shell
-helm repo add \
-crossplane-stable https://charts.crossplane.io/stable
-helm repo update
-&&
-helm install crossplane \
-crossplane-stable/crossplane \
---namespace crossplane-system \
---create-namespace
-```
-
-2. When the Crossplane pods finish installing and are ready, apply the GCP Provider.
-
-```yaml {label="provider",copy-lines="all"}
-cat <}}
-The
-[GCP documentation](https://cloud.google.com/iam/docs/creating-managing-service-account-keys)
-provides information on how to generate a service account JSON file.
-{{< /hint >}}
-
-4. Create a Kubernetes secret from the GCP JSON file
-```shell {label="kube-create-secret",copy-lines="all"}
-kubectl create secret \
-generic gcp-secret \
--n crossplane-system \
---from-file=creds=./gcp-credentials.json
-```
-
-5. Create a _ProviderConfig_
-Include your
-{{< hover label="providerconfig" line="7" >}}GCP project ID{{< /hover >}} in the
-_ProviderConfig_ settings.
-
-{{< hint type="warning" >}}
-Find your GCP project ID from the `project_id` field of the
-`gcp-credentials.json` file.
-{{< /hint >}}
-
-{{< editCode >}}
-```yaml {label="providerconfig",copy-lines="all"}
-cat <$@
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: gcp-secret
- key: creds
-EOF
-```
-{{< /editCode >}}
-
-
-6. Create a _composition_
-```yaml {copy-lines="all"}
-cat <}}
-
-## Enable composition patches
-In a _composition_, `patches` map fields in the custom API to fields inside the
-_managed resources_.
-
-The example _composition_ has two _managed resources_, a
-{{}}bucket{{}} and a
-{{}}topic{{}}.
-
-```yaml {label="compResources"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-# Removed for Brevity
-resources:
- - name: crossplane-quickstart-bucket
- base:
- apiVersion: storage.gcp.upbound.io/v1beta1
- kind: Bucket
- spec:
- forProvider:
- location: US
- - name: crossplane-quickstart-topic
- base:
- apiVersion: pubsub.gcp.upbound.io/v1beta1
- kind: Topic
- spec:
- forProvider:
- messageStoragePolicy:
- - allowedPersistenceRegions:
- - "us-central1"
-```
-
-The custom API defined a single option,
-{{}}location{{}}. A
-{{}}location{{}} can be either
-{{}}EU{{}} or
-{{}}US{{}}.
-
-
-```yaml {label="xrdSnip"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-# Removed for brevity
-spec:
- group: custom-api.example.org
- names:
- kind: XDatabase
-# Removed for brevity
- spec:
- type: object
- properties:
- location:
- type: string
- oneOf:
- - pattern: '^EU$'
- - pattern: '^US$'
-```
-
-Creating a _composition_ `patch` allows Crossplane to update the settings of a
-_composite resource_. Patches apply to an individual _managed resource_
-inside the _composition_.
-
-A {{}}patch{{}} has a
-{{}}fromField{{}} and a
-{{}}toField{{}} specifying which value
-_from_ the custom API should apply _to_ a field in the _managed resource_.
-Patches can create a
-{{}}transform{{}} to change the _from_
-field before it's applied.
-
-The transform
-{{}}type{{}} is what kind of change to
-make on the _from_ field. Types of changes could include appending a string,
-preforming a math operation or mapping one value to another.
-
-Applying a {{}}patch{{}} to the
-{{}}Topic{{}} uses the custom API
-{{}}spec.location{{}} field to use as the
-_managed resource_
-{{}}allowedPersistenceRegions{{}} value.
-
-
-The custom API value "EU" is
-{{}}mapped{{}} to the value
-"europe-central2" and "US" is
-{{}}mapped{{}} to the value
-"us-central1."
-
-
-
-```yaml {label="patch"}
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-# Removed for Brevity
-resources:
- - name: crossplane-quickstart-topic
- base:
- apiVersion: pubsub.gcp.upbound.io/v1beta1
- kind: Topic
- spec:
- forProvider:
- messageStoragePolicy:
- - allowedPersistenceRegions:
- - "us-central1"
- patches:
- - fromFieldPath: "spec.location"
- toFieldPath: "spec.forProvider.messageStoragePolicy[*].allowedPersistenceRegions[*]"
- transforms:
- - type: map
- map:
- EU: "europe-central2"
- US: "us-central1"
-```
-
-Patching is a powerful tool enabling simpler or abstracted APIs. Developers
-aren't required to know the specific GCP region, just the abstracted
-option of "EU" or "US."
-
-
-### Apply the updated composition
-Apply a similar `patch` to the `Bucket` _managed resource_ and apply the updated
-_composition_.
-
-```yaml
-cat <}}location{{}} to "EU."
-
-```yaml {label="claim"}
-cat <}}europe-central2{{< /hover >}}.
-
-```shell {copy-lines="1",label="topicLocation"}
-kubectl describe topic | grep "For Provider" -A3
- For Provider:
- Message Storage Policy:
- Allowed Persistence Regions:
- europe-central2
-```
-
-Describe the `Bucket` resource to see the GCP location is also set to
-{{}}EU{{}}.
-
-```shell {copy-lines="1",label="bucketLocation"}
-kubectl describe bucket | grep "For Provider" -A1
- For Provider:
- Location: EU
-```
-
-
-Using {{}}location: "EU"{{}} in the
-claim patches the _composite resource_, updating the `Topic` GCP region from
-`us-central1` to `europe-central-2` and the `Bucket` from GCP region `US` to GCP
-region `EU`.
-The developer creating the claim isn't required to know which specific GCP
-region or the naming conventions. Using the abstract API options of "EU" or "US"
-the developer places their resources in the desired location.
-
-In this example, patching also allows platform teams to ensure all resources are
-in the same location.
-
-
-Deleting the claim removes the _managed resources_.
-
-{{}}
-The _managed resources_ take up to 5 minutes to delete.
-{{< /hint >}}
-
-```shell
-kubectl delete TopicBucket claimed-eu-topic-with-bucket -n test
-```
-
-## Create a Crossplane configuration package
-
-Creating a configuration package makes your Crossplane custom APIs portable
-and versioned.
-
-Crossplane _configuration packages_ allow users to combine their _custom
-resource definition_ and _composition_ files into an OCI image.
-
-{{< hint "note" >}}
-The [Open Container Initiative](https://opencontainers.org/faq/)
-defines the OCI image standard.
-An OCI images is a standard way to package data.
-{{< /hint >}}
-
-You can host configuration packages in image registries like
-[Docker Hub](https://hub.docker.com/) or the
-[Upbound Marketplace](https://marketplace.upbound.io/).
-
-Crossplane can download and install configuration packages into a Kubernetes
-cluster.
-
-Building and installing configuration packages requires an OCI image compatible
-tool.
-
-{{< hint "note" >}}
-You can use any software that builds OCI images. This includes
-[Docker](https://www.docker.com/) or
-[Upbound's Up command-line tool](https://github.com/upbound/up)
-{{< /hint >}}
-
-A configuration package includes three files:
-* `crossplane.yaml` defines the metadata of the package.
-* `definition.yaml` is the _composite resource definition_ for the package.
-* `composition.yaml` is the _composition_ template for the package.
-
-
-
-### Create a crossplane.yaml file
-
-Configuration packages describe their contents and requirements with a
-`crossplane.yaml` file.
-
-The `crossplane.yaml` file lists the required Crossplane _providers_ and their
-compatible versions as well as the required Crossplane version.
-
-The Crossplane
-{{}}meta.pkg{{}} API defines the schema
-for a
-{{}}Configuration{{}}.
-
-Inside the {{}}spec{{}} define the
-required Crossplane
-{{}}version{{}}.
-
-The {{}}dependsOn{{}} section lists the
-dependencies for a package.
-
-This package lists the Upbound
-{{}}provider-gcp{{}}
-version {{}}0.28.0{{}} or later as a
-dependency.
-
-{{}}
-Crossplane automatically installs dependencies. Dependencies can include other
-configuration packages.
-{{< /hint >}}
-
-```yaml {label="xpyaml"}
-apiVersion: meta.pkg.crossplane.io/v1
-kind: Configuration
-metadata:
- name: crossplane-gcp-quickstart
-spec:
- crossplane:
- version: ">=v1.11.0"
- dependsOn:
- - provider: xpkg.upbound.io/upbound/provider-gcp
- version: ">=v0.28.0"
-```
-
-Create a new directory and save the `crossplane.yaml` file.
-
-```yaml {copy-lines="all"}
-mkdir crossplane-gcp-quickstart
-cat < crossplane-gcp-quickstart/crossplane.yaml
-apiVersion: meta.pkg.crossplane.io/v1
-kind: Configuration
-metadata:
- name: crossplane-gcp-quickstart
-spec:
- crossplane:
- version: ">=v1.11.0"
- dependsOn:
- - provider: xpkg.upbound.io/upbound/provider-gcp
- version: ">=v0.28.0"
-EOF
-```
-
-
-
-### Create a definition.yaml file
-
-
-A configuration package requires a _composite resource definition_ (XRD) to define the
-custom API.
-
-Save the _XRD_ as `definition.yaml` in the same directory as the
-`crossplane.yaml` file.
-
-```yaml {copy-lines="all"}
-cat < crossplane-gcp-quickstart/definition.yaml
-apiVersion: apiextensions.crossplane.io/v1
-kind: CompositeResourceDefinition
-metadata:
- name: xtopicbuckets.custom-api.example.org
-spec:
- group: custom-api.example.org
- names:
- kind: XTopicBucket
- plural: xtopicbuckets
- versions:
- - name: v1alpha1
- served: true
- referenceable: true
- schema:
- openAPIV3Schema:
- type: object
- properties:
- spec:
- type: object
- properties:
- location:
- type: string
- oneOf:
- - pattern: '^EU$'
- - pattern: '^US$'
- required:
- - location
- claimNames:
- kind: TopicBucket
- plural: topicbuckets
-EOF
-```
-
-
-
-### Create a composition.yaml file
-
-
-The _composition_ template creates the _managed resources_ and allows _patches_
-to customize the _managed resources_.
-
-Copy the _composition_ into the `composition.yaml` file in the same directory as
-`crossplane.yaml`.
-
-```yaml
-cat < crossplane-gcp-quickstart/composition.yaml
-apiVersion: apiextensions.crossplane.io/v1
-kind: Composition
-metadata:
- name: topic-with-bucket
-spec:
- compositeTypeRef:
- apiVersion: custom-api.example.org/v1alpha1
- kind: XTopicBucket
- resources:
- - name: crossplane-quickstart-bucket
- base:
- apiVersion: storage.gcp.upbound.io/v1beta1
- kind: Bucket
- spec:
- forProvider:
- location: "US"
- patches:
- - fromFieldPath: "spec.location"
- toFieldPath: "spec.forProvider.location"
- transforms:
- - type: map
- map:
- EU: "EU"
- US: "US"
- - name: crossplane-quickstart-topic
- base:
- apiVersion: pubsub.gcp.upbound.io/v1beta1
- kind: Topic
- spec:
- forProvider:
- messageStoragePolicy:
- - allowedPersistenceRegions:
- - "us-central1"
- patches:
- - fromFieldPath: "spec.location"
- toFieldPath: "spec.forProvider.messageStoragePolicy[*].allowedPersistenceRegions[*]"
- transforms:
- - type: map
- map:
- EU: "europe-central2"
- US: "us-central1"
-EOF
-```
-
-### Install the Crossplane command-line
-To build a configuration package install the Crossplane Kubernetes command-line
-extension.
-
-```shell
-wget "https://raw.githubusercontent.com/crossplane/crossplane/master/install.sh"
-chmod +x install.sh
-./install.sh
-sudo mv crossplane /usr/local/bin
-```
-
-Verify the Crossplane command-line installed with `crossplane --help`
-
-```shell
-crossplane --help
-Usage: crossplane
-
-A command line tool for interacting with Crossplane.
-
-Flags:
- -h, --help Show context-sensitive help.
- -v, --version Print version and quit.
- --verbose Print verbose logging statements.
-# Ouptut removed for brevity
-```
-
-### Build a configuration package
-
-Use the `crossplane` CLI to create an `.xpkg` file containing the
-custom APIs and Crossplane configuration.
-
-```shell
-crossplane build configuration -f crossplane-gcp-quickstart/ --name="crossplane-gcp-quickstart"
-```
-
-Now an `.xpkg` OCI image is inside the `crossplane-gcp-quickstart` directory.
-
-```shell
-ls crossplane-gcp-quickstart/
-composition.yaml crossplane-gcp-quickstart.xpkg crossplane.yaml definition.yaml
-```
-
-## Next steps
-* Explore GCP resources that Crossplane can configure in the [Provider CRD reference](https://marketplace.upbound.io/providers/upbound/provider-family-gcp/).
-* Join the [Crossplane Slack](https://slack.crossplane.io/) and connect with Crossplane users and contributors.
-* Read more about [Crossplane concepts]({{][}})
\ No newline at end of file
diff --git a/content/v1.11/getting-started/provider-gcp.md b/content/v1.11/getting-started/provider-gcp.md
deleted file mode 100644
index 5f5c7d5ac..000000000
--- a/content/v1.11/getting-started/provider-gcp.md
+++ /dev/null
@@ -1,1255 +0,0 @@
----
-title: GCP Quickstart
-weight: 140
----
-
-Connect Crossplane to GCP to create and manage cloud resources from Kubernetes
-with the
-[Upbound GCP Provider](https://marketplace.upbound.io/providers/upbound/provider-gcp).
-
-This guide is in three parts:
-* Part 1 walks through installing Crossplane, configuring the provider to
-authenticate to GCP and creating a _Managed Resource_ in GCP directly from your
-Kubernetes cluster. This shows Crossplane can communicate with GCP.
-* [Part 2]({{< ref "provider-gcp-part-2" >}}) creates a
-_Composite Resource Definition_ (XRD), _Composite Resource_ (XR) and a _Claim_
-(XRC) to show how to create and use custom APIs.
-* [Part 3]({{< ref "provider-gcp-part-3" >}}) demonstrates how to patch
-_Compositions_ with values used in a _Claim_ and how to build a Crossplane
-_Package_ to make a Crossplane platform portable and reusable.
-## Prerequisites
-This quickstart requires:
-* a Kubernetes cluster with at least 6 GB of RAM
-* permissions to create pods and secrets in the Kubernetes cluster
-* [Helm](https://helm.sh/) version `v3.2.0` or later
-* a GCP account with permissions to create a storage bucket
-* GCP [account keys](https://cloud.google.com/iam/docs/creating-managing-service-account-keys)
-* GCP [Project ID](https://support.google.com/googleapi/answer/7014113?hl=en)
-
-## Install Crossplane
-
-Crossplane installs into an existing Kubernetes cluster.
-
-{{< hint type="tip" >}}
-If you don't have a Kubernetes cluster create one locally with
-[Kind](https://kind.sigs.k8s.io/).
-{{< /hint >}}
-
-### Install the Crossplane Helm chart
-
-Helm enables Crossplane to install all its Kubernetes components through a
-_Helm Chart_.
-
-Enable the Crossplane Helm Chart repository:
-
-```shell
-helm repo add \
-crossplane-stable https://charts.crossplane.io/stable && helm repo update
-```
-
-Run the Helm dry-run to see all the Crossplane components Helm installs.
-
-```shell
-helm install crossplane \
-crossplane-stable/crossplane \
---dry-run --debug \
---namespace crossplane-system \
---create-namespace
-```
-{{}}
-```shell
-helm install crossplane \
-crossplane-stable/crossplane \
---dry-run --debug \
---namespace crossplane-system \
---create-namespace
-install.go:193: [debug] Original chart version: ""
-install.go:210: [debug] CHART PATH: /home/vagrant/.cache/helm/repository/crossplane-1.10.1.tgz
-
-NAME: crossplane
-LAST DEPLOYED: Thu Jan 19 15:52:08 2023
-NAMESPACE: crossplane-system
-STATUS: pending-install
-REVISION: 1
-TEST SUITE: None
-USER-SUPPLIED VALUES:
-{}
-
-COMPUTED VALUES:
-affinity: {}
-args: {}
-configuration:
- packages: []
-customAnnotations: {}
-customLabels: {}
-deploymentStrategy: RollingUpdate
-extraEnvVarsCrossplane: {}
-extraEnvVarsRBACManager: {}
-image:
- pullPolicy: IfNotPresent
- repository: crossplane/crossplane
- tag: v1.10.1
-imagePullSecrets: {}
-leaderElection: true
-metrics:
- enabled: false
-nodeSelector: {}
-packageCache:
- medium: ""
- pvc: ""
- sizeLimit: 5Mi
-podSecurityContextCrossplane: {}
-podSecurityContextRBACManager: {}
-priorityClassName: ""
-provider:
- packages: []
-rbacManager:
- affinity: {}
- args: {}
- deploy: true
- leaderElection: true
- managementPolicy: All
- nodeSelector: {}
- replicas: 1
- skipAggregatedClusterRoles: false
- tolerations: {}
-registryCaBundleConfig: {}
-replicas: 1
-resourcesCrossplane:
- limits:
- cpu: 100m
- memory: 512Mi
- requests:
- cpu: 100m
- memory: 256Mi
-resourcesRBACManager:
- limits:
- cpu: 100m
- memory: 512Mi
- requests:
- cpu: 100m
- memory: 256Mi
-securityContextCrossplane:
- allowPrivilegeEscalation: false
- readOnlyRootFilesystem: true
- runAsGroup: 65532
- runAsUser: 65532
-securityContextRBACManager:
- allowPrivilegeEscalation: false
- readOnlyRootFilesystem: true
- runAsGroup: 65532
- runAsUser: 65532
-serviceAccount:
- customAnnotations: {}
-tolerations: {}
-webhooks:
- enabled: false
-
-HOOKS:
-MANIFEST:
----
-# Source: crossplane/templates/rbac-manager-serviceaccount.yaml
-apiVersion: v1
-kind: ServiceAccount
-metadata:
- name: rbac-manager
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
----
-# Source: crossplane/templates/serviceaccount.yaml
-apiVersion: v1
-kind: ServiceAccount
-metadata:
- name: crossplane
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
----
-# Source: crossplane/templates/clusterrole.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-aggregationRule:
- clusterRoleSelectors:
- - matchLabels:
- rbac.crossplane.io/aggregate-to-crossplane: "true"
----
-# Source: crossplane/templates/clusterrole.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:system:aggregate-to-crossplane
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
- crossplane.io/scope: "system"
- rbac.crossplane.io/aggregate-to-crossplane: "true"
-rules:
-- apiGroups:
- - ""
- resources:
- - events
- verbs:
- - create
- - update
- - patch
- - delete
-- apiGroups:
- - apiextensions.k8s.io
- resources:
- - customresourcedefinitions
- verbs:
- - "*"
-- apiGroups:
- - ""
- resources:
- - secrets
- verbs:
- - get
- - list
- - watch
- - create
- - update
- - patch
- - delete
-- apiGroups:
- - ""
- resources:
- - serviceaccounts
- - services
- verbs:
- - "*"
-- apiGroups:
- - apiextensions.crossplane.io
- - pkg.crossplane.io
- - secrets.crossplane.io
- resources:
- - "*"
- verbs:
- - "*"
-- apiGroups:
- - extensions
- - apps
- resources:
- - deployments
- verbs:
- - get
- - list
- - create
- - update
- - patch
- - delete
- - watch
-- apiGroups:
- - ""
- - coordination.k8s.io
- resources:
- - configmaps
- - leases
- verbs:
- - get
- - list
- - create
- - update
- - patch
- - watch
- - delete
-- apiGroups:
- - admissionregistration.k8s.io
- resources:
- - validatingwebhookconfigurations
- - mutatingwebhookconfigurations
- verbs:
- - get
- - list
- - create
- - update
- - patch
- - watch
- - delete
----
-# Source: crossplane/templates/rbac-manager-allowed-provider-permissions.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:allowed-provider-permissions
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-aggregationRule:
- clusterRoleSelectors:
- - matchLabels:
- rbac.crossplane.io/aggregate-to-allowed-provider-permissions: "true"
----
-# Source: crossplane/templates/rbac-manager-clusterrole.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane-rbac-manager
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-- apiGroups:
- - ""
- resources:
- - events
- verbs:
- - create
- - update
- - patch
- - delete
-- apiGroups:
- - ""
- resources:
- - namespaces
- - serviceaccounts
- verbs:
- - get
- - list
- - watch
-- apiGroups:
- - apiextensions.crossplane.io
- resources:
- - compositeresourcedefinitions
- verbs:
- - get
- - list
- - watch
-- apiGroups:
- - pkg.crossplane.io
- resources:
- - providerrevisions
- verbs:
- - get
- - list
- - watch
-- apiGroups:
- - apiextensions.k8s.io
- resources:
- - customresourcedefinitions
- verbs:
- - get
- - list
- - watch
-- apiGroups:
- - rbac.authorization.k8s.io
- resources:
- - clusterroles
- - roles
- verbs:
- - get
- - list
- - watch
- - create
- - update
- - patch
- # The RBAC manager may grant access it does not have.
- - escalate
-- apiGroups:
- - rbac.authorization.k8s.io
- resources:
- - clusterroles
- verbs:
- - bind
-- apiGroups:
- - rbac.authorization.k8s.io
- resources:
- - clusterrolebindings
- verbs:
- - "*"
-- apiGroups:
- - ""
- - coordination.k8s.io
- resources:
- - configmaps
- - leases
- verbs:
- - get
- - list
- - create
- - update
- - patch
- - watch
- - delete
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane-admin
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-aggregationRule:
- clusterRoleSelectors:
- - matchLabels:
- rbac.crossplane.io/aggregate-to-admin: "true"
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane-edit
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-aggregationRule:
- clusterRoleSelectors:
- - matchLabels:
- rbac.crossplane.io/aggregate-to-edit: "true"
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane-view
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-aggregationRule:
- clusterRoleSelectors:
- - matchLabels:
- rbac.crossplane.io/aggregate-to-view: "true"
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane-browse
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-aggregationRule:
- clusterRoleSelectors:
- - matchLabels:
- rbac.crossplane.io/aggregate-to-browse: "true"
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:aggregate-to-admin
- labels:
- rbac.crossplane.io/aggregate-to-admin: "true"
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-# Crossplane administrators have access to view events.
-- apiGroups: [""]
- resources: [events]
- verbs: [get, list, watch]
-# Crossplane administrators must create provider credential secrets, and may
-# need to read or otherwise interact with connection secrets. They may also need
-# to create or annotate namespaces.
-- apiGroups: [""]
- resources: [secrets, namespaces]
- verbs: ["*"]
-# Crossplane administrators have access to view the roles that they may be able
-# to grant to other subjects.
-- apiGroups: [rbac.authorization.k8s.io]
- resources: [clusterroles, roles]
- verbs: [get, list, watch]
-# Crossplane administrators have access to grant the access they have to other
-# subjects.
-- apiGroups: [rbac.authorization.k8s.io]
- resources: [clusterrolebindings, rolebindings]
- verbs: ["*"]
-# Crossplane administrators have full access to built in Crossplane types.
-- apiGroups:
- - apiextensions.crossplane.io
- resources: ["*"]
- verbs: ["*"]
-- apiGroups:
- - pkg.crossplane.io
- resources: [providers, configurations, providerrevisions, configurationrevisions]
- verbs: ["*"]
-# Crossplane administrators have access to view CRDs in order to debug XRDs.
-- apiGroups: [apiextensions.k8s.io]
- resources: [customresourcedefinitions]
- verbs: [get, list, watch]
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:aggregate-to-edit
- labels:
- rbac.crossplane.io/aggregate-to-edit: "true"
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-# Crossplane editors have access to view events.
-- apiGroups: [""]
- resources: [events]
- verbs: [get, list, watch]
-# Crossplane editors must create provider credential secrets, and may need to
-# read or otherwise interact with connection secrets.
-- apiGroups: [""]
- resources: [secrets]
- verbs: ["*"]
-# Crossplane editors may see which namespaces exist, but not edit them.
-- apiGroups: [""]
- resources: [namespaces]
- verbs: [get, list, watch]
-# Crossplane editors have full access to built in Crossplane types.
-- apiGroups:
- - apiextensions.crossplane.io
- resources: ["*"]
- verbs: ["*"]
-- apiGroups:
- - pkg.crossplane.io
- resources: [providers, configurations, providerrevisions, configurationrevisions]
- verbs: ["*"]
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:aggregate-to-view
- labels:
- rbac.crossplane.io/aggregate-to-view: "true"
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-# Crossplane viewers have access to view events.
-- apiGroups: [""]
- resources: [events]
- verbs: [get, list, watch]
-# Crossplane viewers may see which namespaces exist.
-- apiGroups: [""]
- resources: [namespaces]
- verbs: [get, list, watch]
-# Crossplane viewers have read-only access to built in Crossplane types.
-- apiGroups:
- - apiextensions.crossplane.io
- resources: ["*"]
- verbs: [get, list, watch]
-- apiGroups:
- - pkg.crossplane.io
- resources: [providers, configurations, providerrevisions, configurationrevisions]
- verbs: [get, list, watch]
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:aggregate-to-browse
- labels:
- rbac.crossplane.io/aggregate-to-browse: "true"
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-# Crossplane browsers have access to view events.
-- apiGroups: [""]
- resources: [events]
- verbs: [get, list, watch]
-# Crossplane browsers have read-only access to compositions and XRDs. This
-# allows them to discover and select an appropriate composition when creating a
-# resource claim.
-- apiGroups:
- - apiextensions.crossplane.io
- resources: ["*"]
- verbs: [get, list, watch]
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-# The below ClusterRoles are aggregated to the namespaced RBAC roles created by
-# the Crossplane RBAC manager when it is running in --manage=All mode.
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:aggregate-to-ns-admin
- labels:
- rbac.crossplane.io/aggregate-to-ns-admin: "true"
- rbac.crossplane.io/base-of-ns-admin: "true"
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-# Crossplane namespace admins have access to view events.
-- apiGroups: [""]
- resources: [events]
- verbs: [get, list, watch]
-# Crossplane namespace admins may need to read or otherwise interact with
-# resource claim connection secrets.
-- apiGroups: [""]
- resources: [secrets]
- verbs: ["*"]
-# Crossplane namespace admins have access to view the roles that they may be
-# able to grant to other subjects.
-- apiGroups: [rbac.authorization.k8s.io]
- resources: [roles]
- verbs: [get, list, watch]
-# Crossplane namespace admins have access to grant the access they have to other
-# subjects.
-- apiGroups: [rbac.authorization.k8s.io]
- resources: [rolebindings]
- verbs: ["*"]
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:aggregate-to-ns-edit
- labels:
- rbac.crossplane.io/aggregate-to-ns-edit: "true"
- rbac.crossplane.io/base-of-ns-edit: "true"
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-# Crossplane namespace editors have access to view events.
-- apiGroups: [""]
- resources: [events]
- verbs: [get, list, watch]
-# Crossplane namespace editors may need to read or otherwise interact with
-# resource claim connection secrets.
-- apiGroups: [""]
- resources: [secrets]
- verbs: ["*"]
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: crossplane:aggregate-to-ns-view
- labels:
- rbac.crossplane.io/aggregate-to-ns-view: "true"
- rbac.crossplane.io/base-of-ns-view: "true"
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-rules:
-# Crossplane namespace viewers have access to view events.
-- apiGroups: [""]
- resources: [events]
- verbs: [get, list, watch]
----
-# Source: crossplane/templates/clusterrolebinding.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
- name: crossplane
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-roleRef:
- apiGroup: rbac.authorization.k8s.io
- kind: ClusterRole
- name: crossplane
-subjects:
-- kind: ServiceAccount
- name: crossplane
- namespace: crossplane-system
----
-# Source: crossplane/templates/rbac-manager-clusterrolebinding.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
- name: crossplane-rbac-manager
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-roleRef:
- apiGroup: rbac.authorization.k8s.io
- kind: ClusterRole
- name: crossplane-rbac-manager
-subjects:
-- kind: ServiceAccount
- name: rbac-manager
- namespace: crossplane-system
----
-# Source: crossplane/templates/rbac-manager-managed-clusterroles.yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
- name: crossplane-admin
- labels:
- app: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-roleRef:
- apiGroup: rbac.authorization.k8s.io
- kind: ClusterRole
- name: crossplane-admin
-subjects:
-- apiGroup: rbac.authorization.k8s.io
- kind: Group
- name: crossplane:masters
----
-# Source: crossplane/templates/deployment.yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- name: crossplane
- labels:
- app: crossplane
- release: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-spec:
- replicas: 1
- selector:
- matchLabels:
- app: crossplane
- release: crossplane
- strategy:
- type: RollingUpdate
- template:
- metadata:
- labels:
- app: crossplane
- release: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
- spec:
- securityContext:
- {}
- serviceAccountName: crossplane
- initContainers:
- - image: crossplane/crossplane:v1.10.1
- args:
- - core
- - init
- imagePullPolicy: IfNotPresent
- name: crossplane-init
- resources:
- limits:
- cpu: 100m
- memory: 512Mi
- requests:
- cpu: 100m
- memory: 256Mi
- securityContext:
- allowPrivilegeEscalation: false
- readOnlyRootFilesystem: true
- runAsGroup: 65532
- runAsUser: 65532
- env:
- - name: POD_NAMESPACE
- valueFrom:
- fieldRef:
- fieldPath: metadata.namespace
- - name: POD_SERVICE_ACCOUNT
- valueFrom:
- fieldRef:
- fieldPath: spec.serviceAccountName
- containers:
- - image: crossplane/crossplane:v1.10.1
- args:
- - core
- - start
- imagePullPolicy: IfNotPresent
- name: crossplane
- resources:
- limits:
- cpu: 100m
- memory: 512Mi
- requests:
- cpu: 100m
- memory: 256Mi
- securityContext:
- allowPrivilegeEscalation: false
- readOnlyRootFilesystem: true
- runAsGroup: 65532
- runAsUser: 65532
- env:
- - name: POD_NAMESPACE
- valueFrom:
- fieldRef:
- fieldPath: metadata.namespace
- - name: LEADER_ELECTION
- value: "true"
- volumeMounts:
- - mountPath: /cache
- name: package-cache
- volumes:
- - name: package-cache
- emptyDir:
- medium:
- sizeLimit: 5Mi
----
-# Source: crossplane/templates/rbac-manager-deployment.yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- name: crossplane-rbac-manager
- labels:
- app: crossplane-rbac-manager
- release: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
-spec:
- replicas: 1
- selector:
- matchLabels:
- app: crossplane-rbac-manager
- release: crossplane
- strategy:
- type: RollingUpdate
- template:
- metadata:
- labels:
- app: crossplane-rbac-manager
- release: crossplane
- helm.sh/chart: crossplane-1.10.1
- app.kubernetes.io/managed-by: Helm
- app.kubernetes.io/component: cloud-infrastructure-controller
- app.kubernetes.io/part-of: crossplane
- app.kubernetes.io/name: crossplane
- app.kubernetes.io/instance: crossplane
- app.kubernetes.io/version: "1.10.1"
- spec:
- securityContext:
- {}
- serviceAccountName: rbac-manager
- initContainers:
- - image: crossplane/crossplane:v1.10.1
- args:
- - rbac
- - init
- imagePullPolicy: IfNotPresent
- name: crossplane-init
- resources:
- limits:
- cpu: 100m
- memory: 512Mi
- requests:
- cpu: 100m
- memory: 256Mi
- securityContext:
- allowPrivilegeEscalation: false
- readOnlyRootFilesystem: true
- runAsGroup: 65532
- runAsUser: 65532
- containers:
- - image: crossplane/crossplane:v1.10.1
- args:
- - rbac
- - start
- - --manage=All
- - --provider-clusterrole=crossplane:allowed-provider-permissions
- imagePullPolicy: IfNotPresent
- name: crossplane
- resources:
- limits:
- cpu: 100m
- memory: 512Mi
- requests:
- cpu: 100m
- memory: 256Mi
- securityContext:
- allowPrivilegeEscalation: false
- readOnlyRootFilesystem: true
- runAsGroup: 65532
- runAsUser: 65532
- env:
- - name: LEADER_ELECTION
- value: "true"
-
-NOTES:
-Release: crossplane
-
-Chart Name: crossplane
-Chart Description: Crossplane is an open source Kubernetes add-on that enables
-platform teams to assemble infrastructure from multiple vendors, and expose
-higher level self-service APIs for application teams to consume.
-Chart Version: 1.10.1
-Chart Application Version: 1.10.1
-
-Kube Version: v1.24.9
-```
-{{< /expand >}}
-
-Install the Crossplane components using `helm install`.
-
-```shell
-helm install crossplane \
-crossplane-stable/crossplane \
---namespace crossplane-system \
---create-namespace
-```
-
-Verify Crossplane installed with `kubectl get pods`.
-
-```shell {copy-lines="1"}
-kubectl get pods -n crossplane-system
-NAME READY STATUS RESTARTS AGE
-crossplane-644f4d5958-97m5v 1/1 Running 0 16s
-crossplane-rbac-manager-7f8ccd95f8-nkq78 1/1 Running 0 16s
-```
-
-Installing Crossplane creates new Kubernetes API end-points. Look at the new
-API end-points with `kubectl api-resources | grep crossplane`.
-
-```shell {label="grep",copy-lines="1"}
-kubectl api-resources | grep crossplane
-compositeresourcedefinitions xrd,xrds apiextensions.crossplane.io/v1 false CompositeResourceDefinition
-compositionrevisions apiextensions.crossplane.io/v1alpha1 false CompositionRevision
-compositions apiextensions.crossplane.io/v1 false Composition
-configurationrevisions pkg.crossplane.io/v1 false ConfigurationRevision
-configurations pkg.crossplane.io/v1 false Configuration
-controllerconfigs pkg.crossplane.io/v1alpha1 false ControllerConfig
-locks pkg.crossplane.io/v1beta1 false Lock
-providerrevisions pkg.crossplane.io/v1 false ProviderRevision
-providers pkg.crossplane.io/v1 false Provider
-storeconfigs secrets.crossplane.io/v1alpha1 false StoreConfig
-```
-
-## Install the GCP provider
-
-Install the provider into the Kubernetes cluster with a Kubernetes configuration
-file.
-
-```shell {label="provider",copy-lines="all"}
-cat <}}kind: Provider{{< /hover >}} uses the
-Crossplane `Provider` _Custom Resource Definition_ to connect your Kubernetes
-cluster to your cloud provider.
-
-Verify the provider installed with `kubectl get providers`.
-
-{{< hint type="note" >}}
-It may take up to five minutes for the provider to list `HEALTHY` as `True`.
-{{< /hint >}}
-
-```shell {copy-lines="1"}
-kubectl get providers
-NAME INSTALLED HEALTHY PACKAGE AGE
-upbound-provider-gcp True True xpkg.upbound.io/upbound/provider-gcp:v0.28.0 107s
-```
-
-A provider installs their own Kubernetes _Custom Resource Definitions_ (CRDs).
-These CRDs allow you to create GCP resources directly inside Kubernetes.
-
-You can view the new CRDs with `kubectl get crds`. Every CRD maps to a unique
-GCP service Crossplane can provision and manage.
-
-
-{{< hint type="tip" >}}
-See details about all the supported CRDs in the
-[Upbound Marketplace](https://marketplace.upbound.io/providers/upbound/provider-family-gcp/).
-{{< /hint >}}
-
-## Create a Kubernetes secret for GCP
-The provider requires credentials to create and manage GCP resources. Providers
-use a Kubernetes _Secret_ to connect the credentials to the provider.
-
-First generate a Kubernetes _Secret_ from a Google Cloud service account JSON
-file and then configure the Provider to use it.
-
-{{< hint type="note" >}}
-Other authentication methods exist and are beyond the scope of this guide. The
-[Provider documentation](https://marketplace.upbound.io/providers/upbound/provider-gcp/latest/docs/configuration) contains information on alternative authentication methods.
-{{< /hint >}}
-
-### Generate a GCP service account JSON file
-For basic user authentication, use a Google Cloud service account JSON file.
-
-{{< hint type="tip" >}}
-The
-[GCP documentation](https://cloud.google.com/iam/docs/creating-managing-service-account-keys)
-provides information on how to generate a service account JSON file.
-{{< /hint >}}
-
-Save this JSON file as `gcp-credentials.json`
-
-{{< hint type="note" >}}
-The [Configuration](https://marketplace.upbound.io/providers/upbound/provider-gcp/latest/docs/configuration) section of the Provider documentation describes other
-authentication methods.
-{{< /hint >}}
-
-### Create a Kubernetes secret with the GCP credentials
-A Kubernetes generic secret has a name and contents. Use
-{{< hover label="kube-create-secret" line="1">}}kubectl create secret{{< /hover >}}
-to generate the secret object named
-{{< hover label="kube-create-secret" line="2">}}gcp-secret{{< /hover >}} in the
-{{< hover label="kube-create-secret" line="3">}}crossplane-system{{ hover >}}
-namespace.
-Use the {{< hover label="kube-create-secret" line="4">}}--from-file={{}}
-argument to set the value to the contents of the
-{{< hover label="kube-create-secret" line="4">}}gcp-credentials.json{{< /hover >}}
-file.
-
-
-```shell {label="kube-create-secret",copy-lines="all"}
-kubectl create secret \
-generic gcp-secret \
--n crossplane-system \
---from-file=creds=./gcp-credentials.json
-```
-
-View the secret with `kubectl describe secret`
-
-{{< hint type="note" >}}
-The size may be larger if there are extra blank spaces in your JSON file.
-{{< /hint >}}
-
-```shell {copy-lines="1"}
-kubectl describe secret gcp-secret -n crossplane-system
-Name: gcp-secret
-Namespace: crossplane-system
-Labels:
-Annotations:
-
-Type: Opaque
-
-Data
-====
-creds: 2330 bytes
-```
-
-## Create a ProviderConfig
-A `ProviderConfig` customizes the settings of the GCP Provider.
-
-Apply the
-{{< hover label="providerconfig" line="2">}}ProviderConfig{{ hover >}}.
-Include your
-{{< hover label="providerconfig" line="7" >}}GCP project ID{{< /hover >}} in the
-_ProviderConfig_ settings.
-
-{{< hint type="warning" >}}
-Find your GCP project ID from the `project_id` field of the
-`gcp-credentials.json` file.
-{{< /hint >}}
-
-{{< editCode >}}
-```yaml {label="providerconfig",copy-lines="all"}
-cat <$@
- credentials:
- source: Secret
- secretRef:
- namespace: crossplane-system
- name: gcp-secret
- key: creds
-EOF
-```
-{{< /editCode >}}
-
-This attaches the GCP credentials, saved as a Kubernetes secret, as a
-{{< hover label="providerconfig" line="10">}}secretRef{{ hover>}}.
-
-The {{< hover label="providerconfig" line="12">}}spec.credentials.secretRef.name{{< /hover >}} value is the name of the Kubernetes secret containing the GCP credentials in the
-{{< hover label="providerconfig" line="11">}}spec.credentials.secretRef.namespace{{< /hover >}}.
-
-## Create a managed resource
-A _managed resource_ is anything Crossplane creates and manages outside of the
-Kubernetes cluster. This creates a GCP storage bucket with Crossplane.
-The storage bucket is a _managed resource_.
-
-{{< hint type="note" >}}
-To generate a unique name use
-{{}}generateName{{}} instead of `name`.
-{{< /hint >}}
-
-```yaml {label="xr",copy-lines="all"}
-cat <}}apiVersion{{< /hover >}} and
-{{< hover label="xr" line="3">}}kind{{}} are from the provider's CRDs.
-
-The {{< hover label="xr" line="10">}}spec.forProvider.location{{< /hover >}}
-tells GCP which GCP region to use when deploying resources. For a
-{{}}bucket{{}} the
-region can be any
-[GCP multi-region location](https://cloud.google.com/storage/docs/locations#location-mr)
-
-Use `kubectl get bucket` to verify Crossplane created the bucket.
-
-{{< hint type="tip" >}}
-Crossplane created the bucket when the values `READY` and `SYNCED` are `True`.
-This may take up to 5 minutes.
-{{< /hint >}}
-
-```shell {copy-lines="1"}
-kubectl get bucket
-NAME READY SYNCED EXTERNAL-NAME AGE
-crossplane-bucket-8b7gw True True crossplane-bucket-8b7gw 2m2s
-```
-
-## Delete the managed resource
-Before shutting down your Kubernetes cluster, delete the GCP bucket just
-created.
-
-Use `kubectl delete bucket` to remove the bucket.
-
-{{}}
-Use the `--selector` flag to delete by label instead of by name.
-{{}}
-
-```shell {copy-lines="1"}
-kubectl delete bucket --selector docs.crossplane.io/example=provider-gcp
-bucket.storage.gcp.upbound.io "crossplane-bucket-8b7gw" deleted
-```
-
-## Next steps
-* **[Continue to part 2]({{< ref "provider-gcp-part-2">}})** to create a
-Crossplane _Composite Resource_ and _Claim_.
-* Explore GCP resources that can Crossplane can configure in the
-[Provider CRD reference](https://marketplace.upbound.io/providers/upbound/provider-family-gcp/).
-* Join the [Crossplane Slack](https://slack.crossplane.io/) and connect with
-Crossplane users and contributors.
\ No newline at end of file
diff --git a/content/v1.13/concepts/compositions.md b/content/v1.13/concepts/compositions.md
index 4eb36cdcb..4de43e165 100644
--- a/content/v1.13/concepts/compositions.md
+++ b/content/v1.13/concepts/compositions.md
@@ -1224,8 +1224,8 @@ Composition.
## Composition validation
-When creating a Composition Crossplane automatically validates specific
-parameters in the Composition.
+When creating a Composition, Crossplane automatically validates its integrity,
+checking that the Composition is well formed, for example:
* All resources either use a `name` or don't. Compositions can't use both named
and unnamed resources.
@@ -1242,39 +1242,58 @@ parameters in the Composition.
* Composition function `type` is `container`.
* Composition function names are unique.
-### Resource schema validation
-
-Optionally, Crossplane can also validate the schema of the resources defined
-inside a Composition. This verifies that the resource `apiVersion` and `kinds`
-are valid.
-
+### Composition schema aware validation
+
+Crossplane also performs schema aware
+validation of Compositions. Schema validation checks that `patches`,
+`readinessChecks` and `connectionDetails` are valid according to the resource
+schemas. For example, checking that the source and destination fields of a patch
+are valid according to the source and destination resource schema.
+
+{{}}
+Composition schema aware validation is an alpha feature. Crossplane doesn't
+enable alpha features by default.
+
+Enable schema aware validation by setting the
+`--enable-composition-webhook-schema-validation=true` flag on the Crossplane
+pod.
-Enable "schema validation" with the
-`--enable-composition-webhook-schema-validation` flag on the Crossplane pod.
The [Crossplane Pods]({{][}}) page has
more information on enabling Crossplane flags.
+{{< /hint >}}
+
+#### Schema aware validation modes
+
+
+Crossplane always rejects Compositions in case of integrity errors.
+
+
+Set the schema aware validation mode to configure how Crossplane handles both
+missing resource schemas and schema aware validation errors.
{{}}
-
-Schema validation only checks the `apiVersion` and `kind` are valid. Schema
-validation doesn't validate the fields of a specific resource.
-
+If a resource schema is missing, Crossplane skips schema aware validation
+but still returns an error for integrity errors and a warning or an error
+for the missing schemas.
{{< /hint >}}
-The default validations are still checked with schema validation enabled.
-#### Validation modes
+The following modes are available:
-Schema validation supports two modes:
-* `loose` (default) - Sends an warning for each schema error and installs the
- Composition if the default validations pass.
-* `strict` - Send an error for every schema validation error and rejects the
- Composition.
+{{< table "table table-sm table-striped" >}}
+| Mode | Missing Schema | Schema Aware Error | Integrity Error |
+| -------- | -------------- |--------------------|-----------------|
+| `loose` | Warning | Error | Error |
+| `strict` | Error | Error | Error |
+{{< /table >}}
Change the validation mode for a Composition with the
-{{}}crossplane.io/composition-validation-mode{{}}
-annotation.
+{{}}crossplane.io/composition-validation-mode{{}}
+annotation.
+
+If not specified, the default mode is `loose`.
-For example, to enable `strict` mode checking:
+For example, to enable `strict` mode checking set the annotation value to
+{{}}strict{{}}.
```yaml {copy-lines="none",label="mode"}
apiVersion: apiextensions.crossplane.io/v1
@@ -1286,3 +1305,16 @@ metadata:
spec:
# Removed for brevity
```
+
+{{}}
+Validation modes also apply to Compositions defined by Configuration packages.
+
+Depending on the mode configured in the Composition, schema aware validation
+issues may result in warnings or the rejection of the Composition.
+
+View the Crossplane logs for validation warnings.
+
+Crossplane sets a Configuration as unhealthy if there are validation errors.
+View the Configuration details with `kubectl describe configuration` to see the
+specific errors.
+{{< /hint >}}
diff --git a/content/v1.11/_index.md b/content/v1.14/_index.md
similarity index 94%
rename from content/v1.11/_index.md
rename to content/v1.14/_index.md
index 8bbbfbd2c..b9d55816d 100644
--- a/content/v1.11/_index.md
+++ b/content/v1.14/_index.md
@@ -2,7 +2,7 @@
title: "Overview"
weight: -1
cascade:
- version: "1.11"
+ version: "1.14"
---
{{< img src="/media/banner.png" alt="Crossplane Popsicle Truck" size="large" >}}
@@ -18,7 +18,7 @@ APIs. Crossplane can even let you
directly from Kubernetes. If it has an API, Crossplane can connect to it.
With Crossplane, platform teams can create new abstractions and custom
-APIs with the full power of Kubernetes policies, namespaces, role-based access
+APIs with the full power of Kubernetes policies, namespaces, role based access
controls and more. Crossplane brings all your non-Kubernetes resources under
one roof.
@@ -29,16 +29,18 @@ and use Kubernetes as the control plane for everything.
{{< hint "tip" >}}
**What's a control plane?**
+
Control planes create and manage the lifecycle of resources. Control planes
constantly _check_ that the intended resources exist, _report_ when the intended
state doesn't match reality and _act_ to make things right.
Crossplane extends the Kubernetes control plane to be a **universal control
plane** to check, report and act on any resource, anywhere.
+
{{< /hint >}}
-# Get Started
+# Get started
* [Install Crossplane]({{][}}) in your Kubernetes cluster
* Learn more about how Crossplane works in the
[Crossplane introduction]({{][}})
diff --git a/content/v1.14/cli/_index.md b/content/v1.14/cli/_index.md
new file mode 100644
index 000000000..10150e54c
--- /dev/null
+++ b/content/v1.14/cli/_index.md
@@ -0,0 +1,64 @@
+---
+weight: 400
+title: Crossplane CLI
+description: "Documentation for the Crossplane command-line interface"
+---
+
+The Crossplane CLI helps simplify some development and administration aspects of
+Crossplane.
+
+The Crossplane CLI includes:
+* tools to build, install, update and push Crossplane Packages
+* standalone Composition Function testing and rendering without the need to access a Kubernetes cluster running Crossplane
+* troubleshoot Crossplane Compositions, Composite Resources and Managed Resources
+
+## Installing the CLI
+
+The Crossplane CLI is a single standalone binary with no external dependencies.
+
+{{}}
+Install the Crossplane CLI on a user's computer.
+
+Most Crossplane CLI commands are independent of Kubernetes and
+don't require access to a Crossplane pod.
+{{< /hint >}}
+
+To download the latest version for your CPU architecture with the Crossplane
+install script.
+
+```shell
+curl -sL "https://raw.githubusercontent.com/crossplane/crossplane/master/install.sh" | sh
+```
+
+[The script](https://raw.githubusercontent.com/crossplane/crossplane/master/install.sh)
+detects your CPU architecture and downloads the latest stable release.
+
+{{}}
+
+If you don't want to run shell script you can manually download a binary from
+the Crossplane releases repository at
+https://releases.crossplane.io/stable/current/bin
+
+{{}}
+
+The CLI is named `crank` in the release repository. Download this file.
+
+
+The `crossplane` binary is the Kubernetes Crossplane pod image.
+{{< /hint >}}
+
+Move the binary to a location in your `$PATH`, for example `/usr/local/bin`.
+{{< /expand >}}
+
+### Download other CLI versions
+
+Download different Crossplane CLI versions or different release branches with
+the `XP_CHANNEL` and `XP_VERSION` environmental variables.
+
+By default the CLI installs from the `XP_CHANNEL` named `stable` and the
+`XP_VERSION` of `current`, matching the most recent stable release.
+
+For example, to install CLI version `v1.14.0` add `XP_VERSION=v1.14.0` to the
+download script curl command:
+
+`curl -sL "https://raw.githubusercontent.com/crossplane/crossplane/master/install.sh" | XP_VERSION=v1.14.0 sh`
\ No newline at end of file
diff --git a/content/v1.14/cli/command-reference.md b/content/v1.14/cli/command-reference.md
new file mode 100644
index 000000000..016aad416
--- /dev/null
+++ b/content/v1.14/cli/command-reference.md
@@ -0,0 +1,611 @@
+---
+weight: 50
+title: Command Reference
+description: "Command reference for the Crossplane CLI"
+---
+
+
+The `crossplane` CLI provides utilities to make using Crossplane easier.
+
+Read the [Crossplane CLI overview]({{][}}) page for information on
+installing `crossplane`.
+
+## Global flags
+The following flags are available for all commands.
+
+{{< table "table table-sm table-striped">}}
+| Short flag | Long flag | Description |
+|------------|-------------|------------------------------|
+| `-h` | `--help` | Show context sensitive help. |
+| `-v` | `--version` | Print version and exit. |
+| | `--verbose` | Print verbose output. |
+{{< /table >}}
+
+## xpkg
+
+The `crossplane xpkg` commands create, install and update Crossplane
+[packages]({{][}}) as well as enable authentication
+and publishing of Crossplane packages to a Crossplane package registry.
+
+### xpkg build
+
+Using `crossplane xpkg build` provides automation and simplification to build
+Crossplane packages.
+
+The Crossplane CLI combines a directory of YAML files and packages them as
+an [OCI container image](https://opencontainers.org/).
+
+The CLI applies the required annotations and values to meet the
+[Crossplane XPKG specification](https://github.com/crossplane/crossplane/blob/master/contributing/specifications/xpkg.md).
+
+The `crossplane` CLI supports building
+[configuration]({{< ref "../concepts/packages" >}}),
+[function]({{][}}) and
+[provider]({{][}}) package types.
+
+
+#### Flags
+{{< table "table table-sm table-striped">}}
+| Short flag | Long flag | Description |
+| ------------ | ------------- | ------------------------------ |
+| | `--embed-runtime-image-name=NAME` | The image name and tag of an image to include in the package. Only for provider and function packages. |
+| | `--embed-runtime-image-tarball=PATH` | The filename of an image to include in the package. Only for provider and function packages. |
+| `-e` | `--examples-root="./examples"` | The path to a directory of examples related to the package. |
+| | `--ignore=PATH,...` | List of files and directories to ignore. |
+| `-o` | `--package-file=PATH` | Directory and filename of the created package. |
+| `-f` | `--package-root="."` | Directory to search for YAML files. |
+{{< /table >}}
+
+The `crossplane xpkg build` command recursively looks in the directory set by
+`--package-root` and attempts to combine any files ending in `.yml` or `.yaml`
+into a package.
+
+All YAML files must be valid Kubernetes manifests with `apiVersion`, `kind`,
+`metadata` and `spec` fields.
+
+#### Ignore files
+
+Use `--ignore` to provide a list of files and directories to ignore.
+
+For example,
+`crossplane xpkg build --ignore="./test/*,kind-config.yaml"`
+
+#### Set the package name
+
+`crossplane` automatically names the new package a combination of the
+`metadata.name` and a hash of the package contents and saves the contents
+in the same location as `--package-root`. Define a specific location and
+filename with `--package-file` or `-o`.
+
+For example,
+`crossplane xpkg build -o /home/crossplane/example.xpkg`.
+
+
+#### Include examples
+
+Include YAML files demonstrating how to use the package with `--examples-root`.
+
+[Upbound Marketplace](https://marketplace.upbound.io/) uses files included with
+`--examples-root` as documentation for published packages.
+
+#### Include a runtime image
+
+Functions and Providers require YAML files describing their dependencies and
+settings as well as a container image for their runtime.
+
+Using `--embed-runtime-image-name` runs a specified image and
+includes the image inside the function or provider package.
+
+{{}}
+Images referenced with `--embed-runtime-image-name` must be in the local Docker
+cache.
+
+Use `docker pull` to download a missing image.
+{{< /hint >}}
+
+The `--embed-runtime-image-tarball` flag includes a local OCI image tarball
+inside the function or provider package.
+
+
+### xpkg install
+
+Download and install packages into Crossplane with `crossplane xpkg install`.
+
+By default the `crossplane xpkg install` command uses the Kubernetes
+configuration defined in `~/.kube/config`.
+
+Define a custom Kubernetes configuration file location with the environmental
+variable `KUBECONFIG`.
+
+Specify the package kind, package file and optionally a name to give the package
+inside Crossplane.
+
+`crossplane xpkg install []`
+
+The `` is either a `configuration`, `function` or `provider`.
+
+For example, to install version 0.42.0 of the
+[AWS S3 provider](https://marketplace.upbound.io/providers/upbound/provider-aws-s3/v0.42.0):
+
+`crossplane xpkg install provider xpkg.upbound.io/upbound/provider-aws-s3:v0.42.0`
+
+#### Flags
+{{< table "table table-sm table-striped">}}
+| Short flag | Long flag | Description |
+| ------------ | ------------- | ------------------------------ |
+| | `--runtime-config=` | Install the package with a runtime configuration. |
+| `-m` | `--manual-activation` | Set the `revisionActiviationPolicy` to `Manual`. |
+| | `--package-pull-secrets=]` | A comma-seperated list of Kubernetes secrets to use for authenticating to the package registry. |
+| `-r` | `--revision-history-limit=` | Set the `revisionHistoryLimit`. Defaults to `1`. |
+| `-w` | `--wait=` | Number of seconds to wait for a package to install. |
+
+{{< /table >}}
+
+#### Wait for package install
+
+When installing a package the `crossplane xpkg install` command doesn't wait for
+the package to download and install. View any download or installation problems
+by inspecting the `configuration` with `kubectl describe configuration`.
+
+Use `--wait` to have the `crossplane xpkg install` command to wait for a
+package to have the condition `HEALTHY` before continuing. The command
+returns an error if the `wait` time expires before the package is `HEALTHY`.
+
+#### Require manual package activation
+
+Set the package to require
+[manual activation]({{[}}),
+preventing an automatic upgrade of a package with `--manual-activation`
+
+#### Authenticate to a private registry
+
+To authenticate to a private package registry use `--package-pull-secrets` and
+provide a list of Kubernetes Secret objects.
+
+{{}}
+The secrets must be in the same namespace as the Crossplane pod.
+{{< /hint >}}
+
+#### Customize the number of stored package versions
+
+By default Crossplane only stores a single inactive package in the local package
+cache.
+
+Store more inactive copies of a package with `--revision-history-limit`.
+
+Read more about
+[package revisions]({{< ref "../concepts/packages#configuration-revisions" >}})
+in the package documentation.
+
+### xpkg login
+
+Use `xpkg login` to authenticate to `xpkg.upbound.io`, the
+[Upbound Marketplace](https://marketplace.upbound.io/) container registry.
+
+[Register with the Upbound Marketplace](https://accounts.upbound.io/register)
+to push packages and create private repositories.
+
+#### Flags
+
+{{< table "table table-sm table-striped">}}
+| Short flag | Long flag | Description |
+| ------------ | ------------- | ------------------------------ |
+| `-u` | `--username=` | Username to use for authentication. |
+| `-p` | `--password=` | Password to use for authentication. |
+| `-t` | `--token=` | User token string to use for authentication. |
+| `-a` | `--account=` | Specify an Upbound organization during authentication. |
+{{< /table >}}
+
+
+#### Authentication options
+
+The `crossplane xpkg login` command can use a username and password or Upbound API token.
+
+By default, `crossplane xpkg login` without arguments, prompts for a username
+and password.
+
+Provide a username and password with the `--username` and `--password` flags or
+set the environmental variable `UP_USER` for a username or `UP_PASSWORD` for the
+password.
+
+Use an Upbound user token instead of a username and password with `--token` or
+the `UP_TOKEN` environmental variable.
+
+{{< hint "important" >}}
+The `--token` or `UP_TOKEN` environmental variables take precedence over a
+username and password.
+{{< /hint >}}
+
+Using `-` as the input for `--password` or `--token` reads the input from stdin.
+For example, `crossplane xpkg login --password -`.
+
+After logging in the Crossplane CLI creates a `profile` in
+`.crossplane/config.json` to cache unprivileged account information.
+
+{{}}
+The `session` field of `config.json` file is a session cookie identifier.
+
+The `session` value isn't used for authentication. This isn't a `token`.
+{{< /hint >}}
+
+#### Authenticate with a registered Upbound organization
+
+Authenticate to a registered organization in the Upbound Marketplace with the
+`--account` option, along with the username and password or token.
+
+For example,
+`crossplane xpkg login --account=Upbound --username=my-user --password -`.
+
+### xpkg logout
+
+Use `crossplane xpkg logout` to invalidate the current `crossplane xpkg login`
+session.
+
+{{< hint "note" >}}
+Using `crossplane xpkg logout` removes the `session` from the
+`~/.crossplane/config.json` file, but doesn't delete the configuration file.
+{{< /hint >}}
+
+### xpkg push
+
+Push a Crossplane package file to a package registry.
+
+The Crossplane CLI pushes images to the
+[Upbound Marketplace](https://marketplace.upbound.io/) at `xpkg.upbound.io` by
+default.
+
+{{< hint "note" >}}
+Pushing a package may require authentication with
+[`crossplane xpkg login`](#xpkg-login)
+{{< /hint >}}
+
+Specify the organization, package name and tag with
+`crossplane xpkg push `
+
+By default the command looks in the current directory for a single `.xpkg` file
+to push.
+
+To push multiple files or to specify a specific `.xpkg` file use the `-f` flag.
+
+For example, to push a local package named `my-package` to
+`crossplane-docs/my-package:v0.14.0` use:
+
+`crossplane xpkg push -f my-package.xpkg crossplane-docs/my-package:v0.14.0`
+
+To push to another package registry, like [DockerHub](https://hub.docker.com/)
+provide the full URL along with the package name.
+
+For example, to push a local package named `my-package` to
+DockerHub organization `crossplane-docs/my-package:v0.14.0` use:
+`crossplane xpkg push -f my-package.xpkg index.docker.io/crossplane-docs/my-package:v0.14.0`.
+
+
+#### Flags
+
+{{< table "table table-sm table-striped">}}
+| Short flag | Long flag | Description |
+| ------------ | ------------- | ------------------------------ |
+| `-f` | `--package-files=PATH` | A comma-separated list of xpkg files to push. |
+{{< /table >}}
+
+### xpkg update
+
+The `crossplane xpkg update` command downloads and updates an existing package.
+
+By default the `crossplane xpkg update` command uses the Kubernetes
+configuration defined in `~/.kube/config`.
+
+Define a custom Kubernetes configuration file location with the environmental
+variable `KUBECONFIG`.
+
+Specify the package kind, package file and optionally the name of the package
+already installed in Crossplane.
+
+`crossplane xpkg update []`
+
+The package file must be an organization, image and tag on the `xpkg.upbound.io`
+registry on [Upbound Marketplace](https://marketplace.upbound.io/).
+
+For example, to update to version 0.42.0 of the
+[AWS S3 provider](https://marketplace.upbound.io/providers/upbound/provider-aws-s3/v0.42.0):
+
+`crossplane xpkg update provider xpkg.upbound.io/upbound/provider-aws-s3:v0.42.0`
+
+
+## beta
+
+Crossplane `beta` commands are experimental. These commands may change the
+flags, options or outputs in future releases.
+
+Crossplane maintainers may promote or remove commands under `beta` in future
+releases.
+
+### beta render
+
+The `crossplane beta render` command previews the output of a
+[composite resource]({{][}}) after applying
+any [composition functions]({{][}}).
+
+{{< hint "important" >}}
+The `crossplane beta render` command doesn't apply
+[patch and transform composition patches]({{][}}).
+
+The command only supports function "patch and transforms."
+{{< /hint >}}
+
+The `crossplane beta render` command connects to the locally running Docker
+Engine to pull and run composition functions.
+
+{{}}
+Running `crossplane beta render` requires [Docker](https://www.docker.com/).
+{{< /hint >}}
+
+Provide a composite resource, composition and composition function YAML
+definition with the command to render the output locally.
+
+For example,
+`crossplane beta render xr.yaml composition.yaml function.yaml`
+
+The output includes the original composite resource followed by the generated
+managed resources.
+
+{{}}
+```yaml
+---
+apiVersion: nopexample.org/v1
+kind: XBucket
+metadata:
+ name: test-xrender
+status:
+ bucketRegion: us-east-2
+---
+apiVersion: s3.aws.upbound.io/v1beta1
+kind: Bucket
+metadata:
+ annotations:
+ crossplane.io/composition-resource-name: my-bucket
+ generateName: test-xrender-
+ labels:
+ crossplane.io/composite: test-xrender
+ ownerReferences:
+ - apiVersion: nopexample.org/v1
+ blockOwnerDeletion: true
+ controller: true
+ kind: XBucket
+ name: test-xrender
+ uid: ""
+spec:
+ forProvider:
+ region: us-east-2
+```
+{{< /expand >}}
+
+#### Flags
+
+{{< table "table table-sm table-striped">}}
+| Short flag | Long flag | Description |
+| ------------ | ------------- | ------------------------------ |
+| | `--context-files==,=` | A comma separated list of files to load for function "contexts." |
+| | `--context-values==,=` | A comma separated list of key-value pairs to load for function "contexts." |
+| `-r` | `--include-function-results` | Include the "results" or events from the function. |
+| `-o` | `--observed-resources=` | Provide artificial managed resource data to the function. |
+| | `--timeout=` | Amount of time to wait for a function to finish. |
+{{< /table >}}
+
+The `crossplane beta render` command relies on standard
+[Docker environmental variables](https://docs.docker.com/engine/reference/commandline/cli/#environment-variables)
+to connect to the local Docker engine and run composition functions.
+
+
+#### Provide function context
+
+The `--context-files` and `--context-values` flags can provide data
+to a function's `context`.
+The context is JSON formatted data.
+
+#### Include function results
+
+If a function produces Kubernetes events with statuses use the
+`--include-function-results` to print them along with the managed resource
+outputs.
+
+#### Mock managed resources
+
+Provide mocked, or artificial data representing a managed resource with
+`--observed-resources`. The `crossplane beta render` command treats the
+provided inputs as if they were resources in a Crossplane cluster.
+
+A function can reference and manipulate the included resource as part of
+running the function.
+
+The `observed-resources` may be a single YAML file with multiple resources or a
+directory of YAML files representing multiple resources.
+
+Inside the YAML file include an
+{{}}apiVersion{{}},
+{{}}kind{{}},
+{{}}metadata{{}} and
+{{}}spec{{}}.
+
+```yaml {label="or"}
+apiVersion: example.org/v1alpha1
+kind: ComposedResource
+metadata:
+ name: test-render-b
+ annotations:
+ crossplane.io/composition-resource-name: resource-b
+spec:
+ coolerField: "I'm cooler!"
+```
+
+The schema of the resource isn't validated and may contain any data.
+
+
+### beta trace
+
+Use the `crossplane beta trace` command to display a visual relationship of
+Crossplane objects. The `trace` command supports claims, compositions or
+managed resources.
+
+The command requires a resource type and a resource name.
+
+`crossplane beta trace `
+
+For example to view a resource named `my-claim` of type `example.crossplane.io`:
+`crossplane beta trace example.crossplane.io my-claim`
+
+The command also accepts Kubernetes CLI style `/` input.
+For example,
+`crossplane beta trace example.crossplane.io/my-claim`
+
+By default the `crossplane beta trace` command uses the Kubernetes
+configuration defined in `~/.kube/config`.
+
+Define a custom Kubernetes configuration file location with the environmental
+variable `KUBECONFIG`.
+
+#### Flags
+{{< table "table table-sm table-striped">}}
+
+
+| Short flag | Long flag | Description |
+| ------------ | ------------- | ------------------------------ |
+| `-n` | `--namespace` | The namespace of the resource. |
+| `-o` | `--output=` | Change the graph output with `wide`, `json`, or `dot` for a [Graphviz dot](https://graphviz.org/docs/layouts/dot/) output. |
+| `-s` | `--show-connection-secrets` | Print any connection secret names. Doesn't print the secret values. |
+
+{{< /table >}}
+
+#### Output options
+
+By default `crossplane beta trace` prints directly to the terminal, limiting the
+"Ready" condition and "Status" messages to 64 characters.
+
+The following an example output a "cluster" claim from the AWS reference
+platform, which includes multiple Compositions and composed resources:
+
+```shell {copy-lines="1"}
+crossplane beta trace cluster.aws.platformref.upbound.io platform-ref-aws
+NAME SYNCED READY STATUS
+Cluster/platform-ref-aws (default) True True Available
+└─ XCluster/platform-ref-aws-mlnwb True True Available
+ ├─ XNetwork/platform-ref-aws-mlnwb-6nvkx True True Available
+ │ ├─ VPC/platform-ref-aws-mlnwb-ckblr True True Available
+ │ ├─ InternetGateway/platform-ref-aws-mlnwb-r7w47 True True Available
+ │ ├─ Subnet/platform-ref-aws-mlnwb-lhr4h True True Available
+ │ ├─ Subnet/platform-ref-aws-mlnwb-bss4b True True Available
+ │ ├─ Subnet/platform-ref-aws-mlnwb-fzbxx True True Available
+ │ ├─ Subnet/platform-ref-aws-mlnwb-vxbf4 True True Available
+ │ ├─ RouteTable/platform-ref-aws-mlnwb-cs9nl True True Available
+ │ ├─ Route/platform-ref-aws-mlnwb-vpxdg True True Available
+ │ ├─ MainRouteTableAssociation/platform-ref-aws-mlnwb-sngx5 True True Available
+ │ ├─ RouteTableAssociation/platform-ref-aws-mlnwb-hprsp True True Available
+ │ ├─ RouteTableAssociation/platform-ref-aws-mlnwb-shb8f True True Available
+ │ ├─ RouteTableAssociation/platform-ref-aws-mlnwb-hvb2h True True Available
+ │ ├─ RouteTableAssociation/platform-ref-aws-mlnwb-m58vl True True Available
+ │ ├─ SecurityGroup/platform-ref-aws-mlnwb-xxbl2 True True Available
+ │ ├─ SecurityGroupRule/platform-ref-aws-mlnwb-7qt56 True True Available
+ │ └─ SecurityGroupRule/platform-ref-aws-mlnwb-szgxp True True Available
+ ├─ XEKS/platform-ref-aws-mlnwb-fqjzz True True Available
+ │ ├─ Role/platform-ref-aws-mlnwb-gmpqv True True Available
+ │ ├─ RolePolicyAttachment/platform-ref-aws-mlnwb-t6rct True True Available
+ │ ├─ Cluster/platform-ref-aws-mlnwb-crrt8 True True Available
+ │ ├─ ClusterAuth/platform-ref-aws-mlnwb-dgn6f True True Available
+ │ ├─ Role/platform-ref-aws-mlnwb-tdnx4 True True Available
+ │ ├─ RolePolicyAttachment/platform-ref-aws-mlnwb-qzljh True True Available
+ │ ├─ RolePolicyAttachment/platform-ref-aws-mlnwb-l64q2 True True Available
+ │ ├─ RolePolicyAttachment/platform-ref-aws-mlnwb-xn2px True True Available
+ │ ├─ NodeGroup/platform-ref-aws-mlnwb-4sfss True True Available
+ │ ├─ OpenIDConnectProvider/platform-ref-aws-mlnwb-h26xx True True Available
+ │ └─ ProviderConfig/platform-ref-aws - -
+ └─ XServices/platform-ref-aws-mlnwb-bgndx True True Available
+ ├─ Release/platform-ref-aws-mlnwb-bcj7r True True Available
+ └─ Release/platform-ref-aws-mlnwb-7hfkv True True Available
+```
+
+#### Wide outputs
+Print the entire "Ready" or "Status" message if they're longer than
+64 characters with `--output=wide`.
+
+For example, the output truncates the "Status" message that's too long.
+
+```shell {copy-lines="1"
+crossplane trace cluster.aws.platformref.upbound.io platform-ref-aws
+NAME SYNCED READY STATUS
+Cluster/platform-ref-aws (default) True False Waiting: ...resource claim is waiting for composite resource to become Ready
+```
+
+Use `--output=wide` to see the full message.
+
+```shell {copy-lines="1"
+crossplane trace cluster.aws.platformref.upbound.io platform-ref-aws --output=wide
+NAME SYNCED READY STATUS
+Cluster/platform-ref-aws (default) True False Waiting: Composite resource claim is waiting for composite resource to become Ready
+```
+
+#### Graphviz dot file output
+
+Use the `--output=dot` to print out a textual
+[Graphviz dot](https://graphviz.org/docs/layouts/dot/) output.
+
+Save the output and export it or the output directly to Graphviz `dot` to
+render an image.
+
+For example, to save the output as a `graph.png` file use
+`dot -Tpng -o graph.png`.
+
+`crossplane beta trace cluster.aws.platformref.upbound.io platform-ref-aws -o dot | dot -Tpng -o graph.png`
+
+#### Print connection secrets
+
+Use `-s` to print any connection secret names along with the other resources.
+
+{{}}
+The `crossplane beta trace` command doesn't print secret values.
+{{< /hint >}}
+
+The output includes both the secret name along with the secret's namespace.
+
+```shell
+NAME SYNCED READY STATUS
+Cluster/platform-ref-aws (default) True True Available
+└─ XCluster/platform-ref-aws-mlnwb True True Available
+ ├─ XNetwork/platform-ref-aws-mlnwb-6nvkx True True Available
+ │ ├─ SecurityGroupRule/platform-ref-aws-mlnwb-szgxp True True Available
+ │ └─ Secret/3f11c30b-dd94-4f5b-aff7-10fe4318ab1f (upbound-system) - -
+ ├─ XEKS/platform-ref-aws-mlnwb-fqjzz True True Available
+ │ ├─ OpenIDConnectProvider/platform-ref-aws-mlnwb-h26xx True True Available
+ │ └─ Secret/9666eccd-929c-4452-8658-c8c881aee137-eks (upbound-system) - -
+ ├─ XServices/platform-ref-aws-mlnwb-bgndx True True Available
+ │ ├─ Release/platform-ref-aws-mlnwb-7hfkv True True Available
+ │ └─ Secret/d0955929-892d-40c3-b0e0-a8cabda55895 (upbound-system) - -
+ └─ Secret/9666eccd-929c-4452-8658-c8c881aee137 (upbound-system) - -
+```
+
+### beta xpkg init
+
+The `crossplane beta xpkg init` command populates the current directory with
+files to build a package.
+
+Provide a name to use for the package and the package template to start from
+with the command
+`crossplane beta xpkg init `
+
+The `` input isn't used. Crossplane reserves the `` for future releases.
+
+The `` value may be one of three well known templates:
+* `function-template-go` - A template to build Crossplane [composition functions]({{][}}) from the [crossplane/function-template-go](https://github.com/crossplane/function-template-go) repository.
+* `provider-template` - A template to build a basic Crossplane provider from the [Crossplane/provider-template](https://github.com/crossplane/provider-template) repository.
+* `provider-template-upjet` - A template for building [Upjet](https://github.com/crossplane/upjet) based Crossplane providers from existing Terraform providers. Copies from the [upbound/upjet-provider-template](https://github.com/upbound/upjet-provider-template) repository.
+
+Instead of a well known template the `` value can be a git repository
+URL.
+
+#### Flags
+{{< table "table table-sm table-striped">}}
+| Short flag | Long flag | Description |
+| ------------ | ------------- | ------------------------------ |
+| `-d` | `--directory` | The directory to create and load the template files into. Uses the current directory by default. |
+
+{{< /table >}}
+
diff --git a/content/v1.11/concepts/_index.md b/content/v1.14/concepts/_index.md
similarity index 97%
rename from content/v1.11/concepts/_index.md
rename to content/v1.14/concepts/_index.md
index ee3072485..4c41bfe47 100644
--- a/content/v1.11/concepts/_index.md
+++ b/content/v1.14/concepts/_index.md
@@ -53,4 +53,4 @@ learn more about all of these concepts in the [composition documentation].
[providers documentation]: {{][}}
[Upbound Marketplace]: https://marketplace.upbound.io
[managed resources documentation]: {{][}}
-[composition documentation]: {{][}}
+[composition documentation]: {{][}}
diff --git a/content/v1.14/concepts/claims.md b/content/v1.14/concepts/claims.md
new file mode 100644
index 000000000..bfda614bd
--- /dev/null
+++ b/content/v1.14/concepts/claims.md
@@ -0,0 +1,207 @@
+---
+title: Claims
+weight: 60
+description: "Claims are a way to consume Crossplane resources with namespace scoping"
+---
+
+Claims represents a set of managed resources as a single
+Kubernetes object, inside a namespace.
+
+Users create claims when they access the
+custom API, defined in the CompositeResourceDefinition.
+
+{{< hint "tip" >}}
+
+Claims are like [composite resources]({{][}}). The
+difference between Claims and composite resources is Crossplane can create
+Claims in a namespace, while composite resources are cluster scoped.
+{{< /hint >}}
+
+{{}}
+Crossplane has four core components that users commonly mix up:
+
+* [Compositions]({{][}}) - A template to define how to create resources.
+* [Composite Resource Definition]({{][}})
+ (`XRD`) - A custom API specification.
+* [Composite Resources]({{][}}) (`XR`) - Created by
+ using the custom API defined in a Composite Resource Definition. XRs use the
+ Composition template to create new managed resources.
+* Claims (`XRC`) - This page. Like a Composite Resource, but
+ with namespace scoping.
+{{]}}
+
+## Creating a Claim
+
+Creating a Claim requires a
+[Composition]({{[}}) and a
+[CompositeResourceDefinition]({{][}})
+(`XRD`) already installed.
+
+{{}}
+The XRD must
+[enable Claims]({{][}}).
+{{< /hint >}}
+
+The Composition defines the set of resources to create.
+The XRD defines the custom API users call to request the set of resources.
+
+![Diagram of the relationship of Crossplane components](/media/composition-how-it-works.svg)
+
+For example,
+this {{}}CompositeResourceDefinition{{}}
+creates a composite resource API endpoint
+{{}}xmydatabases.example.org{{}} and
+enables a Claim API endpoint
+{{}}database.example.org{{}}
+
+```yaml {label="xrd1",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: CompositeResourceDefinition
+metadata:
+ name: xmydatabases.example.org
+spec:
+ group: example.org
+ names:
+ kind: XMyDatabase
+ plural: xmydatabases
+ claimNames:
+ kind: Database
+ plural: databases
+ # Removed for brevity
+```
+
+The Claim uses the XRD's
+{{}}kind{{}} API endpoint to request
+resources.
+
+The Claim's {{}}apiVersion{{}} matches
+the XRD {{}}group{{}} and the
+{{}}kind{{}} matches the XRD
+{{}}claimNames.kind{{}}
+
+```yaml {label="claim1",copy-lines="none"}
+apiVersion: example.org/v1alpha1
+kind: database
+metadata:
+ name: my-claimed-database
+spec:
+ # Removed for brevity
+```
+
+When a user creates a Claim in a namespace Crossplane also creates a composite
+resource.
+
+Use {{}}kubectl describe{{}} on the
+Claim to view the related composite resource.
+
+The {{}}Resource Ref{{}} is the
+composite resource Crossplane created for this Claim.
+
+```shell {label="claimcomp",copy-lines="1"}
+kubectl describe database.example.org/my-claimed-database
+Name: my-claimed-database
+API Version: example.org/v1alpha1
+Kind: database
+Spec:
+ Resource Ref:
+ API Version: example.org/v1alpha1
+ Kind: XMyDatabase
+ Name: my-claimed-database-rr4ll
+# Removed for brevity.
+```
+
+Use {{}}kubectl describe{{}} on the
+composite resource to view the
+{{}}Claim Ref{{}} linking the
+composite resource to the original Claim.
+
+```shell {label="getcomp",copy-lines="1"}
+kubectl describe xmydatabase.example.org/my-claimed-database-rr4ll
+Name: my-claimed-database-rr4ll
+API Version: example.org/v1alpha1
+Kind: XMyDatabase
+Spec:
+ Claim Ref:
+ API Version: example.org/v1alpha1
+ Kind: database
+ Name: my-claimed-database
+ Namespace: default
+```
+
+{{}}
+Crossplane supports directly creating composite resources. Claims allow
+namespace scoping and isolation for users consuming the custom APIs.
+
+If you don't use namespaces in your Kubernetes deployment Claims aren't necessary.
+{{< /hint >}}
+
+### Claiming existing composite resources
+
+By default, creating a Claim creates a new composite resource. Claims can also
+link to existing composite resources.
+
+A use case for claiming existing composite resources may be slow to provision
+resources. Composite resources can be pre-provisioned and a Claim can
+use those resources without waiting for their creation.
+
+Set the Claim's {{}}resourceRef{{}}
+and match the pre-existing composite resource
+{{}}name{{}}.
+
+```yaml {label="resourceref",copy-lines="none"}
+apiVersion: example.org/v1alpha1
+kind: database
+metadata:
+ name: my-claimed-database
+spec:
+ resourceRef:
+ apiVersion: example.org/v1alpha1
+ kind: XMyDatabase
+ name: my-pre-created-xr
+```
+
+If a Claim specifies a
+{{}}resourceRef{{}} that doesn't
+exist, Crossplane doesn't create a composite resource.
+
+{{}}
+All Claims have a
+{{}}resourceRef{{}}. Manually
+defining the
+{{}}resourceRef{{}}
+isn't required. Crossplane fills in the
+{{}}resourceRef{{}}
+with the information from the composite resource created for the Claim.
+{{< /hint >}}
+
+## Claim connection secrets
+
+If a Claim expects connection secrets the Claim must define a
+{{}}writeConnectionSecretToRef{{}}
+object.
+
+The
+{{}}writeConnectionSecretToRef{{}}
+object defines the name of the Kubernetes secret object where Crossplane saves
+the connection details.
+
+{{}}
+The Crossplane creates the secret object in the same namespace as the Claim.
+{{< /hint >}}
+
+For example, to a new secret object named
+{{}}my-claim-secret{{}} use
+{{}}writeConnectionSecretToRef{{}} with
+the
+{{}}name: my-claim-secret{{}}.
+```yaml {label="claimSec"}
+apiVersion: example.org/v1alpha1
+kind: database
+metadata:
+ name: my-claimed-database
+spec:
+ writeConnectionSecretToRef:
+ name: my-claim-secret
+```
+
+For more information on connection secrets read the [Connection Secrets knowledge base article]({{][}}).
\ No newline at end of file
diff --git a/content/v1.14/concepts/composite-resource-definitions.md b/content/v1.14/concepts/composite-resource-definitions.md
new file mode 100644
index 000000000..6e4641328
--- /dev/null
+++ b/content/v1.14/concepts/composite-resource-definitions.md
@@ -0,0 +1,836 @@
+---
+title: Composite Resource Definitions
+weight: 40
+description: "Composite Resource Definitions or XRDs define custom API schemas"
+---
+
+Composite resource definitions (`XRDs`) define the schema for a custom API.
+Users create composite resources (`XRs`) and Claims (`XCs`) using the API
+schema defined by an `XRD`.
+
+
+{{< hint "note" >}}
+
+Read the [composite resources]({{][}}) page for more
+information about composite resources.
+
+Read the [Claims]({{][}}) page for more
+information about Claims.
+{{]}}
+
+
+{{}}
+Crossplane has four core components that users commonly mix up:
+
+* [Compositions]({{[}}) - A template to define how to create resources.
+* Composite Resource Definition (`XRD`) - This page. A custom API specification.
+* [Composite Resource]({{][}}) (`XR`) - Created by
+ using the custom API defined in a Composite Resource Definition. XRs use the
+ Composition template to create new managed resources.
+* [Claims]({{][}}) (`XRC`) - Like a Composite Resource, but
+ with namespace scoping.
+{{]}}
+
+Crossplane XRDs are like
+[Kubernetes custom resource definitions](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
+XRDs require fewer fields and add options related to Crossplane, like Claims and
+connection secrets.
+
+## Creating a CompositeResourceDefinition
+
+Creating a CompositeResourceDefinition consists of:
+* [Defining a custom API group](#xrd-groups).
+* [Defining a custom API name](#xrd-names).
+* [Defining a custom API schema and version](#xrd-versions).
+
+Optionally, CompositeResourceDefinitions also support:
+* [Offering a Claim](#enable-claims).
+* [Defining connection secrets](#manage-connection-secrets).
+* [Setting composite resource defaults](#set-composite-resource-defaults).
+
+Composite resource definitions (`XRDs`) create new API endpoints inside a
+Kubernetes cluster.
+
+Creating a new API requires defining an API
+{{}}group{{}},
+{{}}name{{}} and
+{{}}version{{}}.
+
+```yaml {label="xrd1",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: CompositeResourceDefinition
+metadata:
+ name: xmydatabases.example.org
+spec:
+ group: example.org
+ names:
+ kind: XMyDatabase
+ plural: xmydatabases
+ versions:
+ - name: v1alpha1
+ # Removed for brevity
+```
+
+After applying an XRD, Crossplane creates a new Kubernetes custom resource
+definition matching the defined API.
+
+For example, the XRD
+{{}}xmydatabases.example.org{{}}
+creates a custom resource definition
+{{}}xmydatabases.example.org{{}}.
+
+```shell {label="kubeapi",copy-lines="3"}
+kubectl api-resources
+NAME SHORTNAMES APIVERSION NAMESPACED KIND
+xmydatabases.example.org v1alpha1 false xmydatabases
+# Removed for brevity
+```
+
+{{}}
+You can't change the XRD
+{{}}group{{}} or
+{{}}names{{}}.
+You must delete and
+recreate the XRD to change the
+{{}}group{{}} or
+{{}}names{{}}.
+{{}}
+
+### XRD groups
+
+Groups define a collection of related API endpoints. The `group` can be any
+value, but common convention is to map to a fully qualified domain name.
+
+
+Many XRDs may use the same `group` to create a logical collection of APIs.
+
+For example a `database` group may have a `relational` and `nosql` kinds.
+
+{{}}
+Group names are cluster scoped. Choose group names that don't conflict with
+Providers.
+Avoid Provider names in the group.
+{{< /hint >}}
+
+### XRD names
+
+The `names` field defines how to refer to this specific XRD.
+The required name fields are:
+
+* `kind` - the `kind` value to use when calling this API. The kind is
+ [UpperCamelCased](https://kubernetes.io/docs/contribute/style/style-guide/#use-upper-camel-case-for-api-objects).
+ Crossplane recommends starting XRD `kinds` with an `X` to show
+ it's a custom Crossplane API definition.
+* `plural` - the plural name used for the API URL. The plural name must be
+ lowercase.
+
+{{}}
+The XRD
+{{}}metadata.name{{}} must be
+{{}}plural{{}} name, `.` (dot character),
+{{}}group{{}}.
+
+For example, {{}}xmydatabases.example.org{{}} matches the {{}}plural{{}} name
+{{}}xmydatabases{{}}, `.`
+{{}}group{{}} name,
+{{}}example.org{{}}.
+
+```yaml {label="xrdName",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: CompositeResourceDefinition
+metadata:
+ name: xmydatabases.example.org
+spec:
+ group: example.org
+ names:
+ kind: XMyDatabase
+ plural: xmydatabases
+ # Removed for brevity
+```
+{{}}
+
+### XRD versions
+
+
+The XRD `version` is like the
+[API versioning used by Kubernetes](https://kubernetes.io/docs/reference/using-api/#api-versioning).
+The version shows how mature or stable the API is and increments when changing,
+adding or removing fields in the API.
+
+
+Crossplane doesn't require specific versions or a specific version naming
+convention, but following
+[Kubernetes API versioning guidelines](https://kubernetes.io/docs/reference/using-api/#api-versioning)
+is strongly recommended.
+
+* `v1alpha1` - A new API that may change at any time.
+* `v1beta1` - An existing API that's considered stable. Breaking changes are
+ strongly discouraged.
+* `v1` - A stable API that doesn't have breaking changes.
+
+#### Define a schema
+
+
+
+The `schema` defines the names
+of the parameters, the data types of the parameters and which parameters are
+required or optional.
+
+
+
+{{}}
+All `schemas` follow the Kubernetes custom resource definition
+[OpenAPIv3 structural schema](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema).
+{{< /hint >}}
+
+Each
+{{}}version{{}} of the API has a unique
+{{}}schema{{}}.
+
+All XRD {{}}schemas{{}} validate against
+the {{}}openAPIV3Schema{{}}. The schema
+is an OpenAPI
+{{}}object{{}} with the
+{{}}properties{{}} of a
+{{}}spec{{}}
+{{}}object{{}}.
+
+Inside the {{}}spec.properties{{}} is the custom
+API definition.
+
+In this example, the key {{}}region{{}}
+is a {{}}string{{}}.
+
+```yaml {label="schema",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: CompositeResourceDefinition
+metadata:
+ name: xdatabases.custom-api.example.org
+spec:
+ group: custom-api.example.org
+ names:
+ kind: xDatabase
+ plural: xdatabases
+ versions:
+ - name: v1alpha1
+ schema:
+ openAPIV3Schema:
+ type: object
+ properties:
+ spec:
+ type: object
+ properties:
+ region:
+ type: string
+ # Removed for brevity
+```
+
+A composite resource using this API references the
+{{}}group/version{{}} and
+{{}}kind{{}}. The
+{{}}spec{{}} has the
+{{}}region{{}} key with a string value.
+
+```yaml {label="xr"}
+apiVersion: custom-api.example.org/v1alpha1
+kind: xDatabase
+metadata:
+ name: my-composite-resource
+spec:
+ region: "US"
+```
+
+
+{{}}
+The custom API defined inside the
+{{}}spec.properties{{}} is an OpenAPIv3
+specification. The
+[data models page](https://swagger.io/docs/specification/data-models/) of
+the Swagger documentation provides a list of examples using data types and input
+restrictions.
+
+The Kubernetes documentation lists
+[the set of special restrictions](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation)
+on what your OpenAPIv3 custom API can use.
+{{< /hint >}}
+
+{{}}
+
+Changing or expanding the XRD schema requires restarting the [Crossplane pod]({{[}}) to take effect.
+{{< /hint >}}
+
+##### Required fields
+
+By default all fields in a schema are optional. Define a parameter as required
+with the
+{{< hover label="required" line="25">}}required{{}} attribute.
+
+In this example the XRD requires
+{{< hover label="required" line="19">}}region{{}} and
+{{< hover label="required" line="21">}}size{{}} but
+{{< hover label="required" line="23">}}name{{}} is optional.
+```yaml {label="required",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: CompositeResourceDefinition
+metadata:
+ name: xdatabases.custom-api.example.org
+spec:
+ group: custom-api.example.org
+ names:
+ kind: xDatabase
+ plural: xdatabases
+ versions:
+ - name: v1alpha1
+ schema:
+ openAPIV3Schema:
+ type: object
+ properties:
+ spec:
+ type: object
+ properties:
+ region:
+ type: string
+ size:
+ type: string
+ name:
+ type: string
+ required:
+ - region
+ - size
+ # Removed for brevity
+```
+
+According to the OpenAPIv3 specification, the `required` field is per-object. If
+a schema contains multiple objects the schema may need multiple `required`
+fields.
+
+This XRD defines two objects:
+ 1. the top-level {{}}spec{{}} object
+ 2. a second {{}}location{{}} object
+
+The {{}}spec{{}} object
+{{}}requires{{}} the
+{{}}size{{}} and
+{{}}location{{}} but
+{{}}name{{}} is optional.
+
+Inside the required {{}}location{{}}
+object,
+{{}}country{{}} is
+{{}}required{{}} and
+{{}}zone{{}} is optional.
+
+```yaml {copy-lines="none",label="required2"}
+# Removed for brevity
+- name: v1alpha1
+ schema:
+ openAPIV3Schema:
+ type: object
+ properties:
+ spec:
+ type: object
+ properties:
+ size:
+ type: string
+ name:
+ type: string
+ location:
+ type: object
+ properties:
+ country:
+ type: string
+ zone:
+ type: string
+ required:
+ - country
+ required:
+ - size
+ - location
+```
+
+The Swagger "[Describing Parameters](https://swagger.io/docs/specification/describing-parameters/)"
+documentation has more examples.
+
+##### Crossplane reserved fields
+
+Crossplane doesn't allow the following fields in a schema:
+* `spec.resourceRef`
+* `spec.resourceRefs`
+* `spec.claimRef`
+* `spec.writeConnectionSecretToRef`
+* `status.conditions`
+* `status.connectionDetails`
+
+Crossplane ignores any fields matching the reserved fields.
+
+#### Serve and reference a schema
+
+To use a schema it must be
+{{}}served: true{{}}
+and
+{{}}referenceable: true{{}}.
+
+```yaml {label="served"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: CompositeResourceDefinition
+metadata:
+ name: xdatabases.custom-api.example.org
+spec:
+ group: custom-api.example.org
+ names:
+ kind: xDatabase
+ plural: xdatabases
+ versions:
+ - name: v1alpha1
+ served: true
+ referenceable: true
+ schema:
+ openAPIV3Schema:
+ type: object
+ properties:
+ spec:
+ type: object
+ properties:
+ region:
+ type: string
+```
+
+Composite resources can use any schema version set as
+{{}}served: true{{}}.
+Kubernetes rejects any composite resource using a schema version set as `served:
+false`.
+
+{{< hint "tip" >}}
+Setting a schema version as `served:false` causes errors for users using an older
+schema. This can be an effective way to identify and upgrade users before
+deleting the older schema version.
+{{< /hint >}}
+
+The {{}}referenceable: true{{}}
+field indicates which version of the schema Compositions use. Only one
+version can be `referenceable`.
+
+{{< hint "note" >}}
+Changing which version is `referenceable:true` requires [updating the `compositeTypeRef.apiVersion`]({{][}})
+of any Compositions referencing that XRD.
+{{< /hint >}}
+
+
+#### Multiple schema versions
+
+{{}}
+Crossplane supports defining multiple `versions`, but the schema of each version
+can't change any existing fields, also called "making a breaking change."
+
+Breaking schema changes between versions requires the use of [conversion webhooks](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#webhook-conversion).
+
+New versions may define new optional parameters, but new required fields are
+a "breaking change."
+
+
+
+
+Crossplane XRDs use Kubernetes custom resource definitions for versioning.
+Read the Kubernetes documentation on
+[versions in CustomResourceDefinitions](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)
+for more background on versions and breaking changes.
+
+
+Crossplane recommends implementing breaking schema changes as brand new XRDs.
+{{< /hint >}}
+
+For XRDs, to create a new version of an API add a new
+{{}}name{{}} in the
+{{}}versions{{}}
+list.
+
+For example, this XRD version
+{{}}v1alpha1{{}} only has the field
+{{}}region{{}}.
+
+A second version,
+{{}}v1{{}} expands the API to have both
+{{}}region{{}} and
+{{}}size{{}}.
+
+```yaml {label="ver",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: CompositeResourceDefinition
+metadata:
+ name: xdatabases.custom-api.example.org
+spec:
+ group: custom-api.example.org
+ names:
+ kind: xDatabase
+ plural: xdatabases
+ versions:
+ - name: v1alpha1
+ schema:
+ openAPIV3Schema:
+ type: object
+ properties:
+ spec:
+ type: object
+ properties:
+ region:
+ type: string
+ - name: v1
+ schema:
+ openAPIV3Schema:
+ type: object
+ properties:
+ spec:
+ type: object
+ properties:
+ region:
+ type: string
+ size:
+ type: string
+```
+
+{{}}
+
+Changing or expanding the XRD schema requires restarting the [Crossplane pod]({{][}}) to take effect.
+{{< /hint >}}
+
+### Enable Claims
+
+Optionally, XRDs can allow Claims to use the XRD API.
+
+{{}}
+
+Read the [Claims]({{][}}) page for more
+information about Claims.
+{{]}}
+
+XRDs offer Claims with a
+{{}}claimNames{{}} object.
+
+The {{}}claimNames{{}} defines a
+{{}}kind{{}} and
+{{}}plural{{}} like the XRD
+{{}}names{{}} object.
+Also like XRD
+{{}}names{{}}, use UpperCamelCase
+for the
+{{}}kind{{}} and lowercase for the
+{{}}plural{{}}.
+
+The Claim
+{{}}kind{{}} and
+{{}}plural{{}} must be unique. They
+can't match any other Claim or other XRD
+{{}}kind{{}}.
+
+{{}}
+Common Crossplane convention is to use
+{{}}claimNames{{}} that match the XRD
+{{}}names{{}}, but without the beginning
+"x."
+{{}}
+
+```yaml {label="claim",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: CompositeResourceDefinition
+metadata:
+ name: xdatabases.custom-api.example.org
+spec:
+ group: custom-api.example.org
+ names:
+ kind: xDatabase
+ plural: xdatabases
+ claimNames:
+ kind: Database
+ plural: databases
+ versions:
+ # Removed for brevity
+```
+
+{{}}
+You can't change the
+{{}}claimNames{{}}
+after they're defined. You must delete and
+recreate the XRD to change the
+{{}}claimNames{{}}.
+{{}}
+
+### Manage connection secrets
+
+When a composite resource creates managed resources, Crossplane provides any
+[connection secrets]({{[}})
+to the composite resource or Claim. This requires the creators of composite
+resources and Claims to know the secrets provided by a managed resource.
+In other cases, Crossplane administrators may not want to expose some or all the
+generated connection secrets.
+
+XRDs can define a list of
+{{}}connectionSecretKeys{{}}
+to limit what's provided to a composite resource or Claim.
+
+Crossplane only provides the keys listed in the
+{{}}connectionSecretKeys{{}}
+to the composite resource or Claim using this XRD. Any other connection
+secrets aren't passed to the composite resource or Claim.
+
+{{}}
+The keys listed in the
+{{}}connectionSecretKeys{{}} must match the
+key names listed in the Composition's `connectionDetails`.
+
+An XRD ignores any keys listed that aren't created by a managed resource.
+
+For more information read the
+[Composition documentation]({{][}}).
+{{< /hint >}}
+
+
+For example, an XRD passes the keys
+{{}}username{{}},
+{{}}password{{}} and
+{{}}address{{}}.
+
+Composite resources or Claims save these in the secret defined by their
+`writeConnectionSecretToRef` field.
+
+```yaml {label="key",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: CompositeResourceDefinition
+metadata:
+ name: xdatabases.custom-api.example.org
+spec:
+ group: custom-api.example.org
+ names:
+ kind: xDatabase
+ plural: xdatabases
+ connectionSecretKeys:
+ - username
+ - password
+ - address
+ versions:
+ # Removed for brevity
+```
+
+{{}}
+You can't change the `connectionSecretKeys` of an XRD. You must delete and
+recreate the XRD to change the `connectionSecretKeys`.
+{{}}
+
+For more information on connection secrets read the
+[Connection Secrets knowledge base article]({{][}}).
+
+### Set composite resource defaults
+XRDs can set default parameters for composite resources and Claims.
+
+
+#### defaultCompositeDeletePolicy
+
+The `defaultCompositeDeletePolicy` defines the deletion policy for composite
+resources and claims.
+
+Using a `defaultCompositeDeletePolicy: Background` policy deletes
+the composite resource or Claim and relies on Kubernetes to delete the remaining
+dependent objects, like managed resources or secrets.
+
+Using `defaultCompositeDeletePolicy: Foreground` causes Kubernetes to attach a
+`foregroundDeletion` finalizer to the composite resource or Claim. Kubernetes
+deletes all the dependent objects before deleting the composite resource or
+Claim.
+
+The default value is `defaultCompositeDeletePolicy: Background`.
+
+Set
+{{}}defaultCompositeDeletePolicy: Foreground{{}}
+to change the XRD deletion policy.
+
+```yaml {label="delete",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: CompositeResourceDefinition
+metadata:
+ name: xdatabases.custom-api.example.org
+spec:
+ defaultCompositeDeletePolicy: Foreground
+ group: custom-api.example.org
+ names:
+ # Removed for brevity
+ versions:
+ # Removed for brevity
+```
+
+
+#### defaultCompositionRef
+
+It's possible for multiple [Compositions]({{][}}) to
+reference the same XRD. If more than one Composition references the same XRD,
+the composite resource or Claim must select which Composition to use.
+
+An XRD can define the default Composition to use with the
+`defaultCompositionRef` value.
+
+Set a
+{{}}defaultCompositionRef{{}}
+to set the default Composition.
+
+```yaml {label="defaultComp",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: CompositeResourceDefinition
+metadata:
+ name: xdatabases.custom-api.example.org
+spec:
+ defaultCompositionRef:
+ name: myComposition
+ group: custom-api.example.org
+ names:
+ # Removed for brevity
+ versions:
+ # Removed for brevity
+```
+
+
+#### defaultCompositionUpdatePolicy
+
+
+Changes to a Composition generate a new Composition revision. By default all
+composite resources and Claims use the updated Composition revision.
+
+Set the XRD `defaultCompositionUpdatePolicy` to `Manual` to prevent composite
+resources and Claims from automatically using the new revision.
+
+The default value is `defaultCompositionUpdatePolicy: Automatic`.
+
+Set {{}}defaultCompositionUpdatePolicy: Manual{{}}
+to set the default Composition update policy for composite resources and Claims
+using this XRD.
+
+```yaml {label="compRev",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: CompositeResourceDefinition
+metadata:
+ name: xdatabases.custom-api.example.org
+spec:
+ defaultCompositionUpdatePolicy: Manual
+ group: custom-api.example.org
+ names:
+ # Removed for brevity
+ versions:
+ # Removed for brevity
+```
+
+
+#### enforcedCompositionRef
+
+To require all composite resources or Claims to use a specific Composition use
+the `enforcedCompositionRef` setting in the XRD.
+
+For example, to require all composite resources and Claims using this XRD to use
+the Composition
+{{}}myComposition{{}}
+set
+{{}}enforcedCompositionRef.name: myComposition{{}}.
+
+```yaml {label="defaultComp",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: CompositeResourceDefinition
+metadata:
+ name: xdatabases.custom-api.example.org
+spec:
+ enforcedCompositionRef:
+ name: myComposition
+ group: custom-api.example.org
+ names:
+ # Removed for brevity
+ versions:
+ # Removed for brevity
+```
+
+## Verify a CompositeResourceDefinition
+
+Verify an XRD with `kubectl get compositeresourcedefinition` or the short form,
+{{}}kubectl get xrd{{}}.
+
+```yaml {label="getxrd",copy-lines="1"}
+kubectl get xrd
+NAME ESTABLISHED OFFERED AGE
+xdatabases.custom-api.example.org True True 22m
+```
+
+The `ESTABLISHED` field indicates Crossplane installed the Kubernetes custom
+resource definition for this XRD.
+
+The `OFFERED` field indicates this XRD offers a Claim and Crossplane installed
+the Kubernetes custom resource definitions for the Claim.
+
+### XRD conditions
+Crossplane uses a standard set of `Conditions` for XRDs.
+View the conditions of a XRD under their `Status` with
+`kubectl describe xrd`.
+
+```yaml {copy-lines="none"}
+kubectl describe xrd
+Name: xpostgresqlinstances.database.starter.org
+API Version: apiextensions.crossplane.io/v1
+Kind: CompositeResourceDefinition
+# Removed for brevity
+Status:
+ Conditions:
+ Reason: WatchingCompositeResource
+ Status: True
+ Type: Established
+ Reason: WatchingCompositeResourceClaim
+ Status: True
+ Type: Offered
+# Removed for brevity
+```
+
+
+#### WatchingCompositeResource
+
+`Reason: WatchingCompositeResource` indicates Crossplane defined the new
+Kubernetes custom resource definitions related to the composite resource and is
+watching for the creation of new composite resources.
+
+```yaml
+Type: Established
+Status: True
+Reason: WatchingCompositeResource
+```
+
+
+#### TerminatingCompositeResource
+
+`Reason: TerminatingCompositeResource` indicates Crossplane is deleting the
+custom resource definitions related to the composite resource and is
+terminating the composite resource controller.
+
+```yaml
+Type: Established
+Status: False
+Reason: TerminatingCompositeResource
+```
+
+
+#### WatchingCompositeResourceClaim
+
+`Reason: WatchingCompositeResourceClaim` indicates Crossplane defined the new
+Kubernetes custom resource definitions related to the offered Claims and is
+watching for the creation of new Claims.
+
+```yaml
+Type: Offered
+Status: True
+Reason: WatchingCompositeResourceClaim
+```
+
+
+#### TerminatingCompositeResourceClaim
+
+`Reason: TerminatingCompositeResourceClaim` indicates Crossplane is deleting the
+custom resource definitions related to the offered Claims and is
+terminating the Claims controller.
+
+```yaml
+Type: Offered
+Status: False
+Reason: TerminatingCompositeResourceClaim
+```
\ No newline at end of file
diff --git a/content/v1.14/concepts/composite-resources.md b/content/v1.14/concepts/composite-resources.md
new file mode 100644
index 000000000..4eb0218b6
--- /dev/null
+++ b/content/v1.14/concepts/composite-resources.md
@@ -0,0 +1,471 @@
+---
+title: Composite Resources
+weight: 50
+description: "Composite resources, an XR or XRs, represent a collection of related cloud resources."
+---
+
+A composite resource represents a set of managed resources as a single
+Kubernetes object. Crossplane creates composite resources when users access a
+custom API, defined in the CompositeResourceDefinition.
+
+{{}}
+Composite resources are a _composite_ of managed resources.
+A _Composition_ defines how to _compose_ the managed resources together.
+{{< /hint >}}
+
+{{}}
+Crossplane has four core components that users commonly mix up:
+
+* [Compositions]({{][}}) - A template to define how to create resources.
+* [Composite Resource Definition]({{][}})
+ (`XRD`) - A custom API specification.
+* Composite Resource (`XR`) - This page. Created by
+ using the custom API defined in a Composite Resource Definition. XRs use the
+ Composition template to create new managed resources.
+* [Claims]({{][}}) (`XRC`) - Like a Composite Resource, but
+ with namespace scoping.
+{{]}}
+
+## Creating composite resources
+
+Creating composite resources requires a
+[Composition]({{[}}) and a
+[CompositeResourceDefinition]({{][}})
+(`XRD`).
+The Composition defines the set of resources to create.
+The XRD defines the custom API users call to request the set of resources.
+
+![Diagram of the relationship of Crossplane components](/media/composition-how-it-works.svg)
+
+XRDs define the API used to create a composite resource.
+For example,
+this {{}}CompositeResourceDefinition{{}}
+creates a custom API endpoint
+{{}}xmydatabases.example.org{{}}.
+
+```yaml {label="xrd1",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: CompositeResourceDefinition
+metadata:
+ name: xmydatabases.example.org
+spec:
+ group: example.org
+ names:
+ kind: xMyDatabase
+ plural: xmydatabases
+ # Removed for brevity
+```
+
+When a user calls the custom API,
+{{}}xmydatabases.example.org{{}},
+Crossplane chooses the Composition to use based on the Composition's
+{{}}compositeTypeRef{{}}
+
+```yaml {label="typeref",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ name: my-composition
+spec:
+ compositeTypeRef:
+ apiVersion: example.org/v1alpha1
+ kind: xMyDatabase
+ # Removed for brevity
+```
+
+The Composition
+{{}}compositeTypeRef{{}} matches the
+XRD {{}}group{{}} and
+{{}}kind{{}}.
+
+Crossplane creates the resources defined in the matching Composition and
+represents them as a single `composite` resource.
+
+```shell{copy-lines="1"}
+kubectl get composite
+NAME SYNCED READY COMPOSITION AGE
+my-composite-resource True True my-composition 4s
+```
+
+### Naming external resources
+By default, managed resources created by a composite resource have the name of
+the composite resource, followed by a random suffix.
+
+
+
+For example, a composite resource named "my-composite-resource" creates external
+resources named "my-composite-resource-fqvkw."
+
+
+
+Resource names can be deterministic by applying an
+{{}}annotation{{}} to the composite
+resource.
+
+```yaml {label="annotation",copy-lines="none"}
+apiVersion: example.org/v1alpha1
+kind: xMyDatabase
+metadata:
+ name: my-composite-resource
+ annotations:
+ crossplane.io/external-name: my-custom-name
+# Removed for brevity
+```
+
+Inside the Composition, use a
+{{}}patch{{}}
+to apply the external-name to the resources.
+
+The {{}}fromFieldPath{{}} patch copies the
+{{}}metadata.annotations{{}} field from
+the composite resource to the
+{{}}metadata.annotations{{}} inside the
+managed resource.
+
+{{}}
+If a managed resource has the `crossplane.io/external-name` annotation
+Crossplane uses the annotation value to name the external resource.
+{{}}
+
+```yaml {label="comp",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ name: my-composition
+spec:
+ resources:
+ - name: database
+ base:
+ # Removed for brevity
+ patches:
+ - fromFieldPath: metadata.annotations
+ toFieldPath: metadata.annotations
+```
+
+For more information on patching resources refer to the [Patch and Transform]({{][}}) documentation.
+
+### Composition selection
+
+Select a specific Composition for a composite resource to use with
+{{}}compositionRef{{}}
+
+{{}}
+The selected Composition must allow the composite resource to use it with a
+`compositeTypeRef`. Read more about the `compositeTypeRef` field in the
+[Enabling Composite Resources]({{][}})
+section of the Composition documentation.
+{{< /hint >}}
+
+```yaml {label="compref",copy-lines="none"}
+apiVersion: example.org/v1alpha1
+kind: xMyDatabase
+metadata:
+ name: my-composite-resource
+spec:
+ compositionRef:
+ name: my-other-composition
+ # Removed for brevity
+```
+
+A composite resource can also select a Composition based on labels instead of
+the exact name with a
+{{}}compositionSelector{{}}.
+
+Inside the {{}}matchLabels{{}} section
+provide one or more Composition labels to match.
+
+```yaml {label="complabel",copy-lines="none"}
+apiVersion: example.org/v1alpha1
+kind: xMyDatabase
+metadata:
+ name: my-composite-resource
+spec:
+ compositionSelector:
+ matchLabels:
+ environment: production
+ # Removed for brevity
+```
+
+### Composition revision policy
+
+Crossplane tracks changes to Compositions as
+[Composition revisions]({{][}}) .
+
+A composite resource can use
+a {{}}compositionUpdatePolicy{{}} to
+manually or automatically reference newer Composition revisions.
+
+The default
+{{}}compositionUpdatePolicy{{}} is
+"Automatic." Composite resources automatically use the latest Composition
+revision.
+
+Change the policy to
+{{}}Manual{{}} to prevent composite
+resources from automatically upgrading.
+
+```yaml {label="comprev",copy-lines="none"}
+apiVersion: example.org/v1alpha1
+kind: xMyDatabase
+metadata:
+ name: my-composite-resource
+spec:
+ compositionUpdatePolicy: Manual
+ # Removed for brevity
+```
+
+### Composition revision selection
+
+Crossplane records changes to Compositions as
+[Composition revisions]({{][}}).
+A composite resource can
+select a specific Composition revision.
+
+
+Use {{}}compositionRevisionRef{{}} to
+select a specific Composition revision by name.
+
+For example, to select a specific Composition revision use the name of the
+desired Composition revision.
+
+```yaml {label="comprevref",copy-lines="none"}
+apiVersion: example.org/v1alpha1
+kind: xMyDatabase
+metadata:
+ name: my-composite-resource
+spec:
+ compositionUpdatePolicy: Manual
+ compositionRevisionRef:
+ name: my-composition-b5aa1eb
+ # Removed for brevity
+```
+
+{{}}
+Find the Composition revision name from
+{{}}kubectl get compositionrevision{{}}
+
+```shell {label="getcomprev",copy-lines="1"}
+kubectl get compositionrevision
+NAME REVISION XR-KIND XR-APIVERSION AGE
+my-composition-5c976ad 1 xmydatabases example.org/v1alpha1 65m
+my-composition-b5aa1eb 2 xmydatabases example.org/v1alpha1 64m
+```
+{{< /hint >}}
+
+A Composite resource can also select Composition revisions based on labels
+instead of the exact name with a
+{{}}compositionRevisionSelector{{}}.
+
+Inside the {{}}matchLabels{{}}
+section provide one or more Composition revision labels to match.
+
+
+```yaml {label="comprevsel",copy-lines="none"}
+apiVersion: example.org/v1alpha1
+kind: xMyDatabase
+metadata:
+ name: my-composite-resource
+spec:
+ compositionRevisionSelector:
+ matchLabels:
+ channel: dev
+ # Removed for brevity
+```
+
+### Manage connection secrets
+
+When a composite resource creates resources, Crossplane provides any
+[connection secrets]({{][}})
+to the composite resource.
+
+{{}}
+
+A resource may only access connection secrets allowed by the XRD. By
+default XRDs provide access to all connection secrets generated by managed
+resources.
+Read more about [managing connection secrets]({{][}})
+in the XRD documentation.
+{{< /hint >}}
+
+Use
+{{}}writeConnectionSecretToRef{{}}
+to specify where the composite resource writes their connection secrets to.
+
+For example, this composite resource saves the connection secrets in a
+Kubernetes secret object named
+{{}}my-secret{{}} in the namespace
+{{}}crossplane-system{{}}.
+
+```yaml {label="writesecret",copy-lines="none"}
+apiVersion: example.org/v1alpha1
+kind: xMyDatabase
+metadata:
+ name: my-composite-resource
+spec:
+ writeConnectionSecretToRef:
+ name: my-secret
+ namespace: crossplane-system
+ # Removed for brevity
+```
+
+Composite resources can write connection secrets to an
+[external secret store]({{][}}),
+like HashiCorp Vault.
+
+{{}}
+External secret stores are an alpha feature. Alpha features aren't enabled by
+default.
+{{< /hint >}}
+
+Use the {{}}publishConnectionDetailsTo{{}} field to save connection
+secrets to an external secrets store.
+
+```yaml {label="publishsecret",copy-lines="none"}
+apiVersion: example.org/v1alpha1
+kind: xMyDatabase
+metadata:
+ name: my-composite-resource
+spec:
+ publishConnectionDetailsTo:
+ name: my-external-secret-store
+ # Removed for brevity
+```
+
+Read the [External Secrets Store]({{][}}) documentation for more information on using
+external secret stores.
+
+For more information on connection secrets read the [Connection Secrets knowledge base article]({{][}}).
+
+### Pausing composite resources
+
+
+Crossplane supports pausing composite resources. A paused composite resource
+doesn't check or make changes on its external resources.
+
+
+To pause a composite resource apply the
+{{}}crossplane.io/paused{{}} annotation.
+
+```yaml {label="pause",copy-lines="none"}
+apiVersion: example.org/v1alpha1
+kind: xMyDatabase
+metadata:
+ name: my-composite-resource
+ annotations:
+ crossplane.io/paused: "true"
+spec:
+ # Removed for brevity
+```
+
+## Verify composite resources
+Use
+{{}}kubectl get composite{{}}
+to view all the composite resources Crossplane created.
+
+```shell{copy-lines="1",label="getcomposite"}
+kubectl get composite
+NAME SYNCED READY COMPOSITION AGE
+my-composite-resource True True my-composition 4s
+```
+
+Use `kubectl get` for the specific custom API endpoint to view
+only those resources.
+
+```shell {copy-lines="1"}
+kubectl get xMyDatabase.example.org
+NAME SYNCED READY COMPOSITION AGE
+my-composite-resource True True my-composition 12m
+```
+
+Use
+{{}}kubectl describe composite{{}}
+to view the linked
+{{}}Composition Ref{{}},
+and unique managed resources created in the
+{{}}Resource Refs{{}}.
+
+
+```yaml {copy-lines="1",label="desccomposite"}
+kubectl describe composite my-composite-resource
+Name: my-composite-resource
+API Version: example.org/v1alpha1
+Kind: xMyDatabase
+Spec:
+ Composition Ref:
+ Name: my-composition
+ Composition Revision Ref:
+ Name: my-composition-cf2d3a7
+ Composition Update Policy: Automatic
+ Resource Refs:
+ API Version: s3.aws.upbound.io/v1beta1
+ Kind: Bucket
+ Name: my-composite-resource-fmrks
+ API Version: dynamodb.aws.upbound.io/v1beta1
+ Kind: Table
+ Name: my-composite-resource-wnr9t
+# Removed for brevity
+```
+
+### Composite resource conditions
+
+The conditions of composite resources match the conditions of their managed
+resources.
+
+Read the
+[conditions section]({{][}}) of the
+managed resources documentation for details.
+
+## Composite resource labels
+
+Crossplane adds labels to composite resources to show their relationship to
+other Crossplane components.
+
+### Composite label
+Crossplane adds the
+{{}} crossplane.io/composite{{}} label
+to all composite resources. The label matches the name of the composite.
+Crossplane applies the composite label to any manged resource created by a
+composite, creating a reference between the managed resource and owning
+composite resource.
+
+```shell {label="claimname",copy-lines="1"}
+kubectl describe xmydatabase.example.org/my-claimed-database-x9rx9
+Name: my-claimed-database2-x9rx9
+Namespace:
+Labels: crossplane.io/composite=my-claimed-database-x9rx9
+```
+
+### Claim name label
+Crossplane adds the
+{{}}crossplane.io/claim-name{{}}
+label to composite resources created from a Claim. The label indicates the name
+of the Claim linked to this composite resource.
+
+```shell {label="claimname",copy-lines="1"}
+kubectl describe xmydatabase.example.org/my-claimed-database-x9rx9
+Name: my-claimed-database2-x9rx9
+Namespace:
+Labels: crossplane.io/claim-name=my-claimed-database
+```
+
+Composite resources created directly, without using a Claim, don't have a
+{{}}crossplane.io/claim-name{{}}
+label.
+
+### Claim namespace label
+Crossplane adds the
+{{}}crossplane.io/claim-namespace{{}}
+label to composite resources created from a Claim. The label indicates the
+namespace of the Claim linked to this composite resource.
+
+```shell {label="claimname",copy-lines="1"}
+kubectl describe xmydatabase.example.org/my-claimed-database-x9rx9
+Name: my-claimed-database2-x9rx9
+Namespace:
+Labels: crossplane.io/claim-namespace=default
+```
+
+Composite resources created directly, without using a Claim, don't have a
+{{}}crossplane.io/claim-namespace{{}}
+label.
\ No newline at end of file
diff --git a/content/v1.14/concepts/composition-functions.md b/content/v1.14/concepts/composition-functions.md
new file mode 100644
index 000000000..8c668e773
--- /dev/null
+++ b/content/v1.14/concepts/composition-functions.md
@@ -0,0 +1,700 @@
+---
+title: Composition Functions
+state: beta
+alphaVersion: "1.11"
+betaVersion: "1.14"
+weight: 80
+description: "Composition Functions allow you to template resources using general-purpose programming languages"
+aliases:
+ - /knowledge-base/guides/composition-functions
+---
+
+Composition functions (or just functions, for short) are custom programs that
+template Crossplane resources. Crossplane calls composition functions to
+determine what resources it should create when you create a composite resource
+(XR). You can write a function to template resources using a general purpose
+programming language like Go or Python. Using a general purpose programming
+language allows a Function to use more advanced logic to template resources,
+like loops and conditionals.
+
+You can build a function using general purpose programming languages such as Go
+or Python. The Crossplane community has also built functions that let you
+template Crossplane resources using [CUE](https://cuelang.org), Helm-like
+[Go templates](https://pkg.go.dev/text/template) or
+[Patch and Transforms]({{][}}).
+
+## Install a composition function
+
+Installing a Function creates a function pod. Crossplane sends requests to this
+pod to ask it what resources to create when you create a composite resource.
+
+Install a Function with a Crossplane
+{{}}Function{{}} object setting the
+{{}}spec.package{{}} value to the
+location of the function package.
+
+
+For example, to install [Function Patch and Transform](https://github.com/crossplane-contrib/function-patch-and-transform),
+
+```yaml {label="install"}
+apiVersion: pkg.crossplane.io/v1beta1
+kind: Function
+metadata:
+ name: function-patch-and-transform
+spec:
+ package: xpkg.upbound.io/crossplane-contrib/function-patch-and-transform:v0.1.4
+```
+
+{{< hint "tip" >}}
+Functions are Crossplane Packages. Read more about Packages in the
+[Packages documentation]({{][}}).
+{{< /hint >}}
+
+By default, the Function pod installs in the same namespace as Crossplane
+(`crossplane-system`).
+
+## Verify a composition function
+
+View the status of a Function with `kubectl get functions`
+
+During the install a Function reports `INSTALLED` as `True` and `HEALTHY` as
+`Unknown`.
+
+```shell {copy-lines="1"}
+kubectl get functions
+NAME INSTALLED HEALTHY PACKAGE AGE
+function-patch-and-transform True Unknown xpkg.upbound.io/crossplane-contrib/function-patch-and-transform:v0.1.4 10s
+```
+
+After the Function install completes and it's ready for use the `HEALTHY` status
+reports `True`.
+
+## Use a function in a composition
+
+Crossplane calls a Function to determine what resources it should create when
+you create a composite resource. The Function also tells Crossplane what to do
+with these resources when a you update or delete a composite resource.
+
+When Crossplane calls a Function it sends it the current state of the composite
+resource. It also sends it the current state of any managed resources the
+composite resource owns.
+
+Crossplane knows what Function to call when a composite resource changes by
+looking at the Composition the composite resource uses.
+
+{{}}
+Crossplane has four core components that users commonly mix up:
+
+* [Composition]({{][}}) - A template to define how to create
+ resources.
+* [CompositeResourceDefinition]({{][}})
+ (`XRD`) - A custom API specification.
+* [Composite Resource]({{][}}) (`XR`) - Created by
+ using the custom API defined in a CompositeResourceDefinition. XRs use the
+ Composition template to create new managed resources.
+* [Claim]({{][}}) (`XRC`) - Like a Composite Resource, but with
+ namespace scoping.
+{{]}}
+
+To use composition functions set the Composition
+{{}}mode{{}} to
+{{}}Pipeline{{}}.
+
+Define a {{}}pipeline{{}} of
+{{}}steps{{}}. Each
+{{}}step{{}} calls a Function.
+
+Each {{}}step{{}} uses a
+{{}}functionRef{{}} to reference the
+{{}}name{{}} of the Function to call.
+
+{{}}
+Compositions using {{}}mode: Pipeline{{}}
+can't specify resource templates with a `resources` field.
+
+Use function "Patch and Transform" to create resource templates.
+{{< /hint >}}
+
+
+Some Functions also allow you to specify an
+{{}}input{{}}.
+The function defines the
+{{}}kind{{}} of input.
+
+This example uses
+[Function Patch and Transform](https://github.com/crossplane-contrib/function-patch-and-transform).
+Function Patch and Transform implements Crossplane resource
+templates.
+The input kind is {{}}Resources{{}},
+and it accepts [Patch and Transform]({{[}})
+{{}}resources{{}} as input.
+
+```yaml {label="single",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ # Removed for Brevity
+ mode: Pipeline
+ pipeline:
+ - step: patch-and-transform
+ functionRef:
+ name: function-patch-and-transform
+ input:
+ apiVersion: pt.fn.crossplane.io/v1beta1
+ kind: Resources
+ resources:
+ - name: storage-bucket
+ base:
+ apiVersion: s3.aws.upbound.io/v1beta1
+ kind: Bucket
+ spec:
+ forProvider:
+ region: "us-east-2"
+```
+
+
+## Use a pipeline of functions in a composition
+
+Crossplane can ask more than one Function what to do when a composite resource
+changes. When a Composition has a pipeline of two or more steps, Crossplane
+calls them all. It calls them in the order they appear in the pipeline.
+
+Crossplane passes each Function in the pipeline the result of the previous
+Function. This enables powerful combinations of Functions. In this example,
+Crossplane calls {{}}function-cue{{}} to
+create an S3 bucket. Crossplane then passes the bucket to
+{{}}function-auto-ready{{}}, which marks the
+composite resource as ready when the bucket becomes ready.
+
+```yaml {label="double",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ # Removed for Brevity
+ mode: Pipeline
+ pipeline:
+ - step: cue-export-resources
+ functionRef:
+ name: function-cue
+ input:
+ apiVersion: cue.fn.crossplane.io/v1beta1
+ kind: CUEInput
+ name: storage-bucket
+ export:
+ target: Resources
+ value: |
+ apiVersion: "s3.aws.upbound.io/v1beta1"
+ kind: "Bucket"
+ spec: forProvider: region: "us-east-2"
+ - step: automatically-detect-readiness
+ functionRef:
+ name: function-auto-ready
+```
+
+## Test a composition that uses functions
+
+You can preview the output of any composition that uses composition functions
+using the Crossplane CLI. You don't need a Crossplane control plane to do
+this. The Crossplane CLI uses Docker Engine to run functions.
+
+
+{{}}
+See the [Crossplane CLI docs](https://github.com/crossplane/docs/pull/584) to
+learn how to install and use the Crossplane CLI.
+{{< /hint >}}
+
+{{}}
+Running `crossplane beta render` requires [Docker](https://www.docker.com).
+{{< /hint >}}
+
+Provide a composite resource, composition and composition functions to render
+the output locally.
+
+```shell
+crossplane beta render xr.yaml composition.yaml functions.yaml
+```
+
+`crossplane beta render` prints resources as YAML to stdout. It prints the
+composite resource first, followed by the resources the composition functions
+created.
+
+```yaml
+---
+apiVersion: example.crossplane.io/v1
+kind: XBucket
+metadata:
+ name: example-render
+---
+apiVersion: s3.aws.upbound.io/v1beta1
+kind: Bucket
+metadata:
+ annotations:
+ crossplane.io/composition-resource-name: storage-bucket
+ generateName: example-render-
+ labels:
+ crossplane.io/composite: example-render
+ ownerReferences:
+ - apiVersion: example.crossplane.io/v1
+ blockOwnerDeletion: true
+ controller: true
+ kind: XBucket
+ name: example-render
+ uid: ""
+spec:
+ forProvider:
+ region: us-east-2
+```
+
+{{}}
+
+You can recreate the output below using by running `crossplane beta render` with
+these files.
+
+The `xr.yaml` file contains the composite resource to render:
+
+```yaml
+apiVersion: example.crossplane.io/v1
+kind: XBucket
+metadata:
+ name: example-render
+spec:
+ bucketRegion: us-east-2
+```
+
+The `composition.yaml` file contains the Composition to use to render the
+composite resource:
+
+```yaml
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ name: example-render
+spec:
+ compositeTypeRef:
+ apiVersion: example.crossplane.io/v1
+ kind: XBucket
+ mode: Pipeline
+ pipeline:
+ - step: patch-and-transform
+ functionRef:
+ name: function-patch-and-transform
+ input:
+ apiVersion: pt.fn.crossplane.io/v1beta1
+ kind: Resources
+ resources:
+ - name: storage-bucket
+ base:
+ apiVersion: s3.aws.upbound.io/v1beta1
+ kind: Bucket
+ patches:
+ - type: FromCompositeFieldPath
+ fromFieldPath: spec.bucketRegion
+ toFieldPath: spec.forProvider.region
+```
+
+The `functions.yaml` file contains the Functions the Composition references in
+its pipeline steps:
+
+```yaml
+---
+apiVersion: pkg.crossplane.io/v1beta1
+kind: Function
+metadata:
+ name: function-patch-and-transform
+spec:
+ package: xpkg.upbound.io/crossplane-contrib/function-patch-and-transform:v0.1.4
+```
+{{}}
+
+The Crossplane CLI uses Docker Engine to run functions. You can change how the
+Crossplane CLI run a function by adding an annotation in `functions.yaml`. Add
+the `render.crossplane.io/runtime` annotation to a Function to change how it's
+run.
+
+`crossplane beta render` supports two `render.crossplane.io/runtime` values:
+
+* `Docker` (the default) connects to Docker Engine. It uses Docker to pull and
+ run a function runtime.
+* `Development` connects to a function runtime you have run manually.
+
+When you use the {{}}Development{{}}
+runtime the Crossplane CLI ignores the Function's {{}}package{{}}. Instead it expects you to make sure the function
+is listening on localhost port 9443. The function must be listening without gRPC
+transport security. Most function SDKs let you run a function with the
+`--insecure` flag to disable transport security. For example you can run a Go
+function locally using `go run . --insecure`.
+
+```yaml {label="development"}
+apiVersion: pkg.crossplane.io/v1beta1
+kind: Function
+metadata:
+ name: function-patch-and-transform
+ annotation:
+ render.crossplane.io/runtime: Development
+spec:
+ package: xpkg.upbound.io/crossplane-contrib/function-patch-and-transform:v0.1.4
+```
+
+{{}}
+Use the `Development` runtime when you
+[write a composition function](#write-a-composition-function) to test your
+function end-to-end.
+{{}}
+
+`crossplane beta render` also supports the following Function annotations. These
+annotations affect how it runs Functions:
+
+* `render.crossplane.io/runtime-docker-cleanup` - When using the `Docker`
+runtime this annotation specifies whether the CLI should stop the function
+container after it calls the function. It supports the values `Stop`, to stop
+the container, and `Orphan`, to leave it running.
+* `render.crossplane.io/runtime-docker-pull-policy` - When using the `Docker`
+ runtime this annotation specifies when the CLI should pull the Function's
+ package. It supports the values `Always`, `Never`, and `IfNotPresent`.
+* `render.crossplane.io/runtime-development-target` - When using the
+ `Development` runtime this annotation tells the CLI to connect to a Function
+ running at the specified target. It uses
+ [gRPC target syntax](https://github.com/grpc/grpc/blob/v1.59.1/doc/naming.md).
+
+## Write a composition function
+
+Composition functions let you replace complicated Compositions with code written
+in your programming language of choice. Crossplane has tools, software
+development kits (SDKs) and templates to help you write a function.
+
+
+
+Here's an example of a tiny, hello world function. This example is written in
+[Go](https://go.dev).
+
+
+```go
+func (f *Function) RunFunction(_ context.Context, req *fnv1beta1.RunFunctionRequest) (*fnv1beta1.RunFunctionResponse, error) {
+ rsp := response.To(req, response.DefaultTTL)
+ response.Normal(rsp, "Hello world!")
+ return rsp, nil
+}
+```
+
+Some people design composition functions for you to use them with any kind of
+composite resource.
+[Function Patch and Transform](https://github.com/crossplane-contrib/function-patch-and-transform)
+and
+[Function Auto Ready](https://github.com/crossplane-contrib/function-auto-ready)
+work with any kind of composite resource.
+
+Another common pattern is to write a composition function specific to one kind
+of composite resource. The function contains all the logic needed to tell
+Crossplane what resources to create when you create a composite resource. When
+you write a composition function like this, your Composition can be small. It
+just tells Crossplane what function to run when you create, update, or delete a
+composite resource.
+
+This Composition tells Crossplane to call {{}}function-xr-xbucket{{}} whenever you create, update, or
+delete an {{}}XBucket{{}} composite
+resource. `function-xr-xbucket` is hard coded to handle `XBucket` composite
+resources.
+
+```yaml {label="dedicated"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ name: example-bucket-function
+spec:
+ compositeTypeRef:
+ apiVersion: example.crossplane.io/v1
+ kind: XBucket
+ mode: Pipeline
+ pipeline:
+ - step: handle-xbucket-xr
+ functionRef:
+ name: function-xr-xbucket
+```
+
+To write a composition function, you:
+
+1. Create the function from a template.
+1. Edit the template to add the function's logic.
+1. [Test the function](#test-a-composition-that-uses-functions).
+1. Build the function, and push it to a package registry.
+
+You use the [Crossplane CLI](https://github.com/crossplane/docs/pull/584) to
+create, test, build, and push a function. For example,
+
+```shell {copy-lines=none}
+# Create the function from a template.
+crossplane beta xpkg init function-example function-template-go
+Initialized package "function-example" in directory "/home/negz/control/negz/function-example" from https://github.com/crossplane/function-template-go/tree/91a1a5eed21964ff98966d72cc6db6f089ad63f4 (main)
+
+$ ls
+Dockerfile fn.go fn_test.go go.mod go.sum input LICENSE main.go package README.md renovate.json
+
+# Edit the template to add your function's logic
+$ vim fn.go
+
+# Build the function.
+$ docker build . --quiet --tag runtime
+sha256:2c31b0f7a34b34ba5b0b2dacc94c360d18aca1b99f56ca4f40a1f26535a7c1c4
+
+# Package the function.
+$ crossplane xpkg build -f package --embed-runtime-image=runtime
+
+# Test the function.
+$ go run . --insecure
+$ crossplane beta render xr.yaml composition.yaml functions.yaml
+
+# Push the function package to xpkg.upbound.io.
+$ crossplane xpkg push -f package/*.xpkg crossplane-contrib/function-example:v0.1.0
+```
+
+{{}}
+Crossplane has
+[language specific guides]({{][}}) to writing
+a composition function. Refer to the guide for your preferred language for a
+more detailed guide to writing a function.
+{{]}}
+
+When you're writing a composition function it's useful to know how composition
+functions work. Read the next section to learn
+[how composition functions work](#how-composition-functions-work).
+
+## How composition functions work
+
+Each composition function is actually a [gRPC](https://grpc.io) server. gRPC is
+a high performance, open source remote procedure call (RPC) framework. When you
+[install a function](#install-a-composition-function) Crossplane deploys the
+function as a gRPC server. Crossplane encrypts and authenticates all gRPC
+communication.
+
+You don't have to be a gRPC expert to write a function. Crossplane's function
+SDKs setup gRPC for you. It's useful to understand how Crossplane calls your
+function though, and how your function should respond.
+
+```mermaid
+sequenceDiagram
+ User->>+API Server: Create composite resource
+ Crossplane Pod->>+API Server: Observe composite resource
+ Crossplane Pod->>+Function Pod: gRPC RunFunctionRequest
+ Function Pod->>+Crossplane Pod: gRPC RunFunctionResponse
+ Crossplane Pod->>+API Server: Apply desired composed resources
+```
+
+When you create, update, or delete a composite resource that uses composition
+functions Crossplane calls each function in the order they appear in the
+Composition's pipeline. Crossplane calls each function by sending it a gRPC
+RunFunctionRequest. The function must respond with a gRPC RunFunctionResponse.
+
+{{}}
+You can find detailed schemas for the RunFunctionRequest and RunFunctionResponse
+RPCs in the [Buf Schema Registry](https://buf.build/crossplane/crossplane/docs/main:apiextensions.fn.proto.v1beta1).
+{{}}
+
+When Crossplane calls a function it includes four important things in the
+RunFunctionRequest.
+
+1. The __observed state__ of the composite resource, and any composed resources.
+1. The __desired state__ of the composite resource, and any composed resources.
+1. The function's __input__.
+1. The function pipeline's __context__.
+
+A function's main job is to update the __desired state__ and return it to
+Crossplane. It does this by returning a RunFunctionResponse.
+
+Most composition functions read the observed state of the composite resource,
+and use it to add composed resources to the desired state. This tells Crossplane
+which composed resources it should create or update.
+
+{{}}
+
+
+A _composed_ resource is a resource created by a composite resource. Composed
+resources are usually Crossplane managed resources (MRs), but they can be any
+kind of Crossplane resource. For example a composite resource could also create
+a ProviderConfig, or another kind of composite resource.
+
+{{}}
+
+### Observed state
+
+When you create a composite resource like this one, Crossplane _observes_ it and
+sends it to the composition function as part of the observed state.
+
+```yaml
+apiVersion: example.crossplane.io/v1
+kind: XBucket
+metadata:
+ name: example-render
+spec:
+ bucketRegion: us-east-2
+```
+
+If any composed resources already exist, Crossplane observes them and sends them
+to your function to as part of the observed state.
+
+Crossplane also observes the connection details of your composite resource and
+any composed resources. It sends them to your function as part of the observed
+state.
+
+Crossplane observes the composite resource and any composed resources once,
+right before it starts calling the functions in the pipeline. This means that
+Crossplane sends every function in the pipeline the same observed state.
+
+### Desired state
+
+Desired state is the set of the changes the function pipeline wants to make to
+the composite resource and any composed resources. When a function adds composed
+resources to the desired state Crossplane creates them.
+
+A function can change:
+
+* The `status` of the composite resource.
+* The `metadata` and `spec` of any composed resource.
+
+A function can also change the connection details and readiness of the composite
+resource. A function indicates that the composite resource is ready by telling
+Crossplane whether its composed resources are ready. When the function pipeline
+tells Crossplane that all composed resources are ready, Crossplane marks the
+composite resource as ready.
+
+A function can't change:
+
+* The `metadata` or `spec` of the composite resource.
+* The `status` of any composed resource.
+* The connection details of any composed resource.
+
+A pipeline of functions _accumulates_ desired state. This means that each
+function builds upon the desired state of previous functions in the pipeline.
+Crossplane sends a function the desired state accumulated by all previous
+functions in the pipeline. The function adds to or updates the desired state and
+then passes it on. When the last function in the pipeline has run, Crossplane
+applies the desired state it returns.
+
+{{}}
+A function __must__ copy all desired state from its RunFunctionRequest to its
+RunFunctionResponse. If a function adds a resource to its desired state the next
+function must copy it to its desired state. If it doesn't, Crossplane doesn't
+apply the resource. If the resource exists, Crossplane deletes it.
+
+A function can _intentionally_ choose not to copy parts of the desired state.
+For example a function may choose not to copy a desired resource to prevent that
+resource from existing.
+
+Most function SDKs handle copying desired state automatically.
+{{}}
+
+A function should only add the fields it cares about to the desired state. It
+should add these fields every time Crossplane calls it. If a function adds a
+field to the desired state once, but doesn't add it the next time it's called,
+Crossplane deletes the field. The same is true for composed resources. If a
+function adds a composed resource to the desired state, but doesn't add it the
+next time it's called, Crossplane deletes the composed resource.
+
+{{}}
+Crossplane uses
+[server side apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/)
+to apply the desired state returned by a function pipeline. In server side apply
+terminology, the desired state is a _fully specified intent_.
+{{}}
+
+For example, if all a function wants is to make sure an S3 bucket in region
+`us-east-2` exists, it should add this resource to its desired composed
+resources.
+
+```yaml
+apiVersion: s3.aws.upbound.io/v1beta1
+kind: Bucket
+spec:
+ forProvider:
+ region: us-east-2
+```
+
+Even if the Bucket already exists and has other `spec` fields, or a `status`,
+`name`, `labels`, etc the function should omit them. The function should only
+include the fields it has an opinion about. Crossplane takes care of applying
+the fields the function cares about, merging them with the existing Bucket.
+
+{{}}
+Composition functions don't actually use YAML for desired and observed
+resources. This example uses YAML for illustration purposes only.
+{{}}
+
+### Function input
+
+If a Composition includes {{}}input{{}}
+Crossplane sends it to the function. Input is a useful way to provide extra
+configuration to a function. Supporting input is optional. Not all functions
+support input.
+
+```yaml {label="input",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ name: example-render
+spec:
+ compositeTypeRef:
+ apiVersion: example.crossplane.io/v1
+ kind: XBucket
+ mode: Pipeline
+ pipeline:
+ - step: patch-and-transform
+ functionRef:
+ name: function-patch-and-transform
+ input:
+ apiVersion: pt.fn.crossplane.io/v1beta1
+ kind: Resources
+ resources:
+ - name: storage-bucket
+ base:
+ apiVersion: s3.aws.upbound.io/v1beta1
+ kind: Bucket
+ patches:
+ - type: FromCompositeFieldPath
+ fromFieldPath: spec.bucketRegion
+ toFieldPath: spec.forProvider.region
+```
+
+{{}}
+Crossplane doesn't validate function input. It's a good idea for a function to
+validate its own input.
+{{}}
+
+### Function pipeline context
+
+Sometimes two functions in a pipeline want to share information with each other
+that isn't desired state. Functions can use context for this. Any function can
+write to the pipeline context. Crossplane passes the context to all following
+functions. When Crossplane has called all functions it discards the pipeline
+context.
+
+Crossplane can write context too. If you enable the alpha
+[composition environment]({{[}}) feature Crossplane
+writes the environment to the top-level context field
+`apiextensions.crossplane.io/environment`.
+
+## Disable composition functions
+
+Crossplane enables composition functions by default. Disable support for
+composition functions by disabling the beta feature flag in Crossplane with
+`helm install --args`.
+
+```shell
+helm install crossplane --namespace crossplane-system crossplane-stable/crossplane \
+ --create-namespace \
+ --set "args='{--enable-composition-functions=false}'"
+```
+
+The preceding Helm command installs Crossplane with the composition functions
+feature flag disabled. Confirm you have disabled composition functions by
+looking for a log line:
+
+```shell {copy-lines="1"}
+ kubectl -n crossplane-system logs -l app=crossplane
+{"level":"info","ts":1674535093.36186,"logger":"crossplane","msg":"Beta feature enabled","flag":"EnableBetaCompositionFunctions"}
+```
+
+If you don't see the log line emitted when Crossplane starts, you have disabled
+composition functions.
diff --git a/content/v1.14/concepts/compositions.md b/content/v1.14/concepts/compositions.md
new file mode 100644
index 000000000..281e57d52
--- /dev/null
+++ b/content/v1.14/concepts/compositions.md
@@ -0,0 +1,1421 @@
+---
+title: Compositions
+weight: 30
+aliases:
+ - composition
+description: "Compositions are a template for creating Crossplane resources"
+---
+
+Compositions are a template for creating multiple managed resources as a single
+object.
+
+A Composition _composes_ individual managed resources together into a larger,
+reusable, solution.
+
+An example Composition may combine a virtual machine, storage resources and
+networking policies. A Composition template links all these individual
+resources together.
+
+{{}}
+Crossplane has four core components that users commonly mix up:
+
+* Compositions - This page. A template to define how to create resources.
+* [Composite Resource Definition]({{][}})
+ (`XRD`) - A custom API specification.
+* [Composite Resource]({{][}}) (`XR`) - Created by
+ using the custom API defined in a Composite Resource Definition. XRs use the
+ Composition template to create new managed resources.
+* [Claims]({{][}}) (`XRC`) - Like a Composite Resource, but
+ with namespace scoping.
+{{]}}
+
+## Creating Compositions
+
+Creating Compositions consists of:
+* [Resource templates](#resource-templates) defining the resources to create.
+* [Enabling Composite Resources](#enabling-composite-resources) to use this
+ Composition template.
+
+
+Optionally, Compositions also support:
+* [Modifying and patching](#changing-resource-fields) resource settings.
+* [Storing connection details](#storing-connection-details) and secrets
+ generated by the managed resources.
+* Using [Composition Functions](#use-composition-functions) to template
+ resources using custom programs.
+* Creating a
+ [custom check of when a resource is ready](#resource-readiness-checks)
+ to use.
+
+
+### Resource templates
+The
+{{}}resources{{}} field of a
+Composition's
+{{}}spec{{}}
+defines the set of things that a Composite Resource creates.
+
+{{}}
+Read more about Composite Resources in the
+[Composite Resources page]({{[}}).
+{{< /hint >}}
+
+
+For example, a Composition can define a template to create a virtual machine
+and an associated storage bucket at the same time.
+
+The {{}}resources{{}} field lists the
+individual resources with a
+{{}}name{{}}.
+This name identifies the
+resource inside the Composition and isn't related to the external name used with
+the Provider.
+
+#### Template a managed resource
+The contents of the
+{{}}base{{}} are identical to
+creating a standalone [managed resource]({{][}}).
+
+This example uses
+[Upbound's Provider AWS](https://marketplace.upbound.io/providers/upbound/provider-aws/v0.35.0)
+to define a
+S3 storage {{}}Bucket{{}} and
+EC2 compute {{}}Instance{{}}.
+
+After defining the
+{{}}apiVersion{{}} and
+{{}}kind{{}}, define the
+{{}}spec.forProvider{{}} fields
+defining the settings of the resource.
+
+```yaml {copy-lines="none",label="resources"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+spec:
+ resources:
+ - name: StorageBucket
+ base:
+ apiVersion: s3.aws.upbound.io/v1beta1
+ kind: Bucket
+ spec:
+ forProvider:
+ region: "us-east-2"
+ - name: VM
+ base:
+ apiVersion: ec2.aws.upbound.io/v1beta1
+ kind: Instance
+ spec:
+ forProvider:
+ ami: ami-0d9858aa3c6322f73
+ instanceType: t2.micro
+ region: "us-east-2"
+```
+
+When a [Composite Resource]({{][}}) uses this
+Composition template, the Composite Resource creates two new managed resources
+with all the provided
+{{}}spec.forProvider{{}} settings.
+
+The {{}}spec{{}}
+supports any settings used in a managed resource including
+applying `annotations` and `labels` or using a specific
+`providerConfigRef`.
+
+{{}}
+Compositions allow applying a `metadata.name` to a resource's
+{{}}spec{{}} but ignores it. The
+`metadata.name` field doesn't influence the name
+of the managed resource in Crossplane or the external resource inside the
+Provider.
+
+Use the `crossplane.io/external-name` annotation on the resource to influence
+the external resource name.
+{{< /hint >}}
+
+#### Template a ProviderConfig
+
+Compositions can define a ProviderConfig like it defines managed resources.
+Generating a ProviderConfig may be useful in providing unique credentials to
+each deployment.
+
+
+```yaml {copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+spec:
+ resources:
+ - name: my-aws-provider-config
+ base:
+ apiVersion: aws.upbound.io/v1beta1
+ kind: ProviderConfig
+ spec:
+ source: Secret
+ secretRef:
+ namespace: crossplane-system
+ name: aws-secret
+ key: creds
+```
+
+
+#### Template another Composite Resource
+
+Compositions can use other Composite Resources to define more complicated
+templates.
+
+A common use case is a Composition that uses other
+Compositions. For example, creating a Composition to create a standard set of
+networking resources that other Compositions reference.
+
+{{< hint "note" >}}
+Both Compositions must have corresponding XRDs.
+{{< /hint >}}
+
+This example networking Composition defines the set of resources required to
+create a new AWS virtual network. This includes a
+{{}}VPC{{}},
+{{}}InternetGateway{{}} and
+{{}}Subnet{{}}.
+
+```yaml {copy-lines="none",label="xnetwork"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+spec:
+ resources:
+ - name: vpc-resource
+ base:
+ apiVersion: ec2.aws.upbound.io/v1beta1
+ kind: VPC
+ # Removed for Brevity
+ - name: gateway-resource
+ base:
+ apiVersion: ec2.aws.upbound.io/v1beta1
+ kind: InternetGateway
+ # Removed for Brevity
+ - name: subnet-resource
+ base:
+ apiVersion: ec2.aws.upbound.io/v1beta1
+ kind: Subnet
+ # Removed for Brevity
+ compositeTypeRef:
+ apiVersion: aws.platformref.upbound.io/v1alpha1
+ kind: XNetwork
+```
+
+The {{}}compositeTypeRef{{}} gives
+this Composition an
+{{}}apiVersion{{}} and
+{{}}kind{{}} to reference in another
+Composition.
+
+{{}}
+The [Enabling a Composite Resource](#enabling-composite-resources) section
+describes the
+{{}}compositeTypeRef{{}} field.
+{{< /hint >}}
+
+A second Composition, defining other resources, in this example, an AWS Elastic
+Kubernetes Cluster, can reference the previous
+{{}}XNetwork{{}}
+
+```yaml {copy-lines="none",label="xcluster"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+spec:
+ resources:
+ - name: nested-network-composition
+ base:
+ apiVersion: aws.platformref.upbound.io/v1alpha1
+ kind: XNetwork
+ # Removed for brevity
+ - name: eks-cluster-resource
+ base:
+ apiVersion: eks.aws.upbound.io/v1beta1
+ kind: Cluster
+ # Removed for brevity
+```
+
+When a Composite Resource creates all the managed resources from this
+Composition, the resources defined by the
+{{}}XNetwork{{}} get created along with
+the EKS {{}}cluster{{}}.
+
+{{}}
+This abbreviated example is from the Upbound
+[AWS Reference Platform](https://github.com/upbound/platform-ref-aws).
+
+View the complete Compositions in the reference platform's
+[package directory](https://github.com/upbound/platform-ref-aws/blob/main/apis/cluster/composition.yaml).
+{{}}
+
+#### Cross-resource references
+
+Inside a Composition some resources use identifiers or names of other resources.
+For example, creating a new `network` and applying the network identifier to a
+virtual machine.
+
+Resources inside a Composition can cross-reference other resources by matching
+a label or a _controller reference_.
+
+{{}}
+Providers allow matching of labels and controller references on a
+per-resource basis. Check the documentation for the specific Provider resource
+to see what's supported.
+
+Matching labels and controllers isn't supported across different Providers.
+{{< /hint >}}
+
+##### Match resource labels
+
+To match a resource label, first apply a
+{{}}label{{}} to the resource to
+match and use
+{{}}matchLabels{{}}
+in the second resource.
+
+This example creates a AWS
+{{}}Role{{}} and applies a
+{{}}label{{}}. The second resource
+is a {{}}RolePolicyAttachment{{}},
+which requires attaching to an existing `Role`.
+
+Using the resource's
+{{}}roleSelector.matchLabels{{}}
+ensures this
+{{}}RolePolicyAttachment{{}}
+references the matching
+{{}}Role{{}}, even if the unique role
+identifier isn't known.
+
+```yaml {label="matchlabel",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+spec:
+ resources:
+ - base:
+ apiVersion: iam.aws.upbound.io/v1beta1
+ kind: Role
+ name: iamRole
+ metadata:
+ labels:
+ role: controlplane
+ - base:
+ apiVersion: iam.aws.upbound.io/v1beta1
+ kind: RolePolicyAttachment
+ name: iamPolicy
+ spec:
+ forProvider:
+ roleSelector:
+ matchLabels:
+ role: controlplane
+ # Removed for brevity
+```
+
+##### Match a controller reference
+
+Matching a controller reference ensures that the matching resource is
+in the same composite resource.
+
+Matching only a controller reference simplifies the matching process without
+requiring labels or more information.
+
+For example, creating an AWS
+{{}}InternetGateway{{}} requires a
+{{}}VPC{{}}.
+
+The {{}}InternetGateway{{}} could
+match a label, but every VPC created by this Composition share the same label.
+
+Using {{}}matchControllerRef{{}}
+matches only the VPC created in the same composite resource that created the
+{{}}InternetGateway{{}}.
+
+```yaml {label="controller1",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+spec:
+ resources:
+ - base:
+ apiVersion: ec2.aws.upbound.io/v1beta1
+ kind: VPC
+ name: my-vpc
+ spec:
+ forProvider:
+ # Removed for brevity
+ - base:
+ apiVersion: ec2.aws.upbound.io/v1beta1
+ kind: InternetGateway
+ name: my-gateway
+ spec:
+ forProvider:
+ vpcIdSelector:
+ matchControllerRef: true
+# Removed for brevity
+```
+
+
+Resources can match both labels and a controller reference to match a specific
+resource in the larger composite resource.
+
+For example, this Composition creates two
+{{}}VPC{{}}
+resources, but the
+{{}}InternetGateway{{}}
+must match only one.
+
+Applying a {{}}label{{}} to the
+second {{}}VPC{{}} allows the
+{{}}InternetGateway{{}} to match
+the label
+{{}}type: internet{{}} and only
+match objects in the same composite resource with
+{{}}matchControllerRef{{}}.
+
+```yaml {label="controller2",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+spec:
+ resources:
+ - base:
+ apiVersion: ec2.aws.upbound.io/v1beta1
+ kind: VPC
+ name: my-first-vpc
+ metadata:
+ labels:
+ type: backend
+ spec:
+ forProvider:
+ # Removed for brevity
+ - base:
+ apiVersion: ec2.aws.upbound.io/v1beta1
+ kind: VPC
+ name: my-second-vpc
+ metadata:
+ labels:
+ type: internet
+ spec:
+ forProvider:
+ # Removed for brevity
+ - base:
+ apiVersion: ec2.aws.upbound.io/v1beta1
+ kind: InternetGateway
+ name: my-gateway
+ spec:
+ forProvider:
+ vpcIdSelector:
+ matchControllerRef: true
+ matchLabels:
+ type: internet
+# Removed for brevity
+```
+### Enabling Composite Resources
+
+A Composition is only a template defining how to create managed
+resources. A Composition limits which Composite Resources can use this
+template.
+
+A Composition's {{}}compositeTypeRef{{}}
+defines which Composite Resource type can use this Composition.
+
+{{}}
+Read more about Composite Resources in the
+[Composite Resources page]({{][}}).
+{{< /hint >}}
+
+Inside a Composition's
+{{}}spec{{}}
+define the Composite Resource
+{{}}apiVersion{{}} and
+{{}}kind{{}}
+that the Composition allows to use this template.
+
+```yaml {label="typeref",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ name: dynamodb-with-bucket
+spec:
+ compositeTypeRef:
+ apiVersion: custom-api.example.org/v1alpha1
+ kind: database
+ # Removed for brevity
+```
+
+### Changing resource fields
+
+Most Compositions require customizing the fields of the resources. This can
+include applying unique passwords, modifying where to deploy resources,
+or applying labels or annotations.
+
+The primary method to change resources is using a resource
+[patch and transform]({{][}}). Patch and transforms
+allow matching specific input fields, modifying them and applying them to the
+managed resource.
+
+{{}}
+The details of creating patch and transforms and their options are in the
+[Patch and Transform page]({{][}}).
+
+This section describes applying patches and transforms to Compositions.
+{{< /hint >}}
+
+Apply patches to individual `resources` with the
+{{}}patches{{}}
+field.
+
+For example, taking the
+{{}}location{{}} provided in a Claim
+and applying it to the
+{{}}region{{}} value in the managed
+resource.
+
+```yaml {copy-lines="none",label="patchClaim"}
+apiVersion: example.org/v1alpha1
+kind: ExampleClaim
+metadata:
+ name: my-example-claim
+spec:
+ location: "eu-north-1"
+```
+
+The Composition patch uses the
+{{}}fromFieldPath{{}} to match the
+{{}}location{{}}
+field in the Claim and the
+{{}}toFieldPath{{}} to define which field
+to change inside the Composition.
+
+```yaml {copy-lines="none",label="patch"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ resources:
+ - name: s3Bucket
+ base:
+ apiVersion: s3.aws.upbound.io/v1beta1
+ kind: Bucket
+ spec:
+ forProvider:
+ region: "us-east-2"
+ patches:
+ - type: FromCompositeFieldPath
+ fromFieldPath: "spec.location"
+ toFieldPath: "spec.forProvider.region"
+```
+
+#### Patch sets
+
+Some Compositions have resources which need identical patches applied. Instead
+of repeating the same `patches` field, resources can reference a single
+`patchSet`.
+
+Define a {{}}patchSet{{}} with a
+{{}}name{{}}
+and
+{{}}patch{{}}
+operations.
+
+Then apply the
+{{}}patchSet{{}}
+to each resource with
+{{}}type: patchSet{{< /hover >}}, referencing
+the {{}}name{{< /hover >}} in the
+{{}}patchSetName{{< /hover >}} field.
+
+```yaml {copy-lines="none",label="patchset"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ patchSets:
+ - name: reusable-patch
+ patches:
+ - type: FromCompositeFieldPath
+ fromFieldPath: "location"
+ toFieldPath: "spec.forProvider.region"
+ resources:
+ - name: first-resource
+ base:
+ # Removed for Brevity
+ patches:
+ - type: PatchSet
+ patchSetName: reusable-patch
+ - name: second-resource
+ base:
+ # Removed for Brevity
+ patches:
+ - type: PatchSet
+ patchSetName: reusable-patch
+```
+
+#### Patch with EnvironmentConfigs
+
+Crossplane uses EnvironmentConfigs to create in-memory data stores. Compositions
+can read and write from this data store as part of the patch process.
+
+{{}}
+EnvironmentConfigs are an alpha feature. Alpha features aren't enabled by
+default.
+{{< /hint >}}
+
+ EnvironmentConfigs can predefine data that Compositions can use
+ or a Composite Resource can write data to their in-memory environment for other
+ resources to read.
+
+
+{{< hint "note" >}}
+
+Read the [EnvironmentConfigs]({{][}}) page for
+more information on using EnvironmentConfigs.
+{{< /hint >}}
+
+To apply a patch using EnvironmentConfigs, first define which EnvironmentConfigs
+to use with
+{{}}environment.environmentConfigs{{}}.
+
+
+
+
+Use either a
+[reference]({{][}})
+or a [selector]({{][}}) to
+identify the EnvironmentConfigs to use.
+
+
+```yaml {label="envselect",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ environment:
+ environmentConfigs:
+ - ref:
+ name: example-environment
+ resources:
+ # Removed for Brevity
+```
+
+
+
+##### Patch a composite resource
+To patch between the composite resource and the in-memory environment use
+{{< hover label="xrpatch" line="7">}}patches{{]}} inside of the
+{{< hover label="xrpatch" line="5">}}environment{{}}.
+
+Use the
+{{< hover label="xrpatch" line="5">}}ToCompositeFieldPath{{}} to copy
+data from the in-memory environment to the composite resource.
+Use the
+{{< hover label="xrpatch" line="5">}}FromCompositeFieldPath{{}} to copy
+data from the composite resource to the in-memory environment.
+
+```yaml {label="xrpatch",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ environment:
+ # Removed for Brevity
+ patches:
+ - type: ToCompositeFieldPath
+ fromFieldPath: tags
+ toFieldPath: metadata.labels[envTag]
+ - type: FromCompositeFieldPath
+ fromFieldPath: metadata.name
+ toFieldPath: newEnvironmentKey
+```
+
+Individual resources can use any data written to their in-memory environment.
+
+##### Patch an individual resource
+To patch an individual resource, inside the
+{{}}patches{{}} of the
+resource, use
+{{}}ToEnvironmentFieldPath{{}} to copy
+data from the resource to the in-memory environment.
+Use {{}}FromEnvironmentFieldPath{{}}
+to copy data to the resource from the in-memory environment.
+
+```yaml {label="envpatch",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ environment:
+ # Removed for Brevity
+ resources:
+ # Removed for Brevity
+ - name: vpc
+ base:
+ apiVersion: ec2.aws.upbound.io/v1beta1
+ kind: VPC
+ spec:
+ forProvider:
+ cidrBlock: 172.16.0.0/16
+ patches:
+ - type: ToEnvironmentFieldPath
+ fromFieldPath: status.atProvider.id
+ toFieldPath: vpcId
+ - type: FromEnvironmentFieldPath
+ fromFieldPath: tags
+ toFieldPath: spec.forProvider.tags
+```
+
+The [EnvironmentConfigs]({{[}}) page has
+more information on EnvironmentConfigs options and usage.
+
+### Use composition functions
+
+Composition functions (or just functions, for short) are custom programs that
+template Crossplane resources. You can write a function to template resources
+using a general purpose programming language like Go or Python. Using a general
+purpose programming language allows a function to use more advanced logic to
+template resources, like loops and conditionals.
+
+{{}}
+Composition functions is a beta feature. Crossplane enables beta functions by
+default. The
+[Composition Functions]({{][}})
+page explains how to disable composition functions.
+{{< /hint >}}
+
+To use composition functions set the Composition
+{{}}mode{{}} to
+{{}}Pipeline{{}}.
+
+Define a {{}}pipeline{{}} of
+{{}}steps{{}}. Each
+{{}}step{{}} calls a Function.
+
+Each {{}}step{{}} uses a
+{{}}functionRef{{}} to reference the
+{{}}name{{}} of the Function to call.
+
+Some Functions also allow you to specify an
+{{}}input{{}}.
+The function defines the
+{{}}kind{{}} of input.
+
+{{}}
+Compositions using {{}}mode: Pipeline{{}}
+can't specify resource templates with a `resources` field.
+
+Use function "Patch and Transform" to create resource templates.
+{{< /hint >}}
+
+This example uses Function Patch and Transform. Function Patch and Transform is
+a function that implements Crossplane resource templates. You can use Function
+Patch and Transform to specify resource templates in a pipeline with other
+Functions.
+
+```yaml {label="xfn",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ # Removed for Brevity
+ mode: Pipeline
+ pipeline:
+ - step: patch-and-transform
+ functionRef:
+ name: function-patch-and-transform
+ input:
+ apiVersion: pt.fn.crossplane.io/v1beta1
+ kind: Resources
+ resources:
+ - name: storage-bucket
+ base:
+ apiVersion: s3.aws.upbound.io/v1beta1
+ kind: Bucket
+ spec:
+ forProvider:
+ region: "us-east-2"
+```
+
+Read the [composition functions]({{][}}) page for
+details on building and using composition functions.
+
+### Storing connection details
+
+Some managed resources generate unique details like usernames, passwords,
+IP addresses, ports or other connection details.
+
+When resources inside a Composition create connection details Crossplane creates
+a Kubernetes secret object for each managed resource generating connection
+details.
+
+{{}}
+This section discusses creating Kubernetes secrets.
+Crossplane also supports using external secret stores like [HashiCorp Vault](https://www.vaultproject.io/).
+
+Read the [external secrets store guide]({{][}}) for more information on using Crossplane
+with an external secret store.
+{{]}}
+
+#### Composite resource combined secret
+Crossplane can combine all the secrets generated by the resources inside a
+Composition into a single Kubernetes secret and optionally copy the
+secret object for [Claims]({{[}}).
+
+Set the value of
+{{}}writeConnectionSecretsToNamespace{{}}
+to the namespace where Crossplane should store the combined secret object.
+
+```yaml {copy-lines="none",label="writeConn"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ writeConnectionSecretsToNamespace: my-namespace
+ resources:
+ # Removed for brevity
+```
+
+#### Composed resource secrets
+Inside the
+{{}}spec{{}} of
+each resource producing connection details, define the
+{{}}writeConnectionSecretToRef{{}}, with
+a
+{{}}namespace{{}} and
+{{}}name{{}} of the secret object for
+the resource.
+
+If a
+{{}}writeConnectionSecretToRef{{}}
+isn't defined, Crossplane doesn't write any keys to the secret.
+
+
+```yaml {label="writeConnRes"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+spec:
+ writeConnectionSecretsToNamespace: other-namespace
+ resources:
+ - name: key
+ base:
+ apiVersion: iam.aws.upbound.io/v1beta1
+ kind: AccessKey
+ spec:
+ forProvider:
+ # Removed for brevity
+ writeConnectionSecretToRef:
+ namespace: docs
+ name: key1
+```
+
+Crossplane saves a secret with the
+{{}}name{{}}
+in the
+{{}}namespace{{}} provided.
+
+```shell {label="viewComposedSec"}
+kubectl get secrets -n docs
+NAME TYPE DATA AGE
+key1 connection.crossplane.io/v1alpha1 4 4m30s
+```
+
+{{}}
+
+Crossplane recommends using a [Patch]({{][}}) to
+create a unique name for each secret.
+
+For example, a
+{{}}patch{{}}
+to add the unique identifier of the resource as the key
+name.
+
+```yaml {label="tipPatch",copy-lines="14-20"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+spec:
+ # Removed for brevity
+ resources:
+ - name: key
+ base:
+ apiVersion: iam.aws.upbound.io/v1beta1
+ kind: AccessKey
+ spec:
+ # Removed for brevity
+ writeConnectionSecretToRef:
+ namespace: docs
+ name: key1
+ patches:
+ - fromFieldPath: "metadata.uid"
+ toFieldPath: "spec.writeConnectionSecretToRef.name"
+ transforms:
+ - type: string
+ string:
+ fmt: "%s-secret"
+```
+{{< /hint >}}
+
+#### Define secret keys
+
+
+A Composition must define the specific secret keys a resource creates with
+the
+{{}}connectionDetails{{}} object.
+
+{{]}}
+| Secret Type | Description |
+| --- | --- |
+| {{}}fromConnectionSecretKey{{}} | Create a secret key matching the key of a secret generated by the resource. |
+| {{}}fromFieldPath{{}} | Create a secret key matching a field path of the resource. |
+| {{}}value{{}} | Create a secret key with a predefined value. |
+{{< /table >}}
+
+{{}}
+The {{}}value{{}} type must use a
+string value.
+
+The {{}}value{{}} isn't added to the
+individual resource secret object. The
+{{}}value{{}} only appears in the
+combined composite resource secret.
+{{< /hint >}}
+
+```yaml {label="conDeet",copy-lines="none"}
+kind: Composition
+spec:
+ writeConnectionSecretsToNamespace: other-namespace
+ resources:
+ - name: key
+ base:
+ # Removed for brevity
+ spec:
+ forProvider:
+ # Removed for brevity
+ writeConnectionSecretToRef:
+ namespace: docs
+ name: key1
+ connectionDetails:
+ - name: myUsername
+ fromConnectionSecretKey: username
+ - name: myFieldSecret
+ fromFieldPath: spec.forProvider.user
+ - name: myStaticSecret
+ value: "docs.crossplane.io"
+```
+
+The
+{{}}connectionDetails{{}}
+in a resource can reference a secret from a resource with
+{{}}fromConnectionSecretKey{{}},
+from another field in the resource with
+{{}}fromFieldPath{{}}
+or a statically defined value with
+{{}}value{{}}.
+
+Crossplane sets the secret key to the
+{{}}name{{}} value.
+
+Describe the secret to view the secret keys inside the secret object.
+
+{{}}
+If more than one resource generates secrets with the same secret key name,
+Crossplane only saves one value.
+
+Use a custom {{}}name{{}} to create
+unique secret keys.
+{{< /hint >}}
+
+{{}}
+Crossplane only adds connection details listed in the
+{{}}connectionDetails{{}}
+to the combined secret object.
+Any connection secrets in a managed resource, not defined in the
+{{}}connectionDetails{{}}
+aren't added to the combined secret object.
+{{< /hint >}}
+
+
+```shell {copy-lines="1"}
+kubectl describe secret
+Name: my-access-key-secret
+Namespace: default
+Labels:
+Annotations:
+
+Type: connection.crossplane.io/v1alpha1
+
+Data
+====
+myUsername: 20 bytes
+myFieldSecret: 24 bytes
+myStaticSecret: 18 bytes
+```
+
+{{}}
+The CompositeResourceDefinition can also limit which keys Crossplane stores from
+the composite resources.
+By default an XRD writes all secret keys listed in the composed resources
+`connectionDetails` to the combined secret object.
+
+Read the
+[CompositeResourceDefinition documentation]({{[}})
+for more information on restricting secret keys.
+{{< /hint >}}
+
+For more information on connection secrets read the
+[Connection Secrets knowledge base article]({{][}}).
+
+{{}}
+You can't change the
+{{}}connectionDetails{{}}
+of a Composition.
+You must delete and
+recreate the Composition to change the
+{{}}connectionDetails{{}} .
+{{}}
+
+
+#### Save connection details to an external secret store
+
+Crossplane
+[External Secret Stores]({{][}})
+write secrets and connection details to external secret stores like HashiCorp
+Vault.
+
+{{}}
+External Secret Stores are an alpha feature.
+
+They're not recommended for production use. Crossplane disables External Secret
+Stores by default.
+{{< /hint >}}
+
+Use
+{{}}publishConnectionDetailsWithStoreConfigRef{{}}
+in place of
+`writeConnectionSecretsToNamespace` to define the
+{{}}StoreConfig{{}}
+to save connection details to.
+
+For example, using a
+{{}}StoreConfig{{}} with the
+{{}}name{{}} "vault,"
+use
+{{}}publishConnectionDetailsWithStoreConfigRef.name{{}}
+matching the {{}}StoreConfig.name{{}},
+in this example, "vault."
+
+
+```yaml {label="gcp-storeconfig",copy-lines="none"}
+apiVersion: gcp.crossplane.io/v1alpha1
+kind: StoreConfig
+metadata:
+ name: vault
+# Removed for brevity.
+---
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ publishConnectionDetailsWithStoreConfigRef:
+ name: vault
+ resources:
+ # Removed for brevity
+```
+
+For more details read the [External Secret Stores]({{][}})
+integration guide.
+
+### Resource readiness checks
+
+By default Crossplane considers a Composite Resource or Claim as `READY` when
+the status of all created resource are `Type: Ready` and `Status: True`
+
+Some resources, for example, a ProviderConfig, don't have a Kubernetes status
+and are never considered `Ready`.
+
+Custom readiness checks allow Compositions to define what custom conditions
+to meet for a resource to be `Ready`.
+
+{{< hint "tip" >}}
+Use multiple readiness checks if a resource must meet multiple conditions for it
+to be `Ready`.
+{{< /hint >}}
+
+
+Define a custom readiness check with the
+{{}}readinessChecks{{}} field on a
+resource.
+
+
+Checks have a
+{{}}type{{}} defining how to match the
+resource and a {{}}fieldPath{{}} of
+which field in the resource to compare.
+
+```yaml {label="check",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ resources:
+ # Removed for Brevity
+ - name: my-resource
+ base:
+ # Removed for brevity
+ readinessChecks:
+ - type:
+ fieldPath:
+```
+
+Compositions support matching resource fields by:
+ * [string match](#match-a-string)
+ * [integer match](#match-an-integer)
+ * [non-empty match](#match-that-a-field-exists)
+ * [always ready](#always-consider-a-resource-ready)
+ * [condition match](#match-a-condition)
+ * [boolean match](#match-a-boolean)
+
+#### Match a string
+
+{{}}MatchString{{}} considers the composed resource to be ready when the value of a
+field in that resource matches a specified string.
+
+{{}}
+
+Crossplane only supports exact string matches. Substrings and regular
+expressions aren't supported in a readiness check.
+
+{{}}
+
+
+For example, matching the string
+{{}}Online{{}}
+in the resource's
+{{}}status.atProvider.state{{}}
+field.
+
+```yaml {label="matchstring",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ resources:
+ # Removed for Brevity
+ - name: my-resource
+ base:
+ # Removed for brevity
+ readinessChecks:
+ - type: MatchString
+ fieldPath: status.atProvider.state
+ matchString: "Online"
+```
+
+#### Match an integer
+
+{{}}MatchInteger{{}} considers the composed resource to be ready when the value of a
+field in that resource matches a specified integer.
+
+{{}}
+
+Crossplane doesn't support matching `0`.
+
+{{}}
+
+For example, matching the number
+{{}}4{{}}
+in the resource's
+{{}}status.atProvider.state{{}}
+field.
+
+```yaml {label="matchint",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ resources:
+ # Removed for Brevity
+ - name: my-resource
+ base:
+ # Removed for brevity
+ readinessChecks:
+ - type: MatchInteger
+ fieldPath: status.atProvider.state
+ matchInteger: 4
+```
+
+#### Match that a field exists
+{{}}NonEmpty{{}} considers the
+composed resource to be ready when a field exists with a value.
+
+{{}}
+
+Crossplane considers a value of `0` or an empty string as empty.
+{{}}
+
+For example, to check that a resource's
+{{}}status.atProvider.state{{}}
+field isn't empty.
+
+
+```yaml {label="NonEmpty",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ resources:
+ # Removed for Brevity
+ - name: my-resource
+ base:
+ # Removed for brevity
+ readinessChecks:
+ - type: NonEmpty
+ fieldPath: status.atProvider.state
+```
+
+{{}}
+Checking {{}}NonEmpty{{}} doesn't
+require setting any other fields.
+{{< /hint >}}
+
+#### Always consider a resource ready
+{{}}None{{}} considers the
+composed resource to be ready as soon as it's created. Crossplane doesn't wait
+for any other conditions before declaring the resource ready.
+
+For example, consider
+{{}}my-resource{{}}
+ready as soon as it's created.
+
+
+```yaml {label="none",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ resources:
+ # Removed for Brevity
+ - name: my-resource
+ base:
+ # Removed for brevity
+ readinessChecks:
+ - type: None
+```
+
+#### Match a condition
+{{}}Condition{{}} considers the composed
+resource to be ready when it finds the expected condition type, with the
+expected status for it in its `status.conditions`.
+
+For example, consider
+{{}}my-resource{{}}, which is
+ready if there is a condition of type
+{{}}MyType{{}} with a status of
+{{}}Success{{}}.
+
+```yaml {label="condition",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ resources:
+ # Removed for Brevity
+ - name: my-resource
+ base:
+ # Removed for brevity
+ readinessChecks:
+ - type: MatchCondition
+ matchCondition:
+ type: MyType
+ status: Success
+```
+
+#### Match a boolean
+
+Two types of checks exist for matching boolean fields:
+ * `MatchTrue`
+ * `MatchFalse`
+
+`MatchTrue` considers the composed resource to be ready when the value of a
+field inside that resource is `true`.
+
+`MatchFalse` considers the composed resource to be ready when the value of a
+field inside that resource is `false`.
+
+For example, consider
+{{}}my-resource{{}}, which is
+ready if
+{{}} status.atProvider.manifest.status.ready{{}}
+is {{}}true{{}}.
+
+```yaml {label="matchTrue",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ resources:
+ # Removed for Brevity
+ - name: my-resource
+ base:
+ # Removed for brevity
+ readinessChecks:
+ - type: MatchTrue
+ fieldPath: status.atProvider.manifest.status.ready
+```
+{{}}
+Checking {{}}MatchTrue{{}} doesn't
+require setting any other fields.
+{{< /hint >}}
+
+`MatchFalse` matches fields that express readiness with the value `false`.
+
+For example, consider
+{{}}my-resource{{}}, is
+ready if
+{{}} status.atProvider.manifest.status.pending{{}}
+is {{}}false{{}}.
+
+```yaml {label="matchFalse",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ resources:
+ # Removed for Brevity
+ - name: my-resource
+ base:
+ # Removed for brevity
+ readinessChecks:
+ - type: MatchFalse
+ fieldPath: status.atProvider.manifest.status.pending
+```
+
+{{}}
+Checking {{}}MatchFalse{{}} doesn't
+require setting any other fields.
+{{< /hint >}}
+
+## Verify a Composition
+
+View all available Compositions with `kubectl get composition`.
+
+```shell {copy-lines="1"}
+kubectl get composition
+NAME XR-KIND XR-APIVERSION AGE
+xapps.aws.platformref.upbound.io XApp aws.platformref.upbound.io/v1alpha1 123m
+xclusters.aws.platformref.upbound.io XCluster aws.platformref.upbound.io/v1alpha1 123m
+xeks.aws.platformref.upbound.io XEKS aws.platformref.upbound.io/v1alpha1 123m
+xnetworks.aws.platformref.upbound.io XNetwork aws.platformref.upbound.io/v1alpha1 123m
+xservices.aws.platformref.upbound.io XServices aws.platformref.upbound.io/v1alpha1 123m
+xsqlinstances.aws.platformref.upbound.io XSQLInstance aws.platformref.upbound.io/v1alpha1 123m
+```
+
+The `XR-KIND` lists the Composite Resource `kind` that's allowed to use the
+Composition template.
+The `XR-APIVERSION` lists the Composite Resource API versions allowed to use the
+Composition template.
+
+{{}}
+The output of `kubectl get composition` is different than `kubectl get
+composite`.
+
+`kubectl get composition` lists all available Compositions.
+
+`kubectl get composite` lists all created Composite Resources and their related
+Composition.
+{{< /hint >}}
+
+## Composition validation
+
+When creating a Composition, Crossplane automatically validates its integrity,
+checking that the Composition is well formed, for example:
+
+If using `mode: Resources`:
+
+* The `resources` field isn't empty.
+* All resources either use a `name` or don't. Compositions can't use both named
+ and unnamed resources.
+* No duplicate resource names.
+* Patch sets must have names.
+* Patches that require a `fromFieldPath` value provide it.
+* Patches that require a `toFieldPath` value provide it.
+* Patches that require a `combine` field provide it.
+* Readiness checks using `matchString` aren't empty.
+* Readiness checks using `matchInteger` isn't `0`.
+* Readiness checks requiring a `fieldPath` value provide it.
+
+If using `mode: Pipeline` (Composition Functions):
+
+* The `pipeline` field isn't empty.
+* No duplicate step names.
+
+### Composition schema aware validation
+
+Crossplane also performs schema aware
+validation of Compositions. Schema validation checks that `patches`,
+`readinessChecks` and `connectionDetails` are valid according to the resource
+schemas. For example, checking that the source and destination fields of a patch
+are valid according to the source and destination resource schema.
+
+{{}}
+Composition schema aware validation is a beta feature. Crossplane enables
+beta features by default.
+
+Disable schema aware validation by setting the
+`--enable-composition-webhook-schema-validation=false` flag on the Crossplane
+pod.
+
+The [Crossplane Pods]({{][}}) page has
+more information on enabling Crossplane flags.
+{{< /hint >}}
+
+#### Schema aware validation modes
+
+Crossplane always rejects Compositions in case of integrity errors.
+
+Set the schema aware validation mode to configure how Crossplane handles both
+missing resource schemas and schema aware validation errors.
+
+{{}}
+If a resource schema is missing, Crossplane skips schema aware validation
+but still returns an error for integrity errors and a warning or an error
+for the missing schemas.
+{{< /hint >}}
+
+The following modes are available:
+
+{{< table "table table-sm table-striped" >}}
+| Mode | Missing Schema | Schema Aware Error | Integrity Error |
+| -------- | -------------- |--------------------|-----------------|
+| `warn` | Warning | Warning | Error |
+| `loose` | Warning | Error | Error |
+| `strict` | Error | Error | Error |
+{{< /table >}}
+
+Change the validation mode for a Composition with the
+{{}}crossplane.io/composition-schema-aware-validation-mode{{}}
+annotation.
+
+If not specified, the default mode is `warn`.
+
+For example, to enable `loose` mode checking set the annotation value to
+{{}}loose{{}}.
+
+```yaml {copy-lines="none",label="mode"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ annotations:
+ crossplane.io/composition-schema-aware-validation-mode: loose
+ # Removed for brevity
+spec:
+ # Removed for brevity
+```
+
+{{}}
+Validation modes also apply to Compositions defined by Configuration packages.
+
+Depending on the mode configured in the Composition, schema aware validation
+issues may result in warnings or the rejection of the Composition.
+
+View the Crossplane logs for validation warnings.
+
+Crossplane sets a Configuration as unhealthy if there are validation errors.
+View the Configuration details with `kubectl describe configuration` to see the
+specific errors.
+{{< /hint >}}
diff --git a/content/v1.14/concepts/environment-configs.md b/content/v1.14/concepts/environment-configs.md
new file mode 100644
index 000000000..586c5725c
--- /dev/null
+++ b/content/v1.14/concepts/environment-configs.md
@@ -0,0 +1,480 @@
+---
+title: Environment Configurations
+weight: 75
+state: alpha
+alphaVersion: "1.11"
+description: "Environment Configurations or EnvironmentConfigs are an in-memory datastore used in patching Compositions"
+---
+
+
+
+
+A Crossplane EnvironmentConfig is a cluster scoped
+[ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/)-like
+resource used
+by Compositions. Compositions can use the environment to store information from
+individual resources or to apply [patches]({{][}}).
+
+Crossplane supports multiple EnvironmentConfigs, each acting as a unique
+data store.
+
+When Crossplane creates a composite resource, Crossplane merges all the
+EnvironmentConfigs referenced in the associated Composition and creates a unique
+in-memory environment for that composite resource.
+
+The composite resource can read and write data to their unique
+in-memory environment.
+
+{{}}
+The in-memory environment is unique to each composite resource.
+A composite resource can't read data in another composite resource's
+environment.
+{{< /hint >}}
+
+## Enable EnvironmentConfigs
+EnvironmentConfigs are an alpha feature. Alpha features aren't enabled by
+default.
+
+Enable EnvironmentConfig support by
+[changing the Crossplane pod setting]({{][}})
+and enabling
+{{}}--enable-environment-configs{{}}
+argument.
+
+```yaml {label="deployment",copy-lines="12"}
+$ kubectl edit deployment crossplane --namespace crossplane-system
+apiVersion: apps/v1
+kind: Deployment
+spec:
+# Removed for brevity
+ template:
+ spec:
+ containers:
+ - args:
+ - core
+ - start
+ - --enable-environment-configs
+```
+
+{{}}
+
+The [Crossplane install guide]({{][}})
+describes enabling feature flags like
+{{}}--enable-environment-configs{{}}
+with Helm.
+{{< /hint >}}
+
+
+## Create an EnvironmentConfig
+
+
+An {{}}EnvironmentConfig{{}} has a single
+object field,
+{{}}data{{}}.
+
+An EnvironmentConfig supports any data inside the
+{{}}data{{}} field.
+
+Here an example
+{{}}EnvironmentConfig{{}}.
+
+```yaml {label="env1"}
+apiVersion: apiextensions.crossplane.io/v1alpha1
+kind: EnvironmentConfig
+metadata:
+ name: example-environment
+data:
+ locations:
+ us: us-east-2
+ eu: eu-north-1
+ key1: value1
+ key2: value2
+ key3:
+ - item1
+ - item2
+```
+
+
+## Select an EnvironmentConfig
+
+
+Select the EnvironmentConfigs to use
+inside a Composition's
+{{}}environment{{}} field.
+
+The {{}}environmentConfigs{{}} field is a
+list of environments this Composition can use.
+
+Select an environment by
+{{}}Reference{{}} or
+by
+{{}}Selector{{}}.
+
+A
+{{}}Reference{{}}
+selects an environment by
+{{}}name{{}}.
+The
+{{}}Selector{{}} selects an environment
+based on the
+{{}}Labels{{}} applied to the environment.
+
+```yaml {label="comp",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ name: example-composition
+spec:
+ environment:
+ environmentConfigs:
+ - type: Reference
+ ref:
+ name: example-environment
+ - type: Selector
+ selector:
+ matchLabels:
+ # Removed for brevity
+```
+
+If a Composition uses multiple
+{{}}environmentConfigs{{}}
+Crossplane merges them together in the order they're listed.
+
+{{}}
+If multiple
+{{}}environmentConfigs{{}}
+use the same key, the Composition uses the value of the last environment listed.
+{{}}
+
+### Select by name
+
+Select an environment by name with
+{{}}type: Reference{{}}.
+
+Define the
+{{}}ref{{}} object and the
+{{}}name{{}} matching the exact name of
+the environment.
+
+
+For example, select the
+{{}}environmentConfig{{}}
+named
+{{}}example-environment{{}}
+
+```yaml {label="byName",copy-lines="all"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ name: example-composition
+spec:
+ environment:
+ environmentConfigs:
+ - type: Reference
+ ref:
+ name: example-environment
+```
+
+### Select by label
+
+Select an environment by labels with a
+{{}}type: Selector{{}}.
+
+Define the {{}}selector{{}} object.
+
+The
+{{}}matchLabels{{}} object contains a
+list of labels to match on.
+
+Selecting a label requires matching both the label
+{{}}key{{}}
+and the value of key.
+
+When matching the label's value, provide an exact value with a
+{{}}type: Value{{}} and provide the value
+to match in the
+{{}}value{{}} field.
+
+Crossplane can also match a label's value based on an input in the composite
+resource. Use
+{{}}type: FromCompositeFieldPath{{}}
+and provide the field to match in the
+{{}}valueFromFieldPath{{}} field.
+
+```yaml {label="byLabel",copy-lines="all"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ name: example-composition
+spec:
+ environment:
+ environmentConfigs:
+ - type: Selector
+ selector:
+ matchLabels:
+ - key: my-label-key
+ type: Value
+ value: my-label-value
+ - key: my-label-key
+ type: FromCompositeFieldPath
+ valueFromFieldPath: spec.parameters.deploy
+ resources:
+ # Removed for brevity
+```
+
+#### Manage selector results
+
+Selecting environments by labels may return more than one environment.
+The Composition sorts all the results by the name of the environments and
+only uses the first environment in the sorted list.
+
+Set the {{}}mode{{}} as
+{{}}mode: Multiple{{}} to return
+all matched environments. Use
+{{}}mode: Single{{}} to
+return a single environment.
+
+{{}}
+Sorting and the selection
+{{}}mode{{}}
+only applies to a single
+{{}}type: Selector{{}}.
+
+This doesn't change how Compositions merge multiple
+{{}}environmentConfigs{{}}.
+{{< /hint >}}
+
+
+```yaml {label="selectResults"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ name: example-composition
+spec:
+ environment:
+ environmentConfigs:
+ - type: Selector
+ selector:
+ mode: Multiple
+ matchLabels:
+ - key: my-label-key
+ type: Value
+ value: my-label-value
+ - key: my-label-key
+ type: FromCompositeFieldPath
+ valueFromFieldPath: spec.parameters.deploy
+ - type: Selector
+ selector:
+ mode: Single
+ matchLabels:
+ - key: my-other-label-key
+ type: Value
+ value: my-other-label-value
+ - key: my-other-label-key
+ type: FromCompositeFieldPath
+ valueFromFieldPath: spec.parameters.deploy
+```
+
+When using
+{{}}mode: Multiple{{}} limit the
+number of returned environments with
+{{}}maxMatch{{}} and define the
+maximum number of environments returned.
+
+The Composition sorts the returned environments alphabetically by name. Sort the
+environments on a different field with
+{{}}sortByFieldPath{{}} and define
+the field to sort by.
+
+
+```yaml {label="maxMatch"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ name: example-composition
+spec:
+ environment:
+ environmentConfigs:
+ - type: Selector
+ selector:
+ mode: Multiple
+ maxMatch: 4
+ sortByFieldPath: metadata.annotations[sort.by/weight]
+ matchLabels:
+ - key: my-label-key
+ type: Value
+ value: my-label-value
+ - key: my-label-key
+ type: FromCompositeFieldPath
+ valueFromFieldPath: spec.parameters.deploy
+```
+
+The environments selected by
+{{}}matchLabels{{}} are then merged
+into any other environments listed in the
+{{}}environmentConfigs{{}}.
+
+#### Optional selector labels
+By default, Crossplane issues an error if a
+{{}}valueFromFieldPath{{}}
+field doesn't exist in the composite resource.
+
+Add
+{{}}fromFieldPathPolicy{{}}
+as {{}}Optional{{}}
+to ignore a field if it doesn't exist.
+
+```yaml {label="byLabelOptional",copy-lines="all"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ name: example-composition
+spec:
+ environment:
+ environmentConfigs:
+ - type: Selector
+ selector:
+ matchLabels:
+ - key: my-first-label-key
+ type: Value
+ value: my-first-label-value
+ - key: my-second-label-key
+ type: FromCompositeFieldPath
+ valueFromFieldPath: spec.parameters.deploy
+ fromFieldPathPolicy: Optional
+ resources:
+ # Removed for brevity
+```
+
+
+Set a default value for an optional label by setting the default
+{{}}value{{}} for the
+{{}}key{{}} first, then
+define the
+{{}}Optional{{}} label.
+
+For example, this Composition defines
+{{}}value: my-default-value{{}}
+for the key {{}}my-second-label-key{{}}.
+If the label
+{{}}my-second-label-key{{}}
+exists, Crossplane uses the value from the label instead.
+
+```yaml {label="byLabelOptionalDefault",copy-lines="all"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ name: example-composition
+spec:
+ environment:
+ environmentConfigs:
+ - type: Selector
+ selector:
+ matchLabels:
+ - key: my-first-label-key
+ type: Value
+ value: my-label-value
+ - key: my-second-label-key
+ type: Value
+ value: my-default-value
+ - key: my-second-label-key
+ type: FromCompositeFieldPath
+ valueFromFieldPath: spec.parameters.deploy
+ fromFieldPathPolicy: Optional
+ resources:
+ # Removed for brevity
+```
+
+{{}}
+Crossplane applies values in order. The value of the last key defined always takes precedence.
+
+Defining the default value _after_ the label always overwrites the label
+value.
+{{< /hint >}}
+
+## Patching with EnvironmentConfigs
+
+When Crossplane creates or updates a composite resource, Crossplane
+merges all the specified EnvironmentConfigs into an in-memory environment.
+
+The composite resource can read or write data between the EnvironmentConfig and
+composite resource or between the EnvironmentConfig and individual resources
+defined inside the composite resource.
+
+{{}}
+Read about EnvironmentConfig patch types in the
+[Patch and Transform]({{][}}) documentation.
+{{< /hint >}}
+
+
+
+### Patch a composite resource
+To patch the composite resource use
+{{< hover label="xrpatch" line="7">}}patches{{}} inside of the
+{{< hover label="xrpatch" line="5">}}environment{{}}.
+
+Use the
+{{< hover label="xrpatch" line="5">}}ToCompositeFieldPath{{}} to copy
+data from the in-memory environment to the composite resource.
+Use the
+{{< hover label="xrpatch" line="5">}}FromCompositeFieldPath{{}} to copy
+data from the composite resource to the in-memory environment.
+
+```yaml {label="xrpatch",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ environment:
+ # Removed for Brevity
+ patches:
+ - type: ToCompositeFieldPath
+ fromFieldPath: tags
+ toFieldPath: metadata.labels[envTag]
+ - type: FromCompositeFieldPath
+ fromFieldPath: metadata.name
+ toFieldPath: newEnvironmentKey
+```
+
+Individual resources can use any data written to the in-memory environment.
+
+### Patch an individual resource
+To patch an individual resource, inside the
+{{}}patches{{}} of the
+resource, use
+{{}}ToEnvironmentFieldPath{{}} to copy
+data from the resource to the in-memory environment.
+Use {{}}FromEnvironmentFieldPath{{}}
+to copy data to the resource from the in-memory environment.
+
+```yaml {label="envpatch",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for Brevity
+spec:
+ environment:
+ # Removed for Brevity
+ resources:
+ # Removed for Brevity
+ - name: vpc
+ base:
+ apiVersion: ec2.aws.upbound.io/v1beta1
+ kind: VPC
+ spec:
+ forProvider:
+ cidrBlock: 172.16.0.0/16
+ patches:
+ - type: ToEnvironmentFieldPath
+ fromFieldPath: status.atProvider.id
+ toFieldPath: vpcId
+ - type: FromEnvironmentFieldPath
+ fromFieldPath: tags
+ toFieldPath: spec.forProvider.tags
+```
+
+The [Patch and Transform]({{][}}) documentation has
+more information on patching individual resources.
+
+
\ No newline at end of file
diff --git a/content/v1.11/concepts/managed-resources.md b/content/v1.14/concepts/managed-resources.md
similarity index 69%
rename from content/v1.11/concepts/managed-resources.md
rename to content/v1.14/concepts/managed-resources.md
index 1f6ba610b..f054a1be4 100644
--- a/content/v1.11/concepts/managed-resources.md
+++ b/content/v1.14/concepts/managed-resources.md
@@ -1,6 +1,7 @@
---
title: Managed Resources
-weight: 102
+weight: 10
+description: "Managed resources are the Crossplane representation of external provider resources"
---
A _managed resource_ (`MR`) represents an external service in a Provider. When
@@ -21,7 +22,7 @@ Examples of managed resources include:
{{< hint "tip" >}}
You can create individual managed resources, but Crossplane recommends using
-[Compositions]({{][}}) and Claims to create
+[Compositions]({{][}}) and Claims to create
managed resources.
{{< /hint >}}
@@ -34,8 +35,7 @@ Provider also define the available settings of a managed resource.
Each managed resource is a unique API endpoint with their own
group, kind and version.
-For example the [Upbound AWS
-Provider](https://marketplace.upbound.io/providers/upbound/provider-aws/latest/)
+For example the [Upbound AWS Provider](https://marketplace.upbound.io/providers/upbound/provider-aws/latest/)
defines the {{}}Instance{{}} kind from the
group {{}}ec2.aws.upbound.io{{}}
@@ -55,7 +55,29 @@ Provider deletes the managed resource but doesn't delete the external resource.
#### Options
* `deletionPolicy: Delete` - **Default** - Delete the external resource when deleting the managed resource.
-* `deletionPolicy: Orphan` - Leave the external resource when deleting the managed resource.
+* `deletionPolicy: Orphan` - Leave the external resource when deleting the managed resource.
+
+#### Interaction with management policies
+
+The [management policy](#managementpolicies) takes precedence over the
+`deletionPolicy` when:
+
+- The related management policy alpha feature is enabled.
+
+- The resource configures a management policy other than the default value.
+
+See the table below for more details.
+
+{{< table "table table-sm table-hover">}}
+| managementPolicies | deletionPolicy | result |
+|-----------------------------|------------------|---------|
+| "*" (default) | Delete (default) | Delete |
+| "*" (default) | Orphan | Orphan |
+| contains "Delete" | Delete (default) | Delete |
+| contains "Delete" | Orphan | Delete |
+| doesn't contain "Delete" | Delete (default) | Orphan |
+| doesn't contain "Delete" | Orphan | Orphan |
+{{< /table >}}
### forProvider
@@ -95,10 +117,6 @@ inside a Provider's web console, Crossplane reverts that change back to what's
configured in the `forProvider` setting.
{{< /hint >}}
-Providers add any settings not manually set to the `forProvider` field of the
-created managed resource object.
-Use `kubectl describe ` to view the applied values.
-
#### Referencing other resources
Some fields in a managed resource may depend on values from other managed
@@ -166,7 +184,8 @@ spec:
Matching by selector is the most flexible matching method.
{{}}
-The [Composition]({{][}}) section covers the
+
+The [Compositions]({{][}}) section covers the
`matchControllerRef` selector.
{{]}}
@@ -206,47 +225,164 @@ resource object is deleted from Kubernetes and the `deletionPolicy` is
`delete`.
{{< /hint >}}
-
+
+#### Late initialization
+
+Crossplane treats the managed resource as the source of truth by default;
+it expects to have all values under `spec.forProvider` including the
+optional ones. If not provided, Crossplane populates the empty fields with
+the values assigned by the provider. For example, consider fields such as
+`region` and `availabilityZone`. You might specify only the region and let the
+cloud provider choose the availability zone. In this case, if the provider
+assigns an availability zone, Crossplane uses that value to populate the
+`spec.forProvider.availabilityZone` field.
+
+{{}}
+
+With [managementPolicies]({{[}}),
+this behavior can be turned off by not including the `LateInitialize` policy in
+the `managementPolicies` list.
+
+{{< /hint >}}
-### managementPolicy
-
+### initProvider
+
{{}}
-The managed resource `managementPolicy` option is an alpha feature.
+The managed resource `initProvider` option is a beta feature related to
+[managementPolicies]({{][}}).
-Enable the `managementPolicy` in a provider with `--enable-management-policies`
-in a
-[ControllerConfig]({{][}}).
{{< /hint >}}
-A `managementPolicy` determines if Crossplane can make changes to managed
-resources. The `ObserveOnly` policy imports existing external resources not
-originally created by Crossplane.
-This allows new managed resources to reference
-the `ObserveOnly` resource, for example, a shared database or network.
-The `ObserveOnly` policy can also place existing resources under the control of
-Crossplane.
+The
+{{}}initProvider{{}} defines
+settings Crossplane applies only when creating a new managed resource.
+Crossplane ignores settings defined in the
+{{}}initProvider{{}}
+field that change after creation.
+
+{{}}
+Settings in `forProvider` are always enforced by Crossplane. Crossplane reverts
+any changes to a `forProvider` field in the external resource.
+
+Settings in `initProvider` aren't enforced by Crossplane. Crossplane ignores any
+changes to a `initProvider` field in the external resource.
+{{}}
+
+Using `initProvider` is useful for setting initial values that a Provider may
+automatically change, like an auto scaling group.
+
+For example, creating a
+{{}}NodeGroup{{}}
+with an initial
+{{}}desiredSize{{}}.
+Crossplane doesn't change the
+{{}}desiredSize{{}}
+setting back when an autoscaler scales the Node Group external resource.
{{< hint "tip" >}}
-Read the [Import Existing Resources]({{][}}) guide for more
-information on using the `managementPolicy` to import existing resources.
+Crossplane recommends configuring
+{{}}managementPolicies{{}} without
+`LateInitialize` to avoid conflicts with `initProvider` settings.
{{< /hint >}}
-#### Options
-* `managementPolicy: FullControl` - **Default** - Crossplane can create, change
- and delete the managed resource.
-* `managementPolicy: ObserveOnly` - Crossplane only imports the details of the
- external resource, but doesn't make any changes to the managed resource.
+```yaml {label="initProvider",copy-lines="none"}
+apiVersion: eks.aws.upbound.io/v1beta1
+kind: NodeGroup
+metadata:
+ name: sample-eks-ng
+spec:
+ managementPolicies: ["Observe", "Create", "Update", "Delete"]
+ initProvider:
+ scalingConfig:
+ - desiredSize: 1
+ forProvider:
+ region: us-west-1
+ scalingConfig:
+ - maxSize: 4
+ minSize: 1
+```
+
+
+### managementPolicies
+
+
+{{}}
+The managed resource `managementPolicies` option is a beta feature. Crossplane enables
+beta features by default.
+
+The Provider determines support for management policies.
+Refer to the Provider's documentation to see if the Provider supports
+management policies.
+{{< /hint >}}
+
+Crossplane
+{{}}managementPolicies{{}}
+determine which actions Crossplane can take on a
+managed resource and its corresponding external resource.
+Apply one or more
+{{}}managementPolicies{{}}
+to a managed resource to determine what permissions
+Crossplane has over the resource.
+
+For example, give Crossplane permission to create and delete an external resource,
+but not make any changes, set the policies to
+{{}}["Create", "Delete", "Observe"]{{}}.
+
+```yaml {label="managementPol1"}
+apiVersion: ec2.aws.upbound.io/v1beta1
+kind: Subnet
+spec:
+ managementPolicies: ["Create", "Delete", "Observe"]
+ forProvider:
+ # Removed for brevity
+```
+The default policy grants Crossplane full control over the resources.
+Defining the `managementPolicies` field with an empty array [pauses](#paused)
+the resource.
+
+{{}}
+The Provider determines support for management policies.
+Refer to the Provider's documentation to see if the Provider supports
+management policies.
+{{< /hint >}}
+
+Crossplane supports the following policies:
+{{]}}
+| Policy | Description |
+| --- | --- |
+| `*` | _Default policy_. Crossplane has full control over a resource. |
+| `Create` | If the external resource doesn't exist, Crossplane creates it based on the managed resource settings. |
+| `Delete` | Crossplane can delete the external resource when deleting the managed resource. |
+| `LateInitialize` | Crossplane initializes some external resource settings not defined in the `spec.forProvider` of the managed resource. See [the late initialization]({{[}}) section for more details. |
+| `Observe` | Crossplane only observes the resource and doesn't make any changes. Used for [observe only resources]({{][}}). |
+| `Update` | Crossplane changes the external resource when changing the managed resource. |
+{{]
}}
+
+The following is a list of common policy combinations:
+{{}}
+| Create | Delete | LateInitialize | Observe | Update | Description |
+| :---: | :---: | :---: | :---: | :---: | --- |
+| ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | _Default policy_. Crossplane has full control over the resource. |
+| ✔️ | ✔️ | ✔️ | ✔️ | | After creation any changes made to the managed resource aren't passed to the external resource. Useful for immutable external resources. |
+| ✔️ | ✔️ | | ✔️ | ✔️ | Prevent Crossplane from managing any settings not defined in the managed resource. Useful for immutable fields in an external resource. |
+| ✔️ | ✔️ | | ✔️ | | Crossplane doesn't import any settings from the external resource and doesn't push changes to the managed resource. Crossplane recreates the external resource if it's deleted. |
+| ✔️ | | ✔️ | ✔️ | ✔️ | Crossplane doesn't delete the external resource when deleting the managed resource. |
+| ✔️ | | ✔️ | ✔️ | | Crossplane doesn't delete the external resource when deleting the managed resource. Crossplane doesn't apply changes to the external resource after creation. |
+| ✔️ | | | ✔️ | ✔️ | Crossplane doesn't delete the external resource when deleting the managed resource. Crossplane doesn't import any settings from the external resource. |
+| ✔️ | | | ✔️ | | Crossplane creates the external resource but doesn't apply any changes to the external resource or managed resource. Crossplane can't delete the resource. |
+| | | | ✔️ | | Crossplane only observes a resource. Used for [observe only resources]({{[}}). |
+| | | | | | No policy set. An alternative method for [pausing](#paused) a resource. |
+{{< /table >}}
### providerConfigRef
The `providerConfigRef` on a managed resource tells the Provider which
-[ProviderConfig]({{][}}) to
+[ProviderConfig]({{][}}) to
use when creating the managed resource.
Use a ProviderConfig to define the authentication method to use when
@@ -288,10 +424,11 @@ same Provider.
### providerRef
+
Crossplane deprecated the `providerRef` field in `crossplane-runtime`
[v0.10.0](https://github.com/crossplane/crossplane-runtime/releases/tag/v0.10.0).
Managed resources using `providerRef`must use [`providerConfigRef`](#providerconfigref).
-
+
### writeConnectionSecretToRef
@@ -304,8 +441,7 @@ Crossplane stores these details in a Kubernetes Secret object specified by the
`writeConnectionSecretToRef` values.
For example, when creating an AWS RDS database instance with the Crossplane
-[community AWS
-provider](https://marketplace.upbound.io/providers/crossplane-contrib/provider-aws/v0.40.0)
+[community AWS provider](https://marketplace.upbound.io/providers/crossplane-contrib/provider-aws/v0.40.0)
generates an endpoint, password, port and username data. The Provider saves
these variables in the Kubernetes secret
{{}}rds-secret{{}}, referenced by
@@ -355,7 +491,7 @@ secrets store like [HashiCorp Vault](https://www.vaultproject.io/).
Using `publishConnectionDetailsTo` requires enabling Crossplane
External Secrets Stores (ESS). Enable ESS inside a Provider with a
-[ControllerConfig]({{][}}) and
+[DeploymentRuntimeConfig]({{][}}) and
in Crossplane with the `--enable-external-secret-stores` argument.
{{< hint "note" >}}
@@ -435,7 +571,6 @@ Read the
guide for details on using StoreConfig objects.
{{< /hint >}}
-
## Annotations
Crossplane applies a standard set of Kubernetes `annotations` to managed
@@ -511,8 +646,7 @@ call and receiving a response.
If a Provider restarts before creating the `succeed` or `fail` annotations the
Provider can't reconcile the manged resource.
-Read Crossplane [issue
-#3037](https://github.com/crossplane/crossplane/issues/3037#issuecomment-1110142427)
+Read Crossplane [issue #3037](https://github.com/crossplane/crossplane/issues/3037#issuecomment-1110142427)
for more details
{{< /hint >}}
diff --git a/content/v1.14/concepts/packages.md b/content/v1.14/concepts/packages.md
new file mode 100644
index 000000000..afee1110c
--- /dev/null
+++ b/content/v1.14/concepts/packages.md
@@ -0,0 +1,486 @@
+---
+title: Configuration Packages
+description: "Packages combine multiple Crossplane resources into a single, portable, OCI image."
+altTitle: "Crossplane Packages"
+weight: 200
+---
+
+A _Configuration_ package is an
+[OCI container images](https://opencontainers.org/) containing a collection of
+[Compositions]({{][}}),
+[Composite Resource Definitions]({{][}})
+and any required [Providers]({{][}}) or
+[Functions]({{][}}).
+
+Configuration packages make your Crossplane configuration fully portable.
+
+{{}}
+Crossplane [Providers]({{][}}) and
+[Functions]({{][}}) are also Crossplane packages.
+
+This document describes how to install and manage configuration packages.
+
+Refer to the
+[Provider]({{][}}) and
+[Composition Functions]({{][}}) chapters for
+details on their usage of packages.
+{{< /hint >}}
+
+## Install a Configuration
+
+Install a Configuration with a Crossplane
+{{}}Configuration{{}} object by setting
+the {{}}spec.package{{}} value to the
+location of the configuration package.
+
+For example to install the
+[Upbound AWS reference platform](https://marketplace.upbound.io/configurations/upbound/platform-ref-aws/v0.6.0),
+
+```yaml {label="install"}
+apiVersion: pkg.crossplane.io/v1
+kind: Configuration
+metadata:
+ name: platform-ref-aws
+spec:
+ package: xpkg.upbound.io/upbound/platform-ref-aws:v0.6.0
+```
+
+Crossplane installs the Compositions, Composite Resource Definitions and
+Providers listed in the Configuration.
+
+### Install with Helm
+
+Crossplane supports installing Configurations during an initial Crossplane
+installation with the Crossplane Helm chart.
+
+Use the
+{{}}--set configuration.packages{{}}
+argument with `helm install`.
+
+For example, to install the Upbound AWS reference platform,
+
+```shell {label="helm"}
+helm install crossplane \
+crossplane-stable/crossplane \
+--namespace crossplane-system \
+--create-namespace \
+--set configuration.packages='{xpkg.upbound.io/upbound/platform-ref-aws:v0.6.0}'
+```
+
+### Install offline
+
+Crossplane installs packages from a local package cache. By
+default the Crossplane package cache is an
+[emptyDir volume](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir).
+
+Configure Crossplane to use a
+[PersistentVolumeClaim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
+to use a storage location containing the Configuration image. Read more about
+configuring the Crossplane Pod settings in the
+[Crossplane install documentation]({{][}}).
+
+Provide the name of the Configuration's `.xpkg` file and set
+{{}}packagePullPolicy: Never{{}}.
+
+For example, to install a locally stored version of
+Upbound AWS reference platform set the
+{{}}package{{}} to the local filename
+and set the Configuration's
+{{}}packagePullPolicy: Never{{}}.
+
+```yaml {label="offline"}
+apiVersion: pkg.crossplane.io/v1
+kind: Configuration
+metadata:
+ name: offline-platform-ref-aws
+spec:
+ package: platform-ref-aws
+ packagePullPolicy: Never
+```
+
+### Installation options
+
+Configurations support multiple options to change configuration package related
+settings.
+
+
+#### Configuration revisions
+
+When installing a newer version of an existing Configuration Crossplane creates
+a new configuration revision.
+
+View the configuration revisions with
+{{}}kubectl get configurationrevisions{{}}.
+
+```shell {label="rev",copy-lines="1"}
+kubectl get configurationrevisions
+NAME HEALTHY REVISION IMAGE STATE DEP-FOUND DEP-INSTALLED AGE
+platform-ref-aws-1735d56cd88d True 2 xpkg.upbound.io/upbound/platform-ref-aws:v0.5.0 Active 2 2 46s
+platform-ref-aws-3ac761211893 True 1 xpkg.upbound.io/upbound/platform-ref-aws:v0.4.1 Inactive 5m13s
+```
+
+Only a single revision is active at a time. The active revision determines the
+available resources, including Compositions and Composite Resource Definitions.
+
+By default Crossplane keeps only a single _Inactive_ revision.
+
+Change the number of revisions Crossplane maintains with a Configuration package
+{{}}revisionHistoryLimit{{}}.
+
+The {{}}revisionHistoryLimit{{}}
+field is an integer.
+The default value is `1`.
+Disable storing revisions by setting
+{{}}revisionHistoryLimit{{}} to `0`.
+
+For example, to change the default setting and store 10 revisions use
+{{}}revisionHistoryLimit: 10{{}}.
+
+```yaml {label="revHistory"}
+apiVersion: pkg.crossplane.io/v1
+kind: Configuration
+metadata:
+ name: platform-ref-aws
+spec:
+ revisionHistoryLimit: 10
+# Removed for brevity
+```
+
+#### Configuration package pull policy
+
+Use a {{}}packagePullPolicy{{}} to
+define when Crossplane should download the Configuration package to the local
+Crossplane package cache.
+
+The `packagePullPolicy` options are:
+* `IfNotPresent` - (**default**) Only download the package if it isn't in the cache.
+* `Always` - Check for new packages every minute and download any matching
+ package that isn't in the cache.
+* `Never` - Never download the package. Packages are only installed from the
+ local package cache.
+
+{{}}
+The Crossplane
+{{}}packagePullPolicy{{}} works
+like the Kubernetes container image
+[image pull policy](https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy).
+
+Crossplane supports the use of tags and package digest hashes like
+Kubernetes images.
+{{< /hint >}}
+
+For example, to `Always` download a given Configuration package use the
+{{}}packagePullPolicy: Always{{}}
+configuration.
+
+```yaml {label="pullpolicy",copy-lines="6"}
+apiVersion: pkg.crossplane.io/v1
+kind: Configuration
+metadata:
+ name: platform-ref-aws
+spec:
+ packagePullPolicy: Always
+# Removed for brevity
+```
+
+#### Revision activation policy
+
+The `Active` package revision
+is the package controller actively reconciling resources.
+
+By default Crossplane sets the most recently installed package revision as
+`Active`.
+
+Control the Configuration upgrade behavior with a
+{{}}revisionActivationPolicy{{}}.
+
+The {{}}revisionActivationPolicy{{}}
+options are:
+* `Automatic` - (**default**) Automatically activate the last installed configuration.
+* `Manual` - Don't automatically activate a configuration.
+
+For example, to change the upgrade behavior to require manual upgrades, set
+{{}}revisionActivationPolicy: Manual{{}}.
+
+```yaml {label="revision"}
+apiVersion: pkg.crossplane.io/v1
+kind: Configuration
+metadata:
+ name: platform-ref-aws
+spec:
+ revisionActivationPolicy: Manual
+# Removed for brevity
+```
+
+
+#### Install a Configuration from a private registry
+
+Like Kubernetes uses `imagePullSecrets` to
+[install images from private registries](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/),
+Crossplane uses `packagePullSecrets` to install Configuration packages from a
+private registry.
+
+Use {{}}packagePullSecrets{{}} to provide a
+Kubernetes secret to use for authentication when downloading a Configuration
+package.
+
+{{}}
+The Kubernetes secret must be in the same namespace as Crossplane.
+{{}}
+
+The {{}}packagePullSecrets{{}} is a list of
+secrets.
+
+For example, to use the secret named
+{{}}example-secret{{}} configure a
+{{}}packagePullSecrets{{}}.
+
+```yaml {label="pps"}
+apiVersion: pkg.crossplane.io/v1
+kind: Configuration
+metadata:
+ name: platform-ref-aws
+spec:
+ packagePullSecrets:
+ - name: example-secret
+# Removed for brevity
+```
+
+#### Ignore dependencies
+
+By default Crossplane installs any [dependencies](#manage-dependencies) listed
+in a Configuration package.
+
+Crossplane can ignore a Configuration package's dependencies with
+{{}}skipDependencyResolution{{}}.
+
+{{< hint "warning" >}}
+Most Configurations include dependencies for the required Providers.
+
+If a Configuration ignores dependencies, the required Providers must be
+manually installed.
+{{< /hint >}}
+
+For example, to disable dependency resolution configure
+{{}}skipDependencyResolution: true{{}}.
+
+```yaml {label="pkgDep"}
+apiVersion: pkg.crossplane.io/v1
+kind: Configuration
+metadata:
+ name: platform-ref-aws
+spec:
+ skipDependencyResolution: true
+# Removed for brevity
+```
+
+#### Ignore Crossplane version requirements
+
+A Configuration package may require a specific or minimum Crossplane version
+before installing. By default, Crossplane doesn't install a Configuration if
+the Crossplane version doesn't meet the required version.
+
+Crossplane can ignore the required version with
+{{}}ignoreCrossplaneConstraints{{}}.
+
+For example, to install a Configuration package into an unsupported Crossplane
+version, configure
+{{}}ignoreCrossplaneConstraints: true{{}}.
+
+```yaml {label="xpVer"}
+apiVersion: pkg.crossplane.io/v1
+kind: Configuration
+metadata:
+ name: platform-ref-aws
+spec:
+ ignoreCrossplaneConstraints: true
+# Removed for brevity
+```
+
+
+### Verify a Configuration
+
+Verify a Configuration with
+{{}}kubectl get configuration{{}}.
+
+A working configuration reports `Installed` and `Healthy` as `True`.
+
+```shell {label="verify",copy-lines="1"}
+kubectl get configuration
+NAME INSTALLED HEALTHY PACKAGE AGE
+platform-ref-aws True True xpkg.upbound.io/upbound/platform-ref-aws:v0.6.0 54s
+```
+
+### Manage dependencies
+
+Configuration packages may include dependencies on other packages including
+Functions, Providers or other Configurations.
+
+If Crossplane can't meet the dependencies of a Configuration the Configuration
+reports `HEALTHY` as `False`.
+
+For example, this installation of the Upbound AWS reference platform is
+`HEALTHY: False`.
+
+```shell {copy-lines="1"}
+kubectl get configuration
+NAME INSTALLED HEALTHY PACKAGE AGE
+platform-ref-aws True False xpkg.upbound.io/upbound/platform-ref-aws:v0.6.0 71s
+```
+
+To see more information on why the Configuration isn't `HEALTHY` use
+{{}}kubectl describe configurationrevisions{{}}.
+
+```yaml {copy-lines="1",label="depend"}
+kubectl describe configurationrevision
+Name: platform-ref-aws-a30ad655c769
+API Version: pkg.crossplane.io/v1
+Kind: ConfigurationRevision
+# Removed for brevity
+Spec:
+ Desired State: Active
+ Image: xpkg.upbound.io/upbound/platform-ref-aws:v0.6.0
+ Revision: 1
+Status:
+ Conditions:
+ Last Transition Time: 2023-10-06T20:08:14Z
+ Reason: UnhealthyPackageRevision
+ Status: False
+ Type: Healthy
+ Controller Ref:
+ Name:
+Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Warning LintPackage 29s (x2 over 29s) packages/configurationrevision.pkg.crossplane.io incompatible Crossplane version: package is not compatible with Crossplane version (v1.12.0)
+```
+
+The {{}}Events{{}} show a
+{{}}Warning{{}} with a message that the
+current version of Crossplane doesn't meet the Configuration package
+requirements.
+
+## Create a Configuration
+
+Crossplane Configuration packages are
+[OCI container images](https://opencontainers.org/) containing one or more YAML
+files.
+
+{{}}
+Configuration packages are fully OCI compliant. Any tool that builds OCI images
+can build Configuration packages.
+
+It's strongly recommended to use the Crossplane command-line tool to
+provide error checking and formatting to Crossplane package builds.
+
+Read the
+[Crossplane package specification](https://github.com/crossplane/crossplane/blob/master/contributing/specifications/xpkg.md)
+for package requirements when building packages with third-party tools.
+{{}}
+
+A Configuration package requires a `crossplane.yaml` file and may include
+Composition and CompositeResourceDefinition files.
+
+
+### The crossplane.yaml file
+
+
+To build a Configuration package using the Crossplane CLI, create a file
+named
+{{}}crossplane.yaml{{}}.
+The
+{{}}crossplane.yaml{{}}
+file defines the requirements and name of the
+Configuration.
+
+{{}}
+The Crossplane CLI only supports a file named `crossplane.yaml`.
+{{< /hint >}}
+
+Configuration package uses the
+{{}}meta.pkg.crossplane.io{{}}
+Crossplane API group.
+
+Specify any other Configurations, Functions or Providers in the
+{{}}dependsOn{{}} list.
+Optionally, you can require a specific or minimum package version with the
+{{}}version{{}} option.
+
+You can also define a specific or minimum version of Crossplane for this
+Configuration with the
+{{}}crossplane.version{{}} option.
+
+{{}}
+Defining the {{}}crossplane{{}} object
+or required versions is optional.
+{{< /hint >}}
+
+```yaml {label="cfgMeta",copy-lines="all"}
+$ cat crossplane.yaml
+apiVersion: meta.pkg.crossplane.io/v1alpha1
+kind: Configuration
+metadata:
+ name: test-configuration
+spec:
+ dependsOn:
+ - provider: xpkg.upbound.io/crossplane-contrib/provider-aws
+ version: ">=v0.36.0"
+ crossplane:
+ version: ">=v1.12.1-0"
+```
+
+### Build the package
+
+Create the package using the Crossplane CLI command
+`crossplane build configuration -f `.
+
+Where the `` is the directory containing the `crossplane.yaml` file
+and any Composition or CompositeResourceDefinition YAML files.
+
+The CLI recursively searches for `.yml` or `.yaml` files in the directory to
+include in the package.
+
+{{}}
+You must ignore any other YAML files with `--ignore=`.
+For
+example, `crossplane build configuration -f test-directory --ignore=".tmp/*"`.
+
+Including YAML files that aren't Compositions or CompositeResourceDefinitions,
+including Claims isn't supported.
+{{}}
+
+By default, Crossplane creates an `.xpkg` file of the Configuration name and
+a SHA-256 hash of the package contents.
+
+For example, a {{}}Configuration{{}}
+named {{}}test-configuration{{}}.
+The
+Crossplane CLI builds a package named `test-configuration-e8c244f6bf21.xpkg`.
+
+```yaml {label="xpkgName"}
+apiVersion: meta.pkg.crossplane.io/v1alpha1
+kind: Configuration
+metadata:
+ name: test-configuration
+# Removed for brevity
+```
+
+Specify the output file with `--name=` option.
+
+For example, to build a package from a directory named `test-directory` and
+generate a package named `test-package.xpkg` use the command:
+
+```shell
+crossplane build configuration -f test-directory --name=test-package
+```
+
+Crossplane automatically adds the `.xpkg` extension.
+
+Crossplane places the package in the provided directory, in this example,
+`test-directory`.
+
+```shell
+ls test-directory
+composition.yml crossplane.yaml compositeresourcedefinition.yml test-package.xpkg
+```
+
diff --git a/content/v1.14/concepts/patch-and-transform.md b/content/v1.14/concepts/patch-and-transform.md
new file mode 100644
index 000000000..969d7c0e3
--- /dev/null
+++ b/content/v1.14/concepts/patch-and-transform.md
@@ -0,0 +1,1717 @@
+---
+title: Patch and Transforms
+weight: 70
+description: "Crossplane Compositions use patches and transforms to modify inputs from claims and composite resources before creating managed resources"
+---
+
+Crossplane Compositions allow for "patch and transform" operations. With patches
+a Composition can apply changes to the resources defined by the Composition.
+
+When users create Claims, Crossplane passes the settings in the Claim to
+the associated composite resource. Patches can use these settings to change the
+associated composite resource or managed resources.
+
+Examples of using patch and transforms include:
+ * changing the name of the external resource
+ * mapping generic terms like "east" or "west" to specific provider locations
+ * appending custom labels or strings to resource fields
+
+
+{{}}
+
+Crossplane expects patch and transform operations to be simple changes.
+Use [Composition Functions]({{][}}) for more
+complex or programmatic modifications.
+
+{{]}}
+
+
+A Composition [patch](#create-a-patch) is the action of changing a field.
+A Composition [transform](#transform-a-patch) modifies the values before
+applying the patch.
+
+## Create a patch
+
+Patches are part of an individual
+{{}}resource{{}} inside a
+{{}}Composition{{}}.
+
+The {{}}patches{{}} field takes a
+list of patches to apply to the individual resource.
+
+Each patch has a {{}}type{{}}, which
+defines what kind of patch action Crossplane applies.
+
+Patches reference fields inside a composite resource or Composition differently
+depending on the patch type, but all patches reference a
+{{}}fromFieldPath{{}} and
+{{}}toFieldPath{{}}.
+
+The {{}}fromFieldPath{{}} defines
+the patch's input values.
+The {{}}toFieldPath{{}} defines the
+data to change with a patch.
+
+Here is an example patch applied to a resource in a Composition.
+```yaml {label="createComp",copy-lines="none"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+spec:
+ resources:
+ - name: my-composed-resource
+ base:
+ # Removed for brevity
+ patches:
+ - type: FromCompositeFieldPath
+ fromFieldPath: spec.field1
+ toFieldPath: metadata.labels["patchLabel"]
+```
+
+### Selecting fields
+
+Crossplane selects fields in a composite resource or managed
+resource with
+a subset of
+[JSONPath selectors](https://kubernetes.io/docs/reference/kubectl/jsonpath/),
+called "field selectors."
+
+Field selectors can select any field in a composite resource or managed resource
+object, including the `metadata`, `spec` or `status` fields.
+
+Field selectors can be a string matching a field name or an array index, in
+brackets. Field names may use a `.` character to select child elements.
+
+#### Example field selectors
+Here are some example selectors from a composite resource object.
+{{}}
+| Selector | Selected element |
+| --- | --- |
+| `kind` | {{}}kind{{}} |
+| `metadata.labels['crossplane.io/claim-name']` | {{}}my-example-claim{{}} |
+| `spec.desiredRegion` | {{}}eu-north-1{{}} |
+| `spec.resourceRefs[0].name` | {{}}my-example-claim-978mh-r6z64{{}} |
+{{
}}
+
+```yaml {label="select",copy-lines="none"}
+$ kubectl get composite -o yaml
+apiVersion: example.org/v1alpha1
+kind: xExample
+metadata:
+ # Removed for brevity
+ labels:
+ crossplane.io/claim-name: my-example-claim
+ crossplane.io/claim-namespace: default
+ crossplane.io/composite: my-example-claim-978mh
+spec:
+ desiredRegion: eu-north-1
+ field1: field1-text
+ resourceRefs:
+ - apiVersion: s3.aws.upbound.io/v1beta1
+ kind: Bucket
+ name: my-example-claim-978mh-r6z64
+ - apiVersion: s3.aws.upbound.io/v1beta1
+ kind: Bucket
+ name: my-example-claim-978mh-cnlhj
+ - apiVersion: s3.aws.upbound.io/v1beta1
+ kind: Bucket
+ name: my-example-claim-978mh-rv5nm
+ # Removed for brevity
+```
+
+## Reuse a patch
+
+A Composition can reuse a patch object on multiple resources with a
+PatchSet.
+
+To create a PatchSet, define a
+{{}}PatchSets{{}} object inside the
+Composition's
+{{}}spec{{}}.
+
+Each patch inside a PatchSet has a
+{{}}name{{}} and a list of
+{{}}patches{{}}.
+
+{{}}
+For multiple PatchSets only use a single
+{{}}PatchSets{{}} object.
+
+Identify each unique PatchSet with a unique
+{{}}name{{}}.
+{{}}
+
+Apply the PatchSet to a resource with a patch
+{{}}type: PatchSet{{}}.
+Set the
+{{}}patchSetName{{}} to the
+{{}}name{{}} of the PatchSet.
+
+```yaml {label="patchset"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for brevity
+spec:
+ patchSets:
+ - name: my-patchset
+ patches:
+ - type: FromCompositeFieldPath
+ fromFieldPath: spec.desiredRegion
+ toFieldPath: spec.forProvider.region
+ resources:
+ - name: bucket1
+ base:
+ # Removed for brevity
+ patches:
+ - type: PatchSet
+ patchSetName: my-patchset
+ - name: bucket2
+ base:
+ # Removed for brevity
+ patches:
+ - type: PatchSet
+ patchSetName: my-patchset
+```
+
+{{}}
+A PatchSet can't contain other PatchSets.
+
+Crossplane ignores any [transforms](#transform-a-patch) or
+[policies](#patch-policies) in a PatchSet.
+{{< /hint >}}
+
+## Patching between resources
+
+Compositions can't directly patch between resources in the same Composition.
+For example, generating a network resource and patching the resource name to
+a compute resource.
+
+{{}}
+The [ToEnvironmentFieldPath](#toenvironmentfieldpath) patch can't read from a
+`Status` field.
+{{< /hint >}}
+
+A resource can patch to a user-defined
+{{}}Status{{}}
+field in the composite resource.
+
+A resource can then read from that
+{{}}Status{{}}
+field to patch a field.
+
+First, define a custom
+{{}}Status{{}}
+in the Composite Resource Definition and a custom field, for example
+{{}}secondResource{{}}
+
+```yaml {label="xrdPatch",copy-lines="13-17"}
+kind: CompositeResourceDefinition
+# Removed for brevity.
+spec:
+ # Removed for brevity.
+ versions:
+ - name: v1alpha1
+ schema:
+ openAPIV3Schema:
+ type: object
+ properties:
+ spec:
+ # Removed for brevity.
+ status:
+ type: object
+ properties:
+ secondResource:
+ type: string
+```
+
+Inside the Composition the resource with the source data uses a
+{{}}ToCompositeFieldPath{{}}
+patch to write data to the
+{{}}status.secondResource{{}}
+field in the composite resource.
+
+The destination resource uses a
+{{}}FromCompositeFieldPath{{}}
+patch to read data from the composite resource
+{{}}status.secondResource{{}}
+field in the composite resource and write it to a label named
+{{}}secondResource{{}} in the
+managed resource.
+
+```yaml {label="patchBetween",copy-lines="9-11"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+# Removed for brevity
+ - name: bucket1
+ base:
+ apiVersion: s3.aws.upbound.io/v1beta1
+ kind: Bucket
+ # Removed for brevity
+ patches:
+ - type: ToCompositeFieldPath
+ fromFieldPath: metadata.name
+ toFieldPath: status.secondResource
+ - name: bucket2
+ base:
+ apiVersion: s3.aws.upbound.io/v1beta1
+ kind: Bucket
+ # Removed for brevity
+ patches:
+ - type: FromCompositeFieldPath
+ fromFieldPath: status.secondResource
+ toFieldPath: metadata.labels['secondResource']
+```
+
+Describe the composite resource to view the
+{{}}resources{{}} and the
+{{}}status.secondResource{{}}
+value.
+
+```yaml {label="descCompPatch",copy-lines="none"}
+$ kubectl describe composite
+Name: my-example-claim-jp7rx
+Spec:
+ # Removed for brevity
+ Resource Refs:
+ Name: my-example-claim-jp7rx-gfg4m
+ # Removed for brevity
+ Name: my-example-claim-jp7rx-fttpj
+Status:
+ # Removed for brevity
+ Second Resource: my-example-claim-jp7rx-gfg4m
+```
+
+Describe the destination managed resource to see the label
+{{}}secondResource{{}}.
+
+```yaml {label="bucketlabel",copy-lines="none"}
+$ kubectl describe bucket
+kubectl describe bucket my-example-claim-jp7rx-fttpj
+Name: my-example-claim-jp7rx-fttpj
+Labels: crossplane.io/composite=my-example-claim-jp7rx
+ secondResource=my-example-claim-jp7rx-gfg4m
+```
+
+## Types of patches
+Crossplane supports multiple patch types, each using a different source for data
+and applying the patch to a different location.
+
+{{}}
+
+This section describes patches applied to individual resources inside a
+Composition.
+
+For information about applying patches to an entire composite resource with a
+Composition's `environment.patches` read the
+[Environment Configurations]({{[}}) documentation.
+
+{{< /hint >}}
+
+Summary of Crossplane patches
+{{< table "table table-hover" >}}
+| Patch Type | Data Source | Data Destination |
+| --- | --- | --- |
+| [FromCompositeFieldPath](#fromcompositefieldpath) | A field in the composite resource. | A field in the patched managed resource. |
+| [ToCompositeFieldPath](#tocompositefieldpath) | A field in the patched managed resource. | A field in the composite resource. |
+| [CombineFromComposite](#combinefromcomposite) | Multiple fields in the composite resource. | A field in the patched managed resource. |
+| [CombineToComposite](#combinetocomposite) | Multiple fields in the patched managed resource. | A field in the composite resource. |
+| [FromEnvironmentFieldPath](#fromenvironmentfieldpath) | Data in the in-memory EnvironmentConfig Environment | A field in the patched managed resource. |
+| [ToEnvironmentFieldPath](#toenvironmentfieldpath) | A field in the patched managed resource. | The in-memory EnvironmentConfig Environment. |
+| [CombineFromEnvironment](#combinefromenvironment) | Multiple fields in the in-memory EnvironmentConfig Environment. | A field in the patched managed resource. |
+| [CombineToEnvironment](#combinetoenvironment) | Multiple fields in the patched managed resource. | A field in the in-memory EnvironmentConfig Environment. |
+{{< /table >}}
+
+{{}}
+All the following examples use the same set of Compositions,
+CompositeResourceDefinitions, Claims and EnvironmentConfigs.
+Only the applied patches change between
+examples.
+
+All examples rely on Upbound
+[provider-aws-s3](https://marketplace.upbound.io/providers/upbound/provider-aws-s3/)
+to create resources.
+
+{{< expand "Reference Composition" >}}
+```yaml {copy-lines="all"}
+apiVersion: apiextensions.crossplane.io/v1
+kind: Composition
+metadata:
+ name: example-composition
+spec:
+ compositeTypeRef:
+ apiVersion: example.org/v1alpha1
+ kind: xExample
+ environment:
+ environmentConfigs:
+ - ref:
+ name: example-environment
+ resources:
+ - name: bucket1
+ base:
+ apiVersion: s3.aws.upbound.io/v1beta1
+ kind: Bucket
+ spec:
+ forProvider:
+ region: us-east-2
+ - name: bucket2
+ base:
+ apiVersion: s3.aws.upbound.io/v1beta1
+ kind: Bucket
+ spec:
+ forProvider:
+ region: us-east-2
+```
+{{< /expand >}}
+
+{{]