This sketch proposes that crossplane.yaml replace the contemporary .registry/app.yaml. The contemporary app.yaml uses a packageType to distinguish between a packaged provider and a packaged stack (note that this sketch essentially uses 'configuration' in place of 'stack'). This sketch does not currently include an example of a Provider, which would presumably look something like:
apiVersion: pkg.crossplane.io/v1alpha1
kind: Provider
metadata:
name: provider-aws
annotations:
company: Upbound
maintainer: Kasey Kirkham <kasey@upbound.io>
keywords: cloud-native, kubernetes, aws
source: github.com/negz/aac
license: Apache-2.0
description: |
The AWS provider adds support for managing AWS resources to Crossplane.
provider: aws
spec:
controllerImage: crossplane/provider-gcp:v0.11.0
# Optional. Matching paths will be ignored by `crossplane package build`.
ignore:
- path: examples/
We need somewhere to demonstrate this, but I'm not sure this repo is the right place given that we're hoping to sketch out the experience for platform builders, who would presumably seldom write their own providers.
This sketch proposes that
crossplane.yamlreplace the contemporary.registry/app.yaml. The contemporaryapp.yamluses apackageTypeto distinguish between a packaged provider and a packaged stack (note that this sketch essentially uses 'configuration' in place of 'stack'). This sketch does not currently include an example of a Provider, which would presumably look something like:We need somewhere to demonstrate this, but I'm not sure this repo is the right place given that we're hoping to sketch out the experience for platform builders, who would presumably seldom write their own providers.