What problem are you facing?
The difficulty of building compositions is a hurdle to Crossplane adoption for many users. The original patch-and-transform composition system was easy to get started with but became unwieldy for large compositions. The modern function pipeline style of composition provides more power and readability by allowing for the use of general purpose programming languages; however, users either have to build and manage composition functions separately from their compositions, or use "generic functions" and write composition code inline in their compositions, neither of which is a simple experience.
How could Crossplane help solve your problem?
Upbound has built a developer experience centered on the idea of control plane "projects": an on-disk directory layout that includes both Crossplane resources (XRDs and compositions in YAML files) and functions. Projects are built into a set of Crossplane packages, with dependencies between them, by the Upbound CLI. There is also support for running a local control plane for testing, and for writing automated tests (both render-based "composition tests" and uptest-based e2e tests).
Full details can be found in the Upbound documentation: https://docs.upbound.io/manuals/cli/howtos/project/
Upbound would like to contribute this tooling to the Crossplane project, either as part of the existing crossplane/crank CLI, or as a new set of tools. Specifically, we propose porting the following functionality from the proprietary up CLI to an open source Crossplane tool:
- The "project" concept and API definitions.
- Commands for managing projects and their dependencies.
- Commands for authoring XRDs and compositions within a project.
- Commands to "compile" projects, including their embedded functions, into Crossplane packages, and pushing those packages to a registry.
- The ability to easily run a control plane locally and install a project into it for testing.
- Commands for testing projects.
- Tooling for generating and distributing "schemas" (bindings for various programming langauges) for Crossplane providers and configurations.
This issue is intended as a starting point for discussion. A design doc describing the details of where this functionality will land in Crossplane and how it works will follow.
What problem are you facing?
The difficulty of building compositions is a hurdle to Crossplane adoption for many users. The original patch-and-transform composition system was easy to get started with but became unwieldy for large compositions. The modern function pipeline style of composition provides more power and readability by allowing for the use of general purpose programming languages; however, users either have to build and manage composition functions separately from their compositions, or use "generic functions" and write composition code inline in their compositions, neither of which is a simple experience.
How could Crossplane help solve your problem?
Upbound has built a developer experience centered on the idea of control plane "projects": an on-disk directory layout that includes both Crossplane resources (XRDs and compositions in YAML files) and functions. Projects are built into a set of Crossplane packages, with dependencies between them, by the Upbound CLI. There is also support for running a local control plane for testing, and for writing automated tests (both render-based "composition tests" and uptest-based e2e tests).
Full details can be found in the Upbound documentation: https://docs.upbound.io/manuals/cli/howtos/project/
Upbound would like to contribute this tooling to the Crossplane project, either as part of the existing crossplane/crank CLI, or as a new set of tools. Specifically, we propose porting the following functionality from the proprietary
upCLI to an open source Crossplane tool:This issue is intended as a starting point for discussion. A design doc describing the details of where this functionality will land in Crossplane and how it works will follow.