Document how to change provider registries
This PR adds a guide for safely changing providers between compatible packages in different OCI registries (e.g., upbound → crossplane-contrib).
The guide focuses on the manual coordination approach needed when providers have family dependencies that create ownership conflicts. Includes step-by-step process, troubleshooting, and rollback procedures.
Also adds cross-reference from the upgrade-to-v2 guide for users switching registries during their v2 upgrade.
Deploy Preview for crossplane ready!
| Name | Link |
|---|---|
| Latest commit | ed31ce59ef41b2ef13066650609c9484e7c2e889 |
| Latest deploy log | https://app.netlify.com/projects/crossplane/deploys/68b23e82074c6f0008414aef |
| Deploy Preview | https://deploy-preview-984--crossplane.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
Lighthouse |
1 paths audited Performance: 94 (🔴 down 1 from production) Accessibility: 90 (🔴 down 2 from production) Best Practices: 92 (no change from production) SEO: 100 (no change from production) PWA: 70 (no change from production) View the detailed breakdown and full score reports |
To edit notification comments on pull requests, go to your Netlify project configuration.
I realized there's a simpler approach:
- Update dependencies (i.e. family provider) in place by changing their OCI ref
- Update dependents
In simple tests this seems to work fine.
In simple tests this seems to work fine.
I've tested it and it works, but it feels like it's dependent on a shortcoming in the package manager.
I'd expect that the dependent packages would attempt to self-heal by reinstalling their dependency once it's gone. So:
- I edit the
upbound-provider-family-gcpprovider to switch it to usexpkg.crossplane.io/crossplane-contrib/provider-family-gcp - Crossplane notices one or more providers depend on the
xpkg.upbound.io/upbound/provider-family-gcppackage - The
xpkg.upbound.io/upbound/provider-family-gcppackage no longer appears in the Lock, so Crossplane re-solves and reinstalls it
Step 3 doesn't happen though, because the package manager only solves and installs dependencies at package install time. If the dependencies are removed after the package is installed, the packages just start saying they're unhealthy and missing deps.
So I'm hesitant to document this simpler approach, because it won't work if we improve the package manager's self-healing of dependencies.
