crossplane-provider-cloudfoundry
is a Crossplane provider for Cloud Foundry. The provider that is built from the source code in this repository can be installed into a Crossplane control plane and adds the following new functionality:
- Custom Resource Definitions (CRDs) that model Cloud Foundry resources (e.g. Organization, Space, Services, Applications, etc.)
- Custom Controllers to provision these resources in a Cloud Foundry deployment based on the users desired state captured in CRDs they create
We have a lot of exciting new features and improvements in our backlogs for you to expect and even contribute yourself! We will publish a detailed roadmap soon.
To install this provider in a kubernetes cluster running crossplane, you can use the provider custom resource, replacing the <version>
placeholder with the current version of this provider (e.g. v0.3.0):
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-cloudfoundry
spec:
package: ghcr.io/sap/crossplane-provider-cloudfoundry/crossplane/provider-cloudfoundry:<VERSION>
Crossplane will take care to create a deployment for this provider. Once it becomes healthy, you can configure your provider using proper credentials and start orchestrating π.
The provider comes with some tooling to ease a local setup for development. As initial setup you can follow these steps:
- Clone the repository
- Run
make submodules
to initialize the "build" submodule provided by crossplane - Run
make dev-debug
to create a kind cluster and install the CRDs
Those steps will leave you with a local cluster and your KUBECONFIG being configured to connect to it via e.g. kubectl or k9s. You can already apply manifests to that cluster at this point.
To run the controller locally, you can use the following command:
make run
This will compile your controller as executable and run it locally (outside of your cluster). It will connect to your cluster using your KUBECONFIG configuration and start watching for resources.
For deleting the cluster again, run
make dev-clean
The provider comes with a set of end-to-end tests that can be run locally. To run them, you can use the following command:
make test-acceptance
This will spin up a specific kind cluster which runs the provider as docker container in it. The e2e tests will run kubectl commands against that cluster to test the provider's functionality.
Please note that when running multiple times you might want to delete the kind cluster again to avoid conflicts:
kind delete cluster <cluster-name>
In order for the tests to perform successfully some configuration need to be present as environment variables:
CF_CREDENTIALS
User credentials for a user that is Cloud Foundry Administrator in the configured environment, structure:
{
"email": "email",
"username": "PuserId",
"password": "mypass"
}
CF_ENVIRONMENT
Contains the CF server URL, for example:
https://api.cf.eu12.hana.ondemand.com
If you have a question always feel free to reach out on our official crossplane slack channel:
π #provider-sap-cloudfoundry.
This project is open to feature requests/suggestions, bug reports etc. via GitHub issues. Contribution and feedback are encouraged and always welcome.
If you are interested in contributing, please check out our CONTRIBUTING.md guide and DEVELOPER.md guide.
If you find any bug that may be a security problem, please follow our instructions at in our security policy on how to report it. Please do not create GitHub issues for security-related doubts or problems.
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone. By participating in this project, you agree to abide by its Code of Conduct at all times.
Copyright 2024 SAP SE or an SAP affiliate company and crossplane-provider-btp contributors. Please see our LICENSE for copyright and license information. Detailed information including third-party components and their licensing/copyright information is available via the REUSE tool.