StackDefinition

stackdefintion.yaml

# This is the canonical stack definition. I believe this replaces our current `Stack` CRD.
# `StackInstall` and `ClusterStackInstall` remain and is where to fetch the `StackDefinition` itself.
# `StackDefinition` can be created directly by users without the need for a `StackIntall` or `ClusterStackInstall`?
apiVersion: stacks.crossplane.io/v1alpha1
kind: StackDefinition
metadata:
 name: wordpress-stack
spec:
  # this is metadata about the stack.
  # NOTE: this part is similar to https://github.com/kubernetes-sigs/application#application-objects
  # TODO: these could also go in annotations. Maybe common metadata goes in the spec, and
  # tool dependent metadata goes in annotations?
  descriptor:
    title: Wordpress Stack
    overviewShort: "One sentence in plain text about how Wordpress Works"
    overview: |
      Plain text about how Wordpress is a really cool database.
    readme: |
      ## README
      * Uses markdown
    category: Applications
    version: 0.1.0
    icons:
    - base64data: iVBORw0KGgoAAAANSUhEUgAAAOEAAADZCAYAAADWmle6AAAACXBIWXMA
      mediatype: image/png
    maintainers:
    - name: Rick Kane
      email: [email protected]
    owners:
    - name: Chandler
      email: [email protected]
    keywords:
    - "databases"
    website: "https://redislabs.com/"
  # These are references to CRDs for the resources supported/owned by this stack.
  # TODO: for template stacks it would be a simplification to just support on CRD. I wonder
  # if that leads us down a path of having two kinds of StackDefinitions -- ControllerStackDefinition
  # and TemplateStackDefinition? For now let's assume that there could be multiple CRDs for
  # controller-based stack defs, and just one for template based stack defs.
  # TODO: if TemplateStackDefinition can only define one CRD, then you can consider TemplateStackDefinition as a subtype
  # of CRD and there would not need to be a separate CRD defined for it.
  customresourcedefinitions:
  - kind: WordpressCluster
   apiVersion: cluster.wordpress.com/v1alpha1
  # This is an array of CRDs that are used by this Stack Definition.
  # These can also be used to drive dependency resolution between stacks.
  # TODO: this should include all GroupKinds this stack uses even if they are not CRDs?
  dependsOn: []
  - crd: '*.crossplane.io'
  # The selector is used to match resources that belong to the stack resource.
  # All of the applications resources should have labels such that they match this selector.
  # Users should use the stack.crossplane.io/name label on all components of the stack resource
  # and set the selector to match this label. 
  # For instance, {"matchLabels": [{"stack.crossplane.io/name": "foo"}]} should be used
  # as the selector for an Stack resource named "foo", and each component should contain a label that matches.
  selector:
    matchLabels:
      stacks.crossplane.io/name: "myapp"
  # Flag controlling if the matched resources need to be adopted by stack instance object.
  # When adopting, an OwnerRef to the stack resource object is inserted into the matched objects
  # .metadata.[]OwnerRefs. The injected OwnerRef has blockOwnerDeletion set to True and controller set to False.
  addOwnerRef: true
  # the scope of this stack
  # NOTE: I assume all owned CRDs must be cluster scoped too, right?
  permissionScope: Cluster 
  # A stack must have an implementation. Currently there will be three different kinds of implementations: controller
  # helm and kustomize. We can add more later. Only one of these must be specified (not sure if this can be specified 
  # CRD validation rules).

  # A stack with a controller implementation is just a controller-runtime controller running as a deployment.
  controller:
    deployment:
        name: wordpress-controller
        spec:
        replicas: 1
        selector:
            matchLabels:
            core.crossplane.io/name: "redis"
        template:
            metadata:
            name: redis-controller
            labels:
                core.crossplane.io/name: "redis"
            spec:
            serviceAccountName: redis-controller
            containers:
            - name: redis-controller
                image: redis/redis-crossplane-controller:2.0.9
                imagePullPolicy: Always
                env:
  # A kustomize implementation of the stack
  kustomize:
    # where to fetch the template/config from (git, OCI, URL) and others maybe that are supported by https://github.com/hashicorp/go-getter
    # one of these must support fetching locally from the stack OCI package itself?
    fetch:
    - git:
      url: https://github.com/bassam/kustomize-sample
      ref: origin/master
    # a set of vars and patches that are setup when invoking kustomize
    # these can draw upon the `spec` values of the supported CRs of this stack def.
    # similar to https://github.com/crossplaneio/crossplane/blob/c6d01ceea778b76d212b12961f4d5368f1187d4a/design/one-pager-resource-packs.md#referencing
    vars:
    - name: REGION
      fieldpath: spec.region
    # patches and possibly overlays can be supported too.
    patches:

  # A helm implementation of the stack
  helm2:
    fetch:
    - git:
      url: https://github.com/bitnami/charts
      ref: origin/master
      subPath: bitnami/wordpress
    # how to generate a values file to use with the chart. This could be a whole values file with mustache templates.
    # or translations as https://github.com/crossplaneio/crossplane/blob/ae12c2a54e6b00b9cbe9bfd61a1e7408e45e757f/design/design-doc-resource-claim-definition.md#proposal
    values:

  # future implementations
  hcl:
  
  # TODO: support for inline templates?

TODO: versioning. Schema vs. template vs. rendering engine.