DCD, Spinfile, Terraform, etc

dcd-plugins.md

name: clouddriver
definition:
  foo:
    plugin: appConfig
    properties:
      pagerDuty: [email protected]
      # ...
  chaos:
    plugin: chaosMonkey
    properties:
      enabled: true
  pipelines:
    plugin: pipelines
    properties:
    - one
    - two

# simplified to...
---

name: clouddriver

appConfig:
  pagerDuty: [email protected]

chaosMonkey:
  enabled: true

pipelines:
- one
- two

Implement as handlers

class DescriptionRoot : HashMap<String, PluginConfig> {
  val name: String
}

interface PluginProperties : Iterate
class Plugin<out T>(val id: String, val properties: T) where T: PluginProperties

interface PluginHandler {
  fun validate(input: PluginProperties): List<Error>
}

class Processor {

  // sorted by priority
  val handlers: List<PluginHandler>

  fun parse(val root: DescriptionRoot) {
    val errors = root.flatMap { k, v ->
      handlers[k].validate(v)
    }
    assert errors.isEmpty

    handlers.forEach { h -> 
      root.filter(h.supports(k)).forEach { k, v ->
        h.handle(v)
      }
    }
  }
}

Spinfile.yml

# Required. Spinfiles have their own independent  schema than what DCD has.
schema: "1"
# Defines the root application name. This can be undefined and will inherit the 
# name the repository e.g. dir(__file__)
name: clouddriver
# Tags allow us to auto-generate Spinnaker Projects of any application that has 
# the same tag. They have no other purpose but for discovery and organizational 
# purposes.
tags:
- spinnaker

# Spinnaker application configurations. If a section is defined, it will become
# locked within the UI, as the Spinfile will manage its state. Example, if only
# chaosMonkey were defined here, the UI would lock it, but attributes could
# still be managed via the UI.
config:
  attributes:
    owner: [email protected]
    pagerDuty: Spinnaker
    repoType: github
    repoProject: spinnaker
    repoName: clouddriver
    description: cloud read and write operations
    accounts:
    - my-prod-account
    - my-test-account
    cloudProvider:
    - aws
    # ...
  notifications:
  - type: slack
    channel: "#spinnaker"
    when:
    - event: pipeline.complete
      message: Optional
  features:
    ci: true
    pipelines: true
    # ...
  links:
  - title: Logs
    links:
    - title: catalina.out
      path: :1234/logs?view=tomcat/catalina.out
  chaosMonkey:
    enabled: true
    # ...
  trafficGuards:
  - account: my-prod-account
    region: "*"

# Metadata is strictly data that can be used to help inform Spinnaker
# of how to intelligently provision the application. 
metadata:
  workload: network # enum cpu|mem|network|etc ... could allow us to
                    # decide what instance type to provision a server on.
  package: docker|deb
pipelines:
# Simple 1-1 mapping to TemplateConfiguration. It feels awkward to have
# pipelines.pipeline.name; so may be worth a diversion in APIs from what
# orca is internally expecting here.
- pipeline:
    name: Bake & Deploy to Test
    template:
      source: spinnaker://my-managed-pipeline-template
    notifications: []
    # ... 
  stages: {} # config-time stage definitions
  modules: {} # config-time module definitions

# Additional, non-pipeline things that Spinnaker typically manages for
# people.
infrastructure:
  loadBalancers: []
  securityGroups: []
  # ...

# etc...
# Additional unknown keys are not syntax errors, but offered as potential
# extension points. It's totally reasonable that we would want to support 
# a root-level "netflix", "google" or "fooCompany" configuration namespace.
netflix:
  tier: 0

spinnaker.tf

provider "spinnaker" {
  host = "https://spinnaker.net"
  x509 {
    cert_file = ""
    key_file = ""
  }
}

resource "spinnaker_app" "clouddriver" {
  name = "clouddriver"
  tags = ["spinnaker"]
  
  attributes {
    owner = "[email protected]"
    # Issue: Terraform doesn't support extensions to resources. We'd need to
    # publish a -nflx provider that extends OSS. This is a supported pattern
    # in TF.
    pagerDuty = "Spinnaker"
    description = cloud read and write operations
  }
  
  notification {
    type = "slack"
    channel = "#spinnaker"
    when {
      event = "pipeline.complete"
      message = optional
    }
    when {
      event = "pipeline.failed"
      message = optional
    }
  }
  
  features {
    pipelines = true
  }
  # ...
}

resource "spinnaker_templated_pipeline" "bake_and_deploy" {
  application = "${spinnaker_application.clouddriver.name}"
  
  name = "Bake & Deploy to Test"
  template {
    source = "spinnaker://my-managed-pipeline-template"
  }
  stages {
    stage {
      
    }
    # ...
  }
  modules {
    # ...
  }
}

# Alternative to making `spinnaker_application` resource huge...
resource "spinnaker_application_notification" "slack_oncomplete" {
  application = "${spinnaker_application.clouddriver.name}"
  
  type = "slack"
  channel = "#spinnaker"
  when {
    event = "pipeline.complete"
    message = optional
  }
  when {
    event = "pipeline.failed"
    message = optional
  }
}