Configuration

Config Proposal

See also ZooKeeper Config Specification

Problems with current format

• distinction between app and app-group is fuzzy
• hard dependency on non-OSS stuff to resolve configuration
• sequences and constraints are confusing; sequence: { envtype: [ [ appname ] ] } vs. constraint: { appname: { envtype: N } }
• sequences are a type of constraint, also confusing
• no distinction between deployments, they're muddled together

app-groups:
  <group-name>:
    - <role>
    - <role>

sequences:
  <environment-type>:
    - [ <app-name>, <app-name> ]

constraints:
  <app-name>:
    <environment-type>: <N>

Proposed configuration format

<deployment-name>:
  apps:
    <application-name>:
        <source-name>:
          - <input>
          - <input>
  envs:
    <environment-type>:
      <source-name>:
        - <environment-name>:
           - <input>
           - <input>
        - <environment-name>:
           - <input>
  constraints:
    <environment-type>:
      concurrency:
        - <application-name>: <N>
        - <application-name>: <N>
      sequence:
        - [ <application-name>, <application-name>, ... ]
        - [ <application-name>, <application-name>, ... ]

As a real example

bob:
  apps:
    frontend:
      inline:
        - foo[1-100].east.bob.com
        - foo[1-100].west.bob.com
    backend:
      inline:
        - bar[1-10].east.bob.com
        - bar[1-10].west.bob.com

  envs:
    coast:
      inline:
        - east:
          - foo[1-100].east.bob.com
          - bar[1-10].east.bob.com
        - west:
          - foo[1-100].west.bob.com
          - bar[1-10].west.bob.com

  constraints:
    coast:
      concurrency:
        - frontend: 25%
        - backend: 1
      sequence:
        - [ backend, frontend ]

Pros

• clearly segregates by deployment
• allows for different source plugins (inline vs roles vs chef vs whatever)

Cons

• very nested
• could get complicated with large inline deployments
• repetition of data between apps and envs