Platform Patterns

Evolving APIs

API implementation change

  • CmpositionRevision is Crossplane concept that will work with compositions to support changes

  • If the --enable-composition-revisions flag is set while installing Crossplane, a CompositionRevision object is created with all the updates to composition

  • The compositions are mutable objects that can change forever, but individual CompositionRevision is immutable

  • Composition and CompositionRevision are in one-to-many relationships

  • Only one CompositionRevision active at any given instance

  • In a Crossplane environment where the composition revision flag is enabled, we will have two attributes automatically added to every XR/Claim object by Crossplane

    • spec.compositionRevisionRef This will hold the name of CompositionRevision with which the resources are created

    • spec.compositionUpdatePolicy This attribute will indicate whether the XR/Claim will automatically migrate to a new, available CompositionRevision. Manual and automatic are the two possible values, with automatic as the default value. If you would like to override the default behavior, add this attribute with a manual indicator in the XR/Claim configuration.

img.png

Enable Composition Revisions

  • Let's try

    • Building an XR API for GCP MySQL provisioning in a composition revision-enabled Crossplane environment

    • Creating two MySQL instances with automated and manual composition revision policies

    • Updating the Composition to change the calculation for database disk size

    • Validating if the MySQL instance with automated revision policy automatically migrates to the latest composition revision

    • Seeing that the MySQL instance with the manual revision policy does not migrate to the latest composition revision

    • Finally, migrating the second MySQL instance manually to the latest composition revision

  • Update composition patch with transform function

  • For manual upgrade update mysql-db-manual with the latest compositionRevisionRef

API contract changes

Non-breaking changes

  • A simple way to think about this is that if Composition/CompositionRevision can handle the co-existence of old and newly provisioned resources, then the XRD contract change is non-breaking

  • To validate whether the first MySQL instance can be sill updated, change the tier with an update YAML


Version upgrade

  • referenceable: flag will determine if we can define a composition implementation for the given version

    • Only one version can have referenceable flag set to true

  • served: will indicate if given XR API version is in use

  • In kubernetesConversion webhook is configured by the CRD author to support conversion between the versions

  • A conversion webhook involves programming.

  • Taking that route will violate the no-code agenda of Crossplane when composing APIs.

  • It’s important to note that the Crossplane community is actively working to build a configuration-based solution to support conversion and migration between versions.


Version upgrade with breaking changes

img.png

Nested and multi-resource XRs

img.png Multi-resource nested XR

  • ESTABLISHED: true: indicates that the Crossplane has started a new controller to reconcile the established XR

  • OFFERED: true: indicates that the Crossplane has started a new controller to reconcile the established Claim only for the application XR


Naming the versions


When we troubleshoot an issue with Crossplane, logs from the Crossplane pod can help. Enable debugging mode by adding an argument, --debug, to the Crossplane pod. Similarly, we can even look at the provider’s container logs.


OpenAPIV3Schema structure

Printer Columns

Last updated