search

cloudfoundry / diego-notes

Diego Notes
Apache License 2.0
23 stars 7 forks source link

The Road to Composing BOSH Releases #9

Closed onsi closed 8 years ago

onsi commented 9 years ago

Diego, Runtime, BOSH and PCF had a joint meeting where we discussed what composing BOSH release might look like.

We have a tentative proposal here: https://github.com/pivotal-cf-experimental/diego-dev-notes/blob/master/proposals/bosh-deployments.md

This includes concrete baby steps for Diego. There is no hard timeline for implementing this yet but this could be a forum for discussion.

Amit-PivotalLabs commented 9 years ago

I'm not sure exactly what the best way to slice and dice deployment ownership will be. Should there be one cf-deployment repo, or many? Should this/these repo(s) support dev, CI, acceptance, OSS, PWS, and/or PCF use cases? AWS, vSphere, vCloud, OpenStack, GCE, etc?

What about versioning? The release(s) that a deployment points to will change over time, will this history be tracked and versioned in some way?

A deployment may point to particular versions of particular releases (via URLs to tarballs, for instance), and might offer template(s) for generating manifests that compose those releases. How do we keep the templates in sync with the job specs in the referenced releases? This is currently done manually, but I can imagine BOSH tooling evolving to help automate this. (boshhub already helps a bit with this).

At some point we should also start to think about tooling for generating manifests, beyond spiff. Particular problems to keep in mind is dealing with shared, often secret, environment-specific data, and sharing data between different deployment manifests deployed to the same environment. In particular, we should think about generalizing this to work in terms beyond just cf-release (and diego-release), we'd ideally have something that works just as well for the various service releases other teams are working on, for instance. Focusing on an overly narrow scope like cf-release can easily just lead to the current state of spiff + deployments-aws/deployments-runtime.

emalm commented 8 years ago

This is mostly already done, or planned by the MEGA teams. Closing.