Cloud Foundry Advisory Board Meeting, Apr 2017: DEA’s End-of-Life on May 22
Anticipating the summit
The steady improvement of Cloud Foundry software was an underlying theme of the Community Advisory Board (CAB) call, April 2017. Led as always by Dr. Michael Maximilien (a.k.a. Dr. Max) of IBM, the call featured two demos—cf-deployment and Turbulence releases—and an overview of the recent progress, as well as a brief discussion of the upcoming Cloud Foundry Summit, to be held June 13–15 in Santa Clara, CA.
Chip Childers, CTO at the Cloud Foundry Foundation, said he expected a record attendance on the order of 3,000 people at the summit, and that new training and certification courses will be available.
Chip also noted that people opting to take in-person exams will receive a $150 discount on their summit registration. The certification exams should take three to four hours to complete, he said. They are performance-based, meaning examinees need to complete actual tasks. Chip added that the CF Foundation expects the courses to be valid for about two years.
(Altoros is hosting a logging and monitoring workshop during the first day of the summit, as well, on June 13.)
End-of-life for DEA
Dieu Cao of Pivotal confirmed the end-of-life (EOL) for the Cloud Foundry’s legacy DEA back end, which will occur on May 22. This comes in the wake of Diego v1.0 being viable late last year, and “closes out a great chapter for Cloud Foundry,” she noted.
Previously, Dieu has written “we are moving the DEAs to the Cloud Foundry Attic, meaning the DEAs will no longer be supported, no longer be patched for any reason, and no longer accept any contributions.”
“The team is removing distribution of the DEAs from cf-release, shutting down all CI pipelines related to the DEAs, and removing all code paths and technical debt in the Cloud Controller associated with running Cloud Foundry on multiple back ends.” —Dieu Cao, Pivotal
The cf-deployment demo
cf-deployment is meant to be a canonical manifest for deploying Cloud Foundry without the use of cf-release, relying instead on individual component releases. It will replace the manifest generation scripts in cf-release when cf-release is deprecated. It uses several newer features of the BOSH director and CLI. cf-deployment uses Diego natively, does not support DEAs, and enables several Diego-specific features.”
There are many other things of particular interest, including the elimination of global properties; “everything has its own properties,” as David noted. Further, “Diego gets in-lined into your deployment, so you don’t need one deployment for (previous) Cloud Foundry and one for Diego,” he said. “You can now put everything into the same deployment, so there’s no more splinter deployments if you don’t want them.”
David also noted that this project is still in development, with a current goal of developing a migration path from cf-release to cf-deployment. His presentation will be found in the CAB call recording available via the Cloud Foundry CAB sub-channel on Slack.
The Turbulence release
Dmitriy Kalinin of Pivotal then presented the Turbulence release used for injecting different failure scenarios into a BOSH deployed system. The idea is to “throw in some type of failure, and see how your environment behaves,” Dmitriy noted. “What is the business impact if something happens to your environment?”
Currently supported scenarios include:
- VM termination on BOSH supported IaaSes
- impose CPU/RAM/IO load
- network partitioning
- packet loss and delay
Two jobs are now available under this release: turbulence_api and turbulence_agent. The API job embodies a server, providing a management UI and accepting API requests to schedule and execute failure scenarios. An agent daemon retrieves instructions from the API server, and should be placed onto participating VMs.
Next steps include creation of a configuration doc for API servers / agents, an API doc on using Turbulence, and a development doc to let people know how they can contribute.
Using BOSH 2.0
Dr. Nic Williams of Stark & Wayne then focused on how to make use of the BOSH 2.0 features. “It’s always good to look and see how far we’ve come,” he said. “Bringing up systems today is so simple and wonderful (compared to the past).”
He provided an example of what it takes to deploy BOSH now and previously:
Diego update
Eric Malm from Pivotal updated the community on Diego, which he said “continues to move away from its dependency on Consul.” (Consul is the original distributed key-value store to provide service discovery, key-value configuration, and distributed locks within cloud infrastructure environments.)
In other Diego news, there is a new proposal submitted by Zach Robinson of Pivotal about zero-downtime applications updates. As Zach wrote in a collaboration proposal, “Cloud Foundry application developers want to push updates to their applications without incurring downtime. There are many types of updates to an application—updating application source, environment variables, service bindings, routes, application security groups, dependencies provided by a buildpack, and the application profile, such as memory and disk. The proposed feature is to provide platform support for zero downtime application updates for the most common application update scenarios, by taking advantage of the new Cloud Foundry v3 API.”
Dmitriy Kalinin also talked about BOSH DNS, which “we’ve been working on for a couple of months,” he said.
“We’re working on the ConfigServer integration, which will be in next BOSH release and will be cut soon. We’re also working with other teams to ensure the DNS system works for their use cases. So, we’ll likely add some compatibility flags to make the transition easier.” —Dmitriy Kalinin, Pivotal
Overall, “BOSH CLI v2 should be generally available by the end of April,” Dmitriy noted. “It will allow users to set multiple runtime configs and help with addon management,” he noted. “DNS v2 will be expected to be installed as an addon, and bosh-deployment repo will contain the DNS addon.”
What’s next?
(Updated) On the day of the CAB meeting, Chip Childers also issued a Cloud Foundry Technology Review for Jan-Mar 2017. There, he presented a “roundup of news from the Cloud Foundry technical community,” covering updates across most of the CF projects. Really worth reading.
The next CAB call is scheduled for Wednesday, May 17, at 8 a.m. Pacific Time. It will be the last call before the upcoming Cloud Foundry Summit. The calls are open to anyone interested via registering with the community’s Slack channel.
Related video
David Sabeti spoke on breaking the cf-release monolith at the Cloud Foundry Summit 2016.
