Skip to content

Instantly share code, notes, and snippets.

@bassam

bassam/stackdefintion.yaml

Last active January 7, 2020 00:04
Show Gist options
  • Save bassam/4940bc6becf02690d708baed1a765f52 to your computer and use it in GitHub Desktop.
Save bassam/4940bc6becf02690d708baed1a765f52 to your computer and use it in GitHub Desktop.
Download ZIP
StackDefinition
Raw
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?
@bassam
Copy link
Author

bassam commented Jan 6, 2020 •
edited
Loading

Here's an alternative with just a Template StackDefinition where CRD is on 1:1 basis with the StackDefinition:

# In this example, the StackDefinition *is* a CRD and adds a template implementation
apiVersion: stacks.crossplane.io/v1alpha1
kind: StackDefinition
metadata:
 name: wordpress-stack-definition
spec:
  ## this is the CRD spec unchanged
  group: cluster.wordpress.com
  names:
    kind: WordpressCluster
    listKind: WordpressClusterList
    plural: wordpressclusters
    singular: wordpresscluster
  scope: Namespaced
  version: v1alpha1
  versions:
  - name: v1alpha1
    served: true
    storage: true
  subresources:
    status: {}  # this is metadata about the stack.
  additionalPrinterColumns:
  validation:
    openAPIV3Schema:

  # 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
    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/"

  # This is an array of GroupKinds that are used by the stack.
  # These can also be used to drive dependency resolution between stacks.
  componentKinds: []
  - crd: '*.crossplane.io'

  # A stack must have an implementation. Currently there will be two different kinds of implementations: helm and kustomize.

  # 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:

If we go with this approach, we would still need the current Stack object and maybe rename it to StackController which is really what it embodies -- a controller that is able to handle one ore more CRDs (loosely stacks).

@bassam
Copy link
Author

bassam commented Jan 7, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment