diff --git a/content/master/concepts/compositions.md b/content/master/concepts/compositions.md
index 3f07a94b5..0afa0b6a5 100644
--- a/content/master/concepts/compositions.md
+++ b/content/master/concepts/compositions.md
@@ -1,7 +1,7 @@
---
title: Compositions
weight: 30
-aliases:
+aliases:
- composition
- composition-functions
- /knowledge-base/guides/composition-functions
@@ -9,14 +9,14 @@ description: "Compositions are a template for creating Crossplane resources"
---
Compositions are a template for creating multiple managed resources as a single
-object.
+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.
+resources together.
Here's an example Composition. When you create an
{{}}AcmeBucket{{}} composite resource
@@ -57,12 +57,12 @@ 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.
+ (`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.
+ Composition template to create new managed resources.
* [Claims]({{][}}) (`XRC`) - Like a Composite Resource, but
- with namespace scoping.
+ with namespace scoping.
{{}}
## Create a Composition
@@ -83,8 +83,8 @@ resource (XR).
{{}}
The Crossplane community has built lots of functions that let you template
Crossplane resources using
-[CUE](https://github.com/crossplane-contrib/function-cue),
-[KCL](https://github.com/crossplane-contrib/function-kcl),
+[CUE](https://github.com/crossplane-contrib/function-cue),
+[KCL](https://github.com/crossplane-contrib/function-kcl),
Helm-like
[Go templates](https://github.com/crossplane-contrib/function-go-templating) or
legacy Crossplane
@@ -111,7 +111,7 @@ but the feature is no longer maintained. Crossplane doesn't accept new
See the [CLI documentation]({{][}})
to learn how to use the `crossplane beta convert` command to convert a legacy
-`Resources` Composition to the `Pipeline` mode.
+`Resources` Composition to the `Pipeline` mode.
{{< /hint >}}
@@ -134,7 +134,7 @@ kind: Function
metadata:
name: function-patch-and-transform
spec:
- package: xpkg.crossplane.io/crossplane-contrib/function-patch-and-transform:v0.1.4
+ package: xpkg.crossplane.io/crossplane-contrib/function-patch-and-transform:v0.8.2
```
{{< hint "tip" >}}
@@ -155,7 +155,7 @@ During the install a Function reports `INSTALLED` as `True` and `HEALTHY` as
```shell {copy-lines="1"}
kubectl get functions
NAME INSTALLED HEALTHY PACKAGE AGE
-function-patch-and-transform True Unknown xpkg.crossplane.io/crossplane-contrib/function-patch-and-transform:v0.1.4 10s
+function-patch-and-transform True Unknown xpkg.crossplane.io/crossplane-contrib/function-patch-and-transform:v0.8.2 10s
```
After the Function install completes and it's ready for use the `HEALTHY` status
@@ -174,36 +174,36 @@ composite resource owns.
Crossplane knows what Function to call when a composite resource changes by
looking at the Composition the composite resource uses.
-To use composition functions set the Composition
+To use composition functions set the Composition
{{}}mode{{}} to
{{}}Pipeline{{}}.
-Define a {{}}pipeline{{}} of
-{{}}steps{{}}. Each
-{{}}step{{}} calls a Function.
+Define a {{}}pipeline{{}} of
+{{}}steps{{}}. Each
+{{}}step{{}} calls a Function.
-Each {{}}step{{}} uses a
+Each {{}}step{{}} uses a
{{}}functionRef{{}} to reference the
-{{}}name{{}} of the Function to call.
+{{}}name{{}} of the Function to call.
{{}}
-Compositions using {{}}mode: Pipeline{{}}
-can't specify resource templates with a `resources` field.
+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{{}}.
+Some Functions also allow you to specify an
+{{}}input{{}}.
The function defines the
{{}}kind{{}} of input.
This example uses
[Function Patch and Transform]({{][}}).
Function Patch and Transform implements Crossplane resource
-templates.
-The input kind is {{}}Resources{{}},
+templates.
+The input kind is {{}}Resources{{}},
and it accepts {{}}resources{{}} as input.
```yaml {label="single",copy-lines="none"}
@@ -239,7 +239,7 @@ 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
+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.
@@ -272,22 +272,22 @@ spec:
### Enable composite resources
-A Composition is only a template defining how to create managed
+A Composition is only a template defining how to create managed
resources. A Composition limits which Composite Resources can use this
-template.
+template.
-A Composition's {{}}compositeTypeRef{{}}
-defines which Composite Resource type can use this Composition.
+A Composition's {{}}compositeTypeRef{{}}
+defines which Composite Resource type can use this Composition.
{{}}
-Read more about Composite Resources in the
-[Composite Resources page]({{][}}).
+Read more about Composite Resources in the
+[Composite Resources page]({{][}}).
{{< /hint >}}
-Inside a Composition's
+Inside a Composition's
{{}}spec{{}}
-define the Composite Resource
-{{}}apiVersion{{}} and
+define the Composite Resource
+{{}}apiVersion{{}} and
{{}}kind{{}}
that the Composition allows to use this template.
@@ -306,26 +306,26 @@ spec:
### Store connection details
Some managed resources generate unique details like usernames, passwords, IP
-addresses, ports or other connection details.
+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.
+details.
{{}}
-This section discusses creating Kubernetes secrets.
+This section discusses creating Kubernetes secrets.
Crossplane also supports using external secret stores like
-[HashiCorp Vault](https://www.vaultproject.io/).
+[HashiCorp Vault](https://www.vaultproject.io/).
Read the [external secrets store guide]({{][}}) for more information on using Crossplane
-with an external secret store.
+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.
+object for claims.
Set the value of `writeConnectionSecretsToNamespace` to the namespace where
Crossplane should store the combined secret object.
@@ -344,7 +344,7 @@ spec:
Inside the `spec` of each resource producing connection details, define the
`writeConnectionSecretToRef`, with a `namespace` and `name` of the secret object
-for the resource.
+for the resource.
If a `writeConnectionSecretToRef` isn't defined, Crossplane doesn't write any
keys to the secret.
@@ -389,10 +389,10 @@ Remember to create a unique name for each secret.
#### External secret stores
-Crossplane
-[External Secret Stores]({{[}})
+Crossplane
+[External Secret Stores]({{][}})
write secrets and connection details to external secret stores like HashiCorp
-Vault.
+Vault.
{{}}
External Secret Stores are an alpha feature.
@@ -403,7 +403,7 @@ Stores by default.
Use `publishConnectionDetailsWithStoreConfigRef` in place of
`writeConnectionSecretsToNamespace` to define the `StoreConfig` to save
-connection details to.
+connection details to.
For example, using a `StoreConfig` with the `name` "vault," use
`publishConnectionDetailsWithStoreConfigRef.name` matching the
@@ -421,13 +421,13 @@ apiVersion: apiextensions.crossplane.io/v1
kind: Composition
# Removed for Brevity
spec:
- publishConnectionDetailsWithStoreConfigRef:
+ publishConnectionDetailsWithStoreConfigRef:
name: vault
# Removed for brevity
```
For more details read the
-[External Secret Stores]({{][}})
+[External Secret Stores]({{][}})
integration guide.
## Test a composition
@@ -451,7 +451,7 @@ Running `crossplane render` requires [Docker](https://www.docker.com).
{{< /hint >}}
Provide a composite resource, composition and composition functions to render
-the output locally.
+the output locally.
```shell
crossplane render xr.yaml composition.yaml functions.yaml
@@ -545,7 +545,7 @@ kind: Function
metadata:
name: function-patch-and-transform
spec:
- package: xpkg.crossplane.io/crossplane-contrib/function-patch-and-transform:v0.1.4
+ package: xpkg.crossplane.io/crossplane-contrib/function-patch-and-transform:v0.8.2
```
{{}}
@@ -576,7 +576,7 @@ metadata:
annotations:
render.crossplane.io/runtime: Development
spec:
- package: xpkg.crossplane.io/crossplane-contrib/function-patch-and-transform:v0.1.4
+ package: xpkg.crossplane.io/crossplane-contrib/function-patch-and-transform:v0.8.2
```
{{}}
@@ -616,18 +616,18 @@ xsqlinstances.aws.platformref.upbound.io XSQLInstance aws.platformref.upboun
```
The `XR-KIND` lists the Composite Resource `kind` that's allowed to use the
-Composition template.
+Composition template.
The `XR-APIVERSION` lists the Composite Resource API versions allowed to use the
-Composition template.
+Composition template.
{{}}
The output of `kubectl get composition` is different than `kubectl get
-composite`.
+composite`.
`kubectl get composition` lists all available Compositions.
`kubectl get composite` lists all created Composite Resources and their related
-Composition.
+Composition.
{{< /hint >}}
## Composition validation
@@ -657,18 +657,18 @@ If using `mode: Pipeline` (Composition Functions):
### 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
+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.
+beta features by default.
Disable schema aware validation by setting the
`--enable-composition-webhook-schema-validation=false` flag on the Crossplane
-pod.
+pod.
The [Crossplane Pods]({{][}}) page has
more information on enabling Crossplane flags.
@@ -698,12 +698,12 @@ The following modes are available:
{{< /table >}}
Change the validation mode for a Composition with the
-{{}}crossplane.io/composition-schema-aware-validation-mode{{}}
+{{}}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
+For example, to enable `loose` mode checking set the annotation value to
{{}}loose{{}}.
```yaml {copy-lines="none",label="mode"}
@@ -827,7 +827,7 @@ Crossplane errors if stability isn't reached after 5 iterations.
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.
+a ProviderConfig, or another kind of composite resource.
{{]}}
@@ -986,4 +986,4 @@ 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`.
\ No newline at end of file
+`apiextensions.crossplane.io/environment`.
diff --git a/content/master/getting-started/provider-aws-part-2.md b/content/master/getting-started/provider-aws-part-2.md
index 12e6a66e5..05c045bfb 100644
--- a/content/master/getting-started/provider-aws-part-2.md
+++ b/content/master/getting-started/provider-aws-part-2.md
@@ -7,7 +7,7 @@ aliases:
---
{{< hint "important" >}}
-This guide is part 2 of a series.
+This guide is part 2 of a series.
[**Part 1**]({{][}}) covers
to installing Crossplane and connect your Kubernetes cluster to AWS.
@@ -36,7 +36,7 @@ crossplane-stable/crossplane \
```
2. When the Crossplane pods finish installing and are ready, apply the AWS Provider
-
+
```yaml {label="provider",copy-lines="all"}
cat <
Crossplane allows you to build your own custom APIs for your users, abstracting
away details about the cloud provider and their resources. You can make your API
-as complex or simple as you wish.
+as complex or simple as you wish.
-The custom API is a Kubernetes object.
+The custom API is a Kubernetes object.
Here is an example custom API.
```yaml {label="exAPI"}
@@ -127,39 +127,39 @@ apiVersion: database.example.com/v1alpha1
kind: NoSQL
metadata:
name: my-nosql-database
-spec:
+spec:
location: "US"
```
-Like any Kubernetes object the API has a
-{{}}version{{}},
-{{}}kind{{}} and
+Like any Kubernetes object the API has a
+{{}}version{{}},
+{{}}kind{{}} and
{{}}spec{{}}.
### Define a group and version
-To create your own API start by defining an
-[API group](https://kubernetes.io/docs/reference/using-api/#api-groups) and
-[version](https://kubernetes.io/docs/reference/using-api/#api-versioning).
+To create your own API start by defining an
+[API group](https://kubernetes.io/docs/reference/using-api/#api-groups) and
+[version](https://kubernetes.io/docs/reference/using-api/#api-versioning).
The _group_ can be any value, but common convention is to map to a fully
-qualified domain name.
+qualified domain name.
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
+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.
+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.
+* `v1` - A stable API that doesn't have breaking changes.
-This guide uses the group
+This guide uses the group
{{}}database.example.com{{}}.
Because this is the first version of the API, this guide uses the version
@@ -176,10 +176,10 @@ individual kinds representing different resources.
For example a `database` group may have a `Relational` and `NoSQL` kinds.
-The `kind` can be anything, but it must be
+The `kind` can be anything, but it must be
[UpperCamelCased](https://kubernetes.io/docs/contribute/style/style-guide/#use-upper-camel-case-for-api-objects).
-This API's kind is
+This API's kind is
{{}}NoSQL{{}}
```yaml {label="kind",copy-lines="none"}
@@ -190,51 +190,51 @@ kind: NoSQL
### Define a spec
The most important part of an API is the schema. The schema defines the inputs
-accepted from users.
+accepted from users.
-This API allows users to provide a
-{{}}location{{}} of where to run their
+This API allows users to provide a
+{{}}location{{}} of where to run their
cloud resources.
All other resource settings can't be configurable by the users. This allows
Crossplane to enforce any policies and standards without worrying about
-user errors.
+user errors.
```yaml {label="spec",copy-lines="none"}
apiVersion: database.example.com/v1alpha1
kind: NoSQL
-spec:
+spec:
location: "US"
```
### Apply the API
-Crossplane uses
-{{}}Composite Resource Definitions{{}}
+Crossplane uses
+{{}}Composite Resource Definitions{{}}
(also called an `XRD`) to install your custom API in
-Kubernetes.
+Kubernetes.
The XRD {{}}spec{{}} contains all the
-information about the API including the
+information about the API including the
{{}}group{{}},
{{}}version{{}},
-{{}}kind{{}} and
+{{}}kind{{}} and
{{}}schema{{}}.
The XRD's {{}}name{{}} must be the
-combination of the {{}}plural{{}} and
+combination of the {{}}plural{{}} and
{{}}group{{}}.
The {{}}schema{{}} uses the
{{}}OpenAPIv3{{}} specification to define
-the API {{}}spec{{}}.
+the API {{}}spec{{}}.
The API defines a {{}}location{{}} that
-must be {{}}oneOf{{}} either
-{{}}EU{{}} or
+must be {{}}oneOf{{}} either
+{{}}EU{{}} or
{{}}US{{}}.
-Apply this XRD to create the custom API in your Kubernetes cluster.
+Apply this XRD to create the custom API in your Kubernetes cluster.
```yaml {label="xrd",copy-lines="all"}
cat <}}claimNames{{}} allows users
-to access this API either at the cluster level with the
+to access this API either at the cluster level with the
{{}}nosql{{}} endpoint or in a namespace
-with the
-{{}}nosqlclaim{{}} endpoint.
+with the
+{{}}nosqlclaim{{}} endpoint.
The namespace scoped API is a Crossplane _Claim_.
{{}}
For more details on the fields and options of Composite Resource Definitions
-read the
-[XRD documentation]({{][}}).
+read the
+[XRD documentation]({{][}}).
{{< /hint >}}
-View the installed XRD with `kubectl get xrd`.
+View the installed XRD with `kubectl get xrd`.
```shell {copy-lines="1"}
kubectl get xrd
@@ -307,20 +307,20 @@ When users access the custom API Crossplane takes their inputs and combines them
with a template describing what infrastructure to deploy. Crossplane calls this
template a _Composition_.
-The {{}}Composition{{}} defines all the
+The {{}}Composition{{}} defines all the
cloud resources to deploy. Each entry in the template is a full resource
definition, defining all the resource settings and metadata like labels and
-annotations.
+annotations.
-This template creates an AWS
+This template creates an AWS
{{}}S3{{}}
-{{}}Bucket{{}} and a
+{{}}Bucket{{}} and a
{{}}DynamoDB{{}}
{{}}Table{{}}.
-This Composition takes the user's
-{{}}location{{}} input and uses it as the
-{{}}region{{}} used in the individual
+This Composition takes the user's
+{{}}location{{}} input and uses it as the
+{{}}region{{}} used in the individual
resource.
{{}}
@@ -336,7 +336,7 @@ Read the [Composition documentation]({{][}}) for
more information on configuring Compositions and all the available options.
{{< /hint >}}
-Apply this Composition to your cluster.
+Apply this Composition to your cluster.
```yaml {label="comp",copy-lines="all"}
cat <}}) for
more information on configuring Compositions and all the available options.
-Read the
-[Patch and Transform function documentation]({{][}})
+Read the
+[Patch and Transform function documentation]({{][}})
for more information on how it uses patches to map user inputs to Composition
resource templates.
{{< /hint >}}
@@ -459,7 +459,7 @@ apiVersion: database.example.com/v1alpha1
kind: NoSQL
metadata:
name: my-nosql-database
-spec:
+spec:
location: "US"
EOF
```
@@ -472,10 +472,10 @@ NAME SYNCED READY COMPOSITION AGE
my-nosql-database True True dynamo-with-bucket 14s
```
-This object is a Crossplane _composite resource_ (also called an `XR`).
+This object is a Crossplane _composite resource_ (also called an `XR`).
It's a
single object representing the collection of resources created from the
-Composition template.
+Composition template.
View the individual resources with `kubectl get managed`
@@ -508,17 +508,17 @@ No resources found
## Using the API with namespaces
-Accessing the API `nosql` happens at the cluster scope.
+Accessing the API `nosql` happens at the cluster scope.
Most organizations
-isolate their users into namespaces.
+isolate their users into namespaces.
A Crossplane _Claim_ is the custom API in a namespace.
Creating a _Claim_ is just like accessing the custom API endpoint, but with the
-{{}}kind{{}}
+{{}}kind{{}}
from the custom API's `claimNames`.
-Create a new namespace to test create a Claim in.
+Create a new namespace to test create a Claim in.
```shell
kubectl create namespace crossplane-test
@@ -533,7 +533,7 @@ kind: NoSQLClaim
metadata:
name: my-nosql-database
namespace: crossplane-test
-spec:
+spec:
location: "US"
EOF
```
@@ -546,7 +546,7 @@ my-nosql-database True True 17s
```
The Claim automatically creates a composite resource, which creates the managed
-resources.
+resources.
View the Crossplane created composite resource with `kubectl get composite`.
@@ -595,9 +595,9 @@ No resources found
```
## Next steps
-* Explore AWS resources that Crossplane can configure in the
+* Explore AWS resources that Crossplane can configure in the
[provider CRD reference](https://github.com/crossplane-contrib/provider-upjet-aws/blob/main/package/crds).
-* Join the [Crossplane Slack](https://slack.crossplane.io/) and connect with
+* Join the [Crossplane Slack](https://slack.crossplane.io/) and connect with
Crossplane users and contributors.
* Read more about the [Crossplane concepts]({{][}}) to find out what else you can do
- with Crossplane.
+ with Crossplane.
diff --git a/content/master/getting-started/provider-azure-part-2.md b/content/master/getting-started/provider-azure-part-2.md
index b7f8418c6..c9a62d5e7 100644
--- a/content/master/getting-started/provider-azure-part-2.md
+++ b/content/master/getting-started/provider-azure-part-2.md
@@ -7,7 +7,7 @@ aliases:
---
{{< hint "important" >}}
-This guide is part 2 of a series.
+This guide is part 2 of a series.
[**Part 1**]({{][}}) covers
to installing Crossplane and connect your Kubernetes cluster to Azure.
@@ -35,9 +35,9 @@ crossplane-stable/crossplane \
--create-namespace
```
-2. When the Crossplane pods finish installing and are ready, apply the Azure
+2. When the Crossplane pods finish installing and are ready, apply the Azure
Provider
-
+
```yaml {label="provider",copy-lines="all"}
cat <}}
```console
@@ -91,10 +91,10 @@ EOF
Crossplane allows you to build your own custom APIs for your users, abstracting
away details about the cloud provider and their resources. You can make your API
-as complex or simple as you wish.
+as complex or simple as you wish.
-The custom API is a Kubernetes object.
+The custom API is a Kubernetes object.
Here is an example custom API.
```yaml {label="exAPI"}
@@ -102,39 +102,39 @@ apiVersion: compute.example.com/v1alpha1
kind: VirtualMachine
metadata:
name: my-vm
-spec:
+spec:
location: "US"
```
-Like any Kubernetes object the API has a
-{{}}version{{}},
-{{}}kind{{}} and
+Like any Kubernetes object the API has a
+{{}}version{{}},
+{{}}kind{{}} and
{{}}spec{{}}.
### Define a group and version
-To create your own API start by defining an
-[API group](https://kubernetes.io/docs/reference/using-api/#api-groups) and
-[version](https://kubernetes.io/docs/reference/using-api/#api-versioning).
+To create your own API start by defining an
+[API group](https://kubernetes.io/docs/reference/using-api/#api-groups) and
+[version](https://kubernetes.io/docs/reference/using-api/#api-versioning).
The _group_ can be any value, but common convention is to map to a fully
-qualified domain name.
+qualified domain name.
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
+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.
+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.
+* `v1` - A stable API that doesn't have breaking changes.
-This guide uses the group
+This guide uses the group
{{}}compute.example.com{{}}.
Because this is the first version of the API, this guide uses the version
@@ -151,10 +151,10 @@ individual kinds representing different resources.
For example a `compute` group may have a `VirtualMachine` and `BareMetal` kinds.
-The `kind` can be anything, but it must be
+The `kind` can be anything, but it must be
[UpperCamelCased](https://kubernetes.io/docs/contribute/style/style-guide/#use-upper-camel-case-for-api-objects).
-This API's kind is
+This API's kind is
{{}}VirtualMachine{{}}
```yaml {label="kind",copy-lines="none"}
@@ -165,51 +165,51 @@ kind: VirtualMachine
### Define a spec
The most important part of an API is the schema. The schema defines the inputs
-accepted from users.
+accepted from users.
-This API allows users to provide a
-{{}}location{{}} of where to run their
+This API allows users to provide a
+{{}}location{{}} of where to run their
cloud resources.
All other resource settings can't be configurable by the users. This allows
Crossplane to enforce any policies and standards without worrying about
-user errors.
+user errors.
```yaml {label="spec",copy-lines="none"}
apiVersion: compute.example.com/v1alpha1
kind: VirtualMachine
-spec:
+spec:
location: "US"
```
### Apply the API
-Crossplane uses
-{{}}Composite Resource Definitions{{}}
+Crossplane uses
+{{}}Composite Resource Definitions{{}}
(also called an `XRD`) to install your custom API in
-Kubernetes.
+Kubernetes.
The XRD {{}}spec{{}} contains all the
-information about the API including the
+information about the API including the
{{}}group{{}},
{{}}version{{}},
-{{}}kind{{}} and
+{{}}kind{{}} and
{{}}schema{{}}.
The XRD's {{}}name{{}} must be the
-combination of the {{}}plural{{}} and
+combination of the {{}}plural{{}} and
{{}}group{{}}.
The {{}}schema{{}} uses the
{{}}OpenAPIv3{{}} specification to define
-the API {{}}spec{{}}.
+the API {{}}spec{{}}.
The API defines a {{}}location{{}} that
-must be {{}}oneOf{{}} either
-{{}}EU{{}} or
+must be {{}}oneOf{{}} either
+{{}}EU{{}} or
{{}}US{{}}.
-Apply this XRD to create the custom API in your Kubernetes cluster.
+Apply this XRD to create the custom API in your Kubernetes cluster.
```yaml {label="xrd",copy-lines="all"}
cat <}}claimNames{{}} allows users
-to access this API either at the cluster level with the
+to access this API either at the cluster level with the
{{}}VirtualMachine{{}} endpoint or in a namespace
-with the
-{{}}VirtualMachineClaim{{}} endpoint.
+with the
+{{}}VirtualMachineClaim{{}} endpoint.
The namespace scoped API is a Crossplane _Claim_.
{{}}
For more details on the fields and options of Composite Resource Definitions
-read the
-[XRD documentation]({{][}}).
+read the
+[XRD documentation]({{][}}).
{{< /hint >}}
-View the installed XRD with `kubectl get xrd`.
+View the installed XRD with `kubectl get xrd`.
```shell {copy-lines="1"}
kubectl get xrd
@@ -282,22 +282,22 @@ When users access the custom API Crossplane takes their inputs and combines them
with a template describing what infrastructure to deploy. Crossplane calls this
template a _Composition_.
-The {{}}Composition{{}} defines all the
+The {{}}Composition{{}} defines all the
cloud resources to deploy.
Each entry in the template
is a full resource definitions, defining all the resource settings and metadata
-like labels and annotations.
+like labels and annotations.
This template creates an Azure
{{}}LinuxVirtualMachine{{}}
-{{}}NetworkInterface{{}},
+{{}}NetworkInterface{{}},
{{}}Subnet{{}}
{{}}VirtualNetwork{{}} and
{{}}ResourceGroup{{}}.
-This Composition takes the user's
-{{}}location{{}} input and uses it as the
-{{}}location{{}} used in the individual
+This Composition takes the user's
+{{}}location{{}} input and uses it as the
+{{}}location{{}} used in the individual
resource.
{{}}
@@ -313,7 +313,7 @@ Read the [Composition documentation]({{][}}) for
more information on configuring Compositions and all the available options.
{{< /hint >}}
-Apply this Composition to your cluster.
+Apply this Composition to your cluster.
```yaml {label="comp",copy-lines="all"}
cat <}}) for
more information on configuring Compositions and all the available options.
-Read the
-[Patch and Transform function documentation]({{][}})
+Read the
+[Patch and Transform function documentation]({{][}})
for more information on how it uses patches to map user inputs to Composition
resource templates.
{{< /hint >}}
@@ -485,9 +485,9 @@ crossplane-quickstart-vm-with-network XVirtualMachine custom-api.example.org
## Install the Azure virtual machine provider
Part 1 only installed the Azure Virtual Network Provider. To deploying virtual
-machines requires the Azure Compute provider as well.
+machines requires the Azure Compute provider as well.
-Add the new Provider to the cluster.
+Add the new Provider to the cluster.
```yaml
cat <}}VirtualMachine{{}} object to
+Create a {{}}VirtualMachine{{}} object to
create the cloud resources.
```yaml {copy-lines="all",label="xr"}
@@ -525,7 +525,7 @@ apiVersion: compute.example.com/v1alpha1
kind: VirtualMachine
metadata:
name: my-vm
-spec:
+spec:
location: "EU"
EOF
```
@@ -542,10 +542,10 @@ NAME SYNCED READY COMPOSITION AGE
my-vm True True crossplane-quickstart-vm-with-network 3m3s
```
-This object is a Crossplane _composite resource_ (also called an `XR`).
+This object is a Crossplane _composite resource_ (also called an `XR`).
It's a
single object representing the collection of resources created from the
-Composition template.
+Composition template.
View the individual resources with `kubectl get managed`
@@ -568,7 +568,7 @@ virtualnetwork.network.azure.upbound.io/my-vm-pd2sw True True my-vm-pd2
```
Accessing the API created all five resources defined in the template and linked
-them together.
+them together.
Look at a specific resource to see it's created in the location used in the API.
@@ -598,17 +598,17 @@ No resources found
## Using the API with namespaces
-Accessing the API `VirtualMachine` happens at the cluster scope.
+Accessing the API `VirtualMachine` happens at the cluster scope.
Most organizations
-isolate their users into namespaces.
+isolate their users into namespaces.
A Crossplane _Claim_ is the custom API in a namespace.
Creating a _Claim_ is just like accessing the custom API endpoint, but with the
-{{}}kind{{}}
+{{}}kind{{}}
from the custom API's `claimNames`.
-Create a new namespace to test create a Claim in.
+Create a new namespace to test create a Claim in.
```shell
kubectl create namespace crossplane-test
@@ -623,7 +623,7 @@ kind: VirtualMachineClaim
metadata:
name: my-namespaced-vm
namespace: crossplane-test
-spec:
+spec:
location: "EU"
EOF
```
@@ -636,7 +636,7 @@ my-namespaced-vm True True 5m11s
```
The Claim automatically creates a composite resource, which creates the managed
-resources.
+resources.
View the Crossplane created composite resource with `kubectl get composite`.
@@ -693,9 +693,9 @@ No resources found
```
## Next steps
-* Explore Azure resources that Crossplane can configure in the
+* Explore Azure resources that Crossplane can configure in the
[Provider CRD reference](https://github.com/crossplane-contrib/provider-upjet-azure/tree/main/package/crds).
-* Join the [Crossplane Slack](https://slack.crossplane.io/) and connect with
+* Join the [Crossplane Slack](https://slack.crossplane.io/) and connect with
Crossplane users and contributors.
* Read more about the [Crossplane concepts]({{][}}) to find out
- what else you can do with Crossplane.
+ what else you can do with Crossplane.
diff --git a/content/master/getting-started/provider-gcp-part-2.md b/content/master/getting-started/provider-gcp-part-2.md
index 550fa484b..56731db52 100644
--- a/content/master/getting-started/provider-gcp-part-2.md
+++ b/content/master/getting-started/provider-gcp-part-2.md
@@ -7,20 +7,20 @@ aliases:
---
{{< hint "important" >}}
-This guide is part 2 of a series.
+This guide is part 2 of a series.
[**Part 1**]({{][}}) covers
to installing Crossplane and connect your Kubernetes cluster to GCP.
{{< /hint >}}
-This guide walks you through building and accessing a custom API with
+This guide walks you through building and accessing a custom API with
Crossplane.
## Prerequisites
* Complete [quickstart part 1]({{][}}) connecting Kubernetes
to GCP.
-* a GCP account with permissions to create a 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).
@@ -37,9 +37,9 @@ crossplane-stable/crossplane \
--create-namespace
```
-2. When the Crossplane pods finish installing and are ready, apply the GCP
+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)
+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 >}}
@@ -69,12 +69,12 @@ generic gcp-secret \
```
5. Create a _ProviderConfig_
-Include your
+Include your
{{< hover label="providerconfig" line="7" >}}GCP project ID{{< /hover >}} in the
_ProviderConfig_ settings.
{{< hint type="tip" >}}
-Find your GCP project ID from the `project_id` field of the
+Find your GCP project ID from the `project_id` field of the
`gcp-credentials.json` file.
{{< /hint >}}
@@ -101,11 +101,11 @@ EOF
## Install the PubSub Provider
-Part 1 only installed the GCP Storage Provider. This section deploys a
-PubSub Topic along with a GCP storage bucket.
+Part 1 only installed the GCP Storage Provider. This section deploys a
+PubSub Topic along with a GCP storage bucket.
First install the GCP PubSub Provider.
-Add the new Provider to the cluster.
+Add the new Provider to the cluster.
```yaml
cat <
Crossplane allows you to build your own custom APIs for your users, abstracting
away details about the cloud provider and their resources. You can make your API
-as complex or simple as you wish.
+as complex or simple as you wish.
-The custom API is a Kubernetes object.
+The custom API is a Kubernetes object.
Here is an example custom API.
```yaml {label="exAPI"}
@@ -145,39 +145,39 @@ apiVersion: database.example.com/v1alpha1
kind: NoSQL
metadata:
name: my-nosql-database
-spec:
+spec:
location: "US"
```
-Like any Kubernetes object the API has a
-{{}}version{{}},
-{{}}kind{{}} and
+Like any Kubernetes object the API has a
+{{}}version{{}},
+{{}}kind{{}} and
{{}}spec{{}}.
### Define a group and version
-To create your own API start by defining an
-[API group](https://kubernetes.io/docs/reference/using-api/#api-groups) and
-[version](https://kubernetes.io/docs/reference/using-api/#api-versioning).
+To create your own API start by defining an
+[API group](https://kubernetes.io/docs/reference/using-api/#api-groups) and
+[version](https://kubernetes.io/docs/reference/using-api/#api-versioning).
The _group_ can be any value, but common convention is to map to a fully
-qualified domain name.
+qualified domain name.
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
+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.
+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.
+* `v1` - A stable API that doesn't have breaking changes.
-This guide uses the group
+This guide uses the group
{{}}database.example.com{{}}.
Because this is the first version of the API, this guide uses the version
@@ -194,10 +194,10 @@ individual kinds representing different resources.
For example a `queue` group may have a `PubSub` and `CloudTask` kinds.
-The `kind` can be anything, but it must be
+The `kind` can be anything, but it must be
[UpperCamelCased](https://kubernetes.io/docs/contribute/style/style-guide/#use-upper-camel-case-for-api-objects).
-This API's kind is
+This API's kind is
{{}}PubSub{{}}
```yaml {label="kind",copy-lines="none"}
@@ -208,51 +208,51 @@ kind: PubSub
### Define a spec
The most important part of an API is the schema. The schema defines the inputs
-accepted from users.
+accepted from users.
-This API allows users to provide a
-{{}}location{{}} of where to run their
+This API allows users to provide a
+{{}}location{{}} of where to run their
cloud resources.
All other resource settings can't be configurable by the users. This allows
Crossplane to enforce any policies and standards without worrying about
-user errors.
+user errors.
```yaml {label="spec",copy-lines="none"}
apiVersion: queue.example.com/v1alpha1
kind: PubSub
-spec:
+spec:
location: "US"
```
### Apply the API
-Crossplane uses
-{{}}Composite Resource Definitions{{}}
+Crossplane uses
+{{}}Composite Resource Definitions{{}}
(also called an `XRD`) to install your custom API in
-Kubernetes.
+Kubernetes.
The XRD {{}}spec{{}} contains all the
-information about the API including the
+information about the API including the
{{}}group{{}},
{{}}version{{}},
-{{}}kind{{}} and
+{{}}kind{{}} and
{{}}schema{{}}.
The XRD's {{}}name{{}} must be the
-combination of the {{}}plural{{}} and
+combination of the {{}}plural{{}} and
{{}}group{{}}.
The {{}}schema{{}} uses the
{{}}OpenAPIv3{{}} specification to define
-the API {{}}spec{{}}.
+the API {{}}spec{{}}.
The API defines a {{}}location{{}} that
-must be {{}}oneOf{{}} either
-{{}}EU{{}} or
+must be {{}}oneOf{{}} either
+{{}}EU{{}} or
{{}}US{{}}.
-Apply this XRD to create the custom API in your Kubernetes cluster.
+Apply this XRD to create the custom API in your Kubernetes cluster.
```yaml {label="xrd",copy-lines="all"}
cat <}}claimNames{{}} allows users
-to access this API either at the cluster level with the
+to access this API either at the cluster level with the
{{}}pubsub{{}} endpoint or in a namespace
-with the
-{{}}pubsubclaim{{}} endpoint.
+with the
+{{}}pubsubclaim{{}} endpoint.
The namespace scoped API is a Crossplane _Claim_.
{{}}
For more details on the fields and options of Composite Resource Definitions
-read the
-[XRD documentation]({{][}}).
+read the
+[XRD documentation]({{][}}).
{{< /hint >}}
-View the installed XRD with `kubectl get xrd`.
+View the installed XRD with `kubectl get xrd`.
```shell {copy-lines="1"}
kubectl get xrd
@@ -325,21 +325,21 @@ When users access the custom API Crossplane takes their inputs and combines them
with a template describing what infrastructure to deploy. Crossplane calls this
template a _Composition_.
-The {{}}Composition{{}} defines all the
+The {{}}Composition{{}} defines all the
cloud resources to deploy.
Each entry in the template
is a full resource definitions, defining all the resource settings and metadata
-like labels and annotations.
+like labels and annotations.
This template creates a GCP
{{}}Storage{{}}
-{{}}Bucket{{}} and a
+{{}}Bucket{{}} and a
{{}}PubSub{{}}
{{}}Topic{{}}.
-This Composition takes the user's
-{{}}location{{}} input and uses it as the
-{{}}location{{}} used in the individual
+This Composition takes the user's
+{{}}location{{}} input and uses it as the
+{{}}location{{}} used in the individual
resource.
{{}}
@@ -355,7 +355,7 @@ Read the [Composition documentation]({{][}}) for
more information on configuring Compositions and all the available options.
{{< /hint >}}
-Apply this Composition to your cluster.
+Apply this Composition to your cluster.
```yaml {label="comp",copy-lines="all"}
cat <}}) for
more information on configuring Compositions and all the available options.
-Read the
-[Patch and Transform function documentation]({{][}})
+Read the
+[Patch and Transform function documentation]({{][}})
for more information on how it uses patches to map user inputs to Composition
resource templates.
{{< /hint >}}
@@ -464,7 +464,7 @@ apiVersion: queue.example.com/v1alpha1
kind: PubSub
metadata:
name: my-pubsub-queue
-spec:
+spec:
location: "US"
EOF
```
@@ -477,10 +477,10 @@ NAME SYNCED READY COMPOSITION AGE
my-pubsub-queue True True topic-with-bucket 2m12s
```
-This object is a Crossplane _composite resource_ (also called an `XR`).
+This object is a Crossplane _composite resource_ (also called an `XR`).
It's a
single object representing the collection of resources created from the
-Composition template.
+Composition template.
View the individual resources with `kubectl get managed`
@@ -513,17 +513,17 @@ No resources found
## Using the API with namespaces
-Accessing the API `pubsub` happens at the cluster scope.
+Accessing the API `pubsub` happens at the cluster scope.
Most organizations
-isolate their users into namespaces.
+isolate their users into namespaces.
A Crossplane _Claim_ is the custom API in a namespace.
Creating a _Claim_ is just like accessing the custom API endpoint, but with the
-{{}}kind{{}}
+{{}}kind{{}}
from the custom API's `claimNames`.
-Create a new namespace to test create a Claim in.
+Create a new namespace to test create a Claim in.
```shell
kubectl create namespace crossplane-test
@@ -535,10 +535,10 @@ Then create a Claim in the `crossplane-test` namespace.
cat <}}) to find out what else you can do
- with Crossplane.
\ No newline at end of file
+ with Crossplane.
diff --git a/content/master/guides/function-patch-and-transform.md b/content/master/guides/function-patch-and-transform.md
index c242449ca..dff4f21ed 100644
--- a/content/master/guides/function-patch-and-transform.md
+++ b/content/master/guides/function-patch-and-transform.md
@@ -92,7 +92,7 @@ kind: Function
metadata:
name: function-patch-and-transform
spec:
- package: xpkg.crossplane.io/crossplane-contrib/function-patch-and-transform:v0.1.4
+ package: xpkg.crossplane.io/crossplane-contrib/function-patch-and-transform:v0.8.2
```
{{}}
@@ -507,7 +507,7 @@ 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
+All examples rely on
[provider-aws-s3](https://github.com/crossplane-contrib/provider-upjet-aws)
to create resources.
]