Re: Cloud Foundry DEA to Diego switch - when?


Amit Kumar Gupta
 

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.

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.