I'd encourage anyone wanting to switch to Diego to track the following
release marker in our project tracker:
https://www.pivotaltracker.com/story/show/76376202. When this marker is
delivered, it means the core teams have confidence that Diego can replace
the DEAs. Note that while the tracker shows the date for this release to
occur this week, there are actually several unpointed placeholder stories
above the line that will expand. Those stories will be broken down and
pointed soon, so it will be possible to get a more realistic estimate soon.

After it's deemed that Diego can replace the DEAs, there will be some time
before the DEAs will be end-of-life'd, but I would not recommend waiting
that long.

On Wed, Oct 21, 2015 at 11:07 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:

Hi, Amit



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?



Thanks,

Maggie



*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?



Hi Rishi,



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[1],
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[2], 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[3]. 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[4] 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.



[1] https://github.com/cloudfoundry/cf-deployment

[2] https://github.com/cloudfoundry/bosh-notes/

[3]
https://github.com/cloudfoundry/cf-release/blob/v222/jobs/cloud_controller_ng/spec#L396-L398

[4] https://www.pivotaltracker.com/story/show/76376202



Thanks,

Amit, OSS Release Integration PM



On Wed, Oct 21, 2015 at 10:31 AM, R M <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?

Thanks.

Hi, Amit

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?

Thanks,
Maggie

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?

Hi Rishi,

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[1], 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[2], 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[3]. 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[4] 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.

[1] https://github.com/cloudfoundry/cf-deployment
[2] https://github.com/cloudfoundry/bosh-notes/
[3] https://github.com/cloudfoundry/cf-release/blob/v222/jobs/cloud_controller_ng/spec#L396-L398
[4] https://www.pivotaltracker.com/story/show/76376202

Thanks,
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?

Thanks.

Thanks Amit - this helps a lot.

Hi Rishi,

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[1],
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[2], 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[3]. 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[4] 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.

[1] https://github.com/cloudfoundry/cf-deployment
[2] https://github.com/cloudfoundry/bosh-notes/
[3]
https://github.com/cloudfoundry/cf-release/blob/v222/jobs/cloud_controller_ng/spec#L396-L398
[4] https://www.pivotaltracker.com/story/show/76376202

Thanks,
Amit, OSS Release Integration PM

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?

Thanks.