Update Helm release crossplane to v2 (main)

Sylva Renovate botrequested to merge
renovate/main-crossplane-2.x into main

This MR contains the following updates:

Package Update Change
crossplane (source) major 1.20.1 -> 2.0.2

⚠️ Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Release Notes

crossplane/crossplane (crossplane)

v2.0.2

Compare Source

This is a patch release scoped to fixing issues reported by users of Crossplane v2.0.

What's Changed

Full Changelog: https://github.com/crossplane/crossplane/compare/v2.0.1...v2.0.2

v2.0.1

Compare Source

This is a patch release scoped to fixing issues reported by users of Crossplane v2.0.

⚠️ Install latest v2.0 patch release

v2.0.1 has some blocking issues that were discovered after extended post-release testing and feedback. It is not the most recent v2 patch release. We strongly advise installing the latest patch (v2.0.2 as of this writing) to have the highest quality experience in your control plane.

The most recent patch has been promoted to the stable channel, so if you simply install or upgrade using the stable channel, you don't need to take any further action.

What's Changed

Full Changelog: https://github.com/crossplane/crossplane/compare/v2.0.0...v2.0.1

v2.0.0

Compare Source

The v2.0.0 release is the first major version update in years for the Crossplane project. It takes all the feedback and lessons from our amazing community of adopters of v1.x releases over the last 5 years and incorporates them into an improved, more capable, and streamlined experience. There are so many exciting enhancements that we are happy to share with the community today, as well as important changes to understand and consider when upgrading from v1.20.

⚠️ Install latest v2.0 patch release

v2.0.0 has some blocking issues that were discovered after extended post-release testing and feedback. It is not the most recent v2 patch release. We strongly advise installing the latest patch (v2.0.2 as of this writing) to have the highest quality experience in your control plane.

The most recent patch has been promoted to the stable channel, so if you simply install or upgrade using the stable channel, you don't need to take any further action.

Upgrade from v1

It is strongly advised to upgrade to v2.0 from the most recent v1 minor version, which is v1.20. Upon upgrade for each minor release, Crossplane performs any necessary migrations of its CRDs to ensure the latest versions are stored in the Kubernetes API server. Therefore, it is important to upgrade sequentially through one minor version at a time.

For example, if you are currently on v1.18, then you should first upgrade to v1.19, then v1.20, before finally upgrading to v2.0. The upgrade path in this example looks like v1.18 --> v1.19 --> v1.20 --> v2.0. To reiterate, you should be running a v1.20 version before you upgrade to v2.0.

🎉 Highlights

The v2 release is chock full of awesome new features that focus on making Crossplane easier to use, operate, and understand as well as be a better fit for application level resources in addition to infrastructure.

  • Broader composition capabilities - Compositions can now include any Kubernetes resource, e.g. Deployment, Configmap, Secret, custom resources - anything from the Kubernetes API, not just Crossplane-defined resources. This enables full-stack abstractions of both applications and infrastructure and makes Crossplane a great fit for your entire tech stack.
  • Namespaced by default - Composite Resources (XRs) and Managed Resources (MRs) are now namespaced by default, providing better isolation boundaries for your end users and aligning better with Kubernetes conventions and practices.
  • Declarative day two operations - The new Operation type supports one-off, scheduled, and event-driven workflows for operational tasks like backups, rolling upgrades, configuration validation, and scheduled maintenance.
  • Managed resource filtering - When installing a provider, you can now install only the specific managed resources you need instead of getting everything from a provider. No more 100's of CRDs that slow down your control plane!
  • Reconciliation observability - The reconciliation process of Crossplane objects is now easier to get insight into its progress as status conditions will now have the observedGeneration, i.e. the version of the resource, for which they were reconciled. You no longer need to wonder if Crossplane has seen and reconciled your latest changes.

🚨 Warnings and breaking changes

Backwards Compatibility with v1

The Crossplane maintainers have taken thoughtful consideration to make major improvements and changes in v2 while maintaining backwards compatibility for the vast majority of v1 workloads. We expect most users to be able to upgrade to v2 without any changes to their control plane. However, there is a set of 4 breaking changes that we have made, mostly to long deprecated features and features that have remained stuck in alpha for a long time.

If you are not using any of these 4 features, you can upgrade to v2 without any issues and your existing workload should continue operating as usual.

The following features have been removed:

  • Native patch and transform within composition (mode: Resources)
    • You can migrate your compositions to use function pipelines with the crossplane beta convert pipeline-composition command available in the v1 crossplane CLI. See the Crossplane docs for details.
  • ControllerConfig
    • These have been replaced by DeploymentRuntimeConfig. You can migrate your existing ControllerConfig to DeploymentRuntimeConfig with the crossplane beta convert deployment-runtime command available in the v1 crossplane CLI. See the Crossplane docs for details.
  • External secret store support
    • Crossplane no longer directly supports writing connection details to external destinations outside of the control plane. We recommend using an alternative such as External Secrets Operator. Note that It is still fully supported to write connection details to a Secret within the control plane using spec.writeConnectionSecretToRef available on managed resources.
  • Default registry
    • When specifying a package for Crossplane to install, you must now fully qualify the package with the registry that hosts it, both directly via spec.package and indirectly as dependencies. For example, it is no longer valid to simply use crossplane-contrib/provider-family-azure:v1.13.0 which does not specify the host registry. You must supply the fully qualified package, including the host registry, like xpkg.crossplane.io/crossplane-contrib/provider-family-azure:v1.13.0. If a registry is not specified, then an error will be returned for the package.

Go module path is now github.com/crossplane/crossplane/v2

As this release is a major version bump that has breaking changes, the rules for Go modules required the Crossplane module path to be updated to include the v2 version suffix.

If you import crossplane and crossplane-runtime into your go.mod, when you update to v2+ you will also need to update the module path. All import statements in your code base need to be updated to also include this v2 module path, as it is effectively a module change.

See this commit as an example of this type of update: d6c489c

The module paths for v2 versions of crossplane and crossplane-runtime are:

  • github.com/crossplane/crossplane/v2
  • github.com/crossplane/crossplane-runtime/v2

Metrics name changes

The Prometheus metrics that Crossplane exposes for the controller engine and function response caches have been updated with the addition of Operations that expands the functionality of function pipelines. The names of these metrics have been updated as follows:

  • crossplane_composition_controllers_* --> crossplane_engine_controllers_*
  • crossplane_composition_watches_* --> crossplane_engine_watches_*
  • crossplane_composition_run_function_* --> crossplane_function_run_function_*

login/logout removed from Crossplane CLI

The crossplane xpkg login and crossplane xpkg logout commands have been removed from the Crossplane CLI. To login to a registry before pushing a package, consider using docker login locally, or the docker/login-action from CI.

An example of this pattern can be seen in many Community Extension Projects, for example function-auto-ready.

deletionPolicy removed for namespaced managed resources

Namespaced managed resources, that are net new in v2, no longer have the deletionPolicy field. This behavior can be recreated using a ManagementPolicy without the "Delete" option. For example:

managementPolicies: ["Create", "Observe", "Update"]

Existing cluster scoped managed resources are not affected.

🏅 Release MVP

Since v2.0 is such a massive release with many months of effort across many contributors in the community, it was impossible to pick a single release MVP this time - so we're going big with 3 MVPs! 📈

  • @​joebowbeer did lots of bleeding edge testing and finding issues in the daily builds of Crossplane v2 in the main branch. He was often the quickest to spot any new regressions creeping in that e2e tests did not catch, so he contributed significantly to the overall quality of the release.
  • @​jcogilvie is driving major improvements in the Crossplane CLI that will enable broader extensions to its functionality from the community. He's also driving SIG-cli to organize folks interested in more collaboration in this area.
  • @​gotwarlost generously donated function-hcl as a Community Extension Project, which provides function users with a familiar HCL syntax and functionality.

Thank you very much release MVPs! 🙇‍♂️

What's Changed

New Contributors

Full Changelog: https://github.com/crossplane/crossplane/compare/v1.20.1...v2.0.0

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻️ Rebasing: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this MR and you won't be reminded about this update again.

  • If you want to rebase/retry this MR, check this box

This MR has been generated by Renovate Bot Sylva instance.

CI configuration couldn't be handle by MR description. A dedicated comment has been posted to control it.

If no checkbox is checked, a default pipeline will be enabled (capm3, or capo if capo label is set)

Edited by Sylva Renovate bot

Merge request reports