Re: Cloud Foundry DEA to Diego switch - when?
Our team is also planning the timeline of replacing dea with diego. Would you please let me know the approximated estimation on when the final iteration would come? Will it in 2016 or 1017?
From: Amit Gupta [mailto:agupta(a)pivotal.io]
Sent: 2015年10月22日 2:59
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: Cloud Foundry DEA to Diego switch - when?
Thanks for your question. Let's first clarify the distinction between what you deploy -- bosh releases (versioned packages of source code and binaries) -- and how you deploy things -- bosh deployment (a manifest of which releases to use, what code/binaries from those releases to place on nodes in your deployment cluster, property/credential configuration, networking and compute resources, etc.).
diego-release may not change, although it may be split into smaller releases, e.g. the cc-bridge part consisting of the components which talk to CC, and the diego runtime part consisting of components responsible for scheduling, running, and health-monitoring containerized workloads.
cf-release will undergo heavy changes. We are currently breaking it apart entirely, into separate releases: consul, etcd, logging-and-metrics, identity, routing, API, nats, postgres, and existing runtime backend (DEA, Warden, HM9k).
In addition to breaking up cf-release, we are working on cf-deployment, this will give you the same ability to deploy the Cloud Foundry PaaS as you know it today, but composed of multiple releases rather than the monolithic cf-release. We will ensure that cf-deployment has versioning and tooling to make it easy to deploy everything at versions that are known to work together.
For the first major iteration of cf-deployment, it will deploy all the existing components of cf-release, but coming from separate releases. You can still deploy diego separately (configured to talk to the CC) as you do today.
The second major iteration will be to leverage new BOSH features, such as links, AZs, cloud config, and global networking to simplify the manifest generation for cf-deployment. Again, you will still be able to deploy diego separately alongside your cf deployment.
The third iteration is to fold the diego-release deployment strategies into cf-deployment itself, so you'll have a single manifest deploying DEAs and Diego side-by-side.
The final iteration will be to remove the DEAs from cf-deployment and stop supporting the release that contains them.
As to your question of defaults, there are several definitions of "default". You can set Diego to be the default backend today. You have to opt in to this, but then anyone using the platform you deployed will have their apps run on Diego by default. Pivotal Web Services, for example, now defaults to Diego as the backend. At some point, Diego will be the true default backend, and you will have to opt-out of it (either at the CC configuration level, or at the individual app level). Finally, at a later point in time, DEAs will no longer be supported and Diego will be the only backend option.
We are actively working on a timeline for all these things. You can see the Diego team's public tracker has a release marker for when Diego will be capable of replacing the DEAs. After reaching that release marker, there will be some time given for the rest of the community to switch over before declaring end-of-life for the DEAs.
Amit, OSS Release Integration PM
On Wed, Oct 21, 2015 at 10:31 AM, R M <rishi.investigate(a)gmail.com<mailto:rishi.investigate(a)gmail.com>> wrote:
I am trying to understand when will Diego become default runtime of Cloud Foundry. Latest cf-release is still using DEA and if my understanding is correct, at some stage, a new cf-release version will come out with Diego and perhaps change to v3. Do we have any ideas on when/if this will happen? Is it safe to assume that diego-release on github will slowly transition to cf-release?