Addons

[dpb587]

I was thinking more about addons...

It seems like addons will often be maintained by independent teams (i.e. logging/monitoring, antivirus on-site). It seems weird to have a single file where everyone will be touching things. Rather than a single file of many addons that many people have to work in, perhaps they could be individually maintained. It seems like it'd be much more readable, concise, and easier to maintain.

$ bosh update addon /dev/stdin << EOF
name: ipsec
releases:
  - { name: ipsec, version: 27 }
templates:
  - { name: ipsec_agent, release: ipspec }
  - { name: ipsec_openswan, release: ipsec }
properties:
  ipsec:
    shared_key: UYasbvh872f
EOF

Internally, they could be versioned such that deployments point to which addons they're currently using. This seems like it'd be easier than deployments pointing to a single entry of all addons which may not actually be relevant to the deployment (like cloud-config)...

$ psql 'select * from deployments_addons;'
{ "deployment": "always_updated",  "addon_version": "3", "addon_version.addon.name": "ipsec" }
{ "deployment": "outdated_deploy", "addon_version": "1", "addon_version.addon.name": "ipsec" }

$ bosh addons
[ { "name": "ipsec",
    "versions": [ "1", "2", "3" ] },
  { "name": "logsearch-shipper",
    "versions": [ "4", "5", "6" ] } ]

$ bosh deployment addons "outdated_deploy"
[ { "name": "ipsec",
    "version": "1",
    "latest_version": "3" } ]

Rather than versions, it might be worthwhile to consider using timestamps. Versions might imply correlations to the addon's .releases[].version and cause confusion. For example, the ipsec addon is using release version 27, but the BOSH director might consider the addon config version to be 3 causing users to become worried it's out of date.

On the releases[].version discussion of latest, I'd personally rather see it be explicit where I as the addon operator need to state the release version I expect deployments to use.

Personally, I'd like to see addons not be installed by default, but rather let deployment operators elect which addons/features are going to be transforming their deployments. Maybe that's where tags.excluded_on is useful? Seems odd to make addon operators responsible for knowing which deployments are going to be deployed if those addons are more service-oriented. As mentioned in the file, some addons might need network security group customizations and on some CPIs that'll be affecting how I plan those out and I need to be aware of that. Also, some addons may just be for convenience than having to retype a bunch of properties or global templates but aren't necessarily appropriate for everything I deploy. For that, I think it'd be nice to have a deployment manifest addons property which allows me to elect (or possibly ignore) addons...

name: my_deployment
director_uuid: 423a77e8-1aca-45c6-a5d0-d70cf6417ce6
addons:
  - ramdisk             # use the ramdisk addon which might not be installed by default
  - !logsearch-shipper  # do not use the addon which might be installed by default
  - ipsec?              # if there's an ipsec addon, use it; otherwise ignore
templates:
  ...snip...

Other crazy idea... what if deployments could expose an addon since it seems like some addons might be closely bound to a deployment's services. For example, a deployment manifest managing a logsearch cluster might expose an addon for shipper which will ship logs into the deployment. Other deployments could opt into that by referencing the logsearch.shipper addon it exposed. Haven't really thought that one through though.

Anyways... just some ideas which seemed easier to consider with examples.