Add support for overriding stemcell and bosh versions

[orange-cloudfoundry]

Add support for overriding stemcell and bosh versions

[poblin-orange]

as a workaround, for bosh-releases dependency, you could define a dedicated alias in deployment-dependency, which can define a specific version in xxx-depls-versions

deployment-dependencies.yml

---
deployment:
  ntp:
    stemcells:
      bosh-openstack-kvm-ubuntu-trusty-go_agent:
    releases:
      ntpv10_boshrelease:
        base_location: https://bosh.io/d/github.com/
        repository: cloudfoundry-community/ntp-release

xxx-depls-versions.yml

ntp_boshrelease-version: 4
ntpv10_boshrelease-version: 10

[gberche-orange]

Met the issue with the snyk deployment in master-depls which is requiring a pinned version of the xenial stemcell (version 60 w.r.t. latest which is 81)

We considered a workaround using ops file to modify the manifest. However, the concourse resource used by COA first interpolates manifest using the bosh director api call, and then modify the resulting manifest.

See https://github.com/cloudfoundry/bosh-deployment-resource#parameters-1

stemcells: Optional. An array of globs that should point to where the stemcells used in the deployment can be found. Stemcell entries in the manifest with version 'latest' will be updated to the actual provided stemcell versions.

See
https://github.com/cloudfoundry/bosh-deployment-resource/blob/master/out/out_command.go#L83-L86 and
https://github.com/cloudfoundry/bosh-deployment-resource/blob/9c70a78277a6681e728b12de265fe9400382eb0a/bosh/deployment_manifest.go#L42

We then tried to declare additional stemcells in the manifest file which do not specify the latest version and should be ignored by the concourse resource

stemcells:
- alias: default
  os: ubuntu-trusty
  version: latest
- alias: xenial
  os: ubuntu-xenial
  version: 60

The xenial stemcell would be uploaded using the deploy.sh script using bosh upload-stemcell specifying sha1

[gberche-orange]

Moving back to be reviewed following version conflicts experienced in COAB:

• among dedicated service instances that may require different version of a given bosh release (e.g. cf-mysql-release)
• among bosh releases shared by multiple bosh releases, with incompatible versions (e.g. cf-routing-release or haproxy-release