Cloud Foundry Advisory Board Meeting, Feb 2018: Abacus, Envoy, and containerd
The main highlight of this month’s call was a demo of CF-Abacus by Hristo Iliev of SAP. (Abacus provides usage metering and aggregation for Cloud Foundry services.)
Other topics on the agenda included reports from project-management teams, a call for more contributors to the Cloud Foundry documentation, and an update on the upcoming Cloud Foundry Boston Summit.
Abacus is a uniquely critical project within the CF community, as its goal is to serve as a trusted bookkeeper throughout Cloud Foundry deployments. It is built as a set of REST microservices that “collect usage data, apply metering formulas, and aggregate usage at several levels,” according to its GitHub description. CF-Abacus is implemented in Node.js with microservices running as Cloud Foundry apps.
CAB call moderator Michael Maximilien (aka Dr. Max) from IBM congratulated Hristo and the Abacus team on their progress, noting that “users complain about costs, so we need this technology to track the use of resources accurately and consistently.”
As always, all the projects within the open-source world of Cloud Foundry welcome new contributors.
Pivotal’s Dieu Cao noted that Envoy—a Cloud Foundry service broker front end—has now been added to containers. The first use case is improving route integrity for the apps built with the Hortonworks Data Platform. “So, containers can reject connections that aren’t intended for them by taking advantage of identity certificates that Diego has,” she said. “Service discovery for internal routes is also now there, and we’re looking for feedback.”
The containerd runtime
Julian Friedman (Dr. Julz) from IBM incepted the containerd runtime for managing the full container life cycle from image transfer / storage and container execution / supervision to low-level storage and network attachments. Now, it is available as a daemon for Linux and Windows.
Dr. Julz noted that “there is a consistent operator experience with containerd. We also think we’ve improved garbage collection (for the moment) by figuring out the “low-hanging fruits” method that will tide us over until we can do something much better.” He asked to look for details in the next Garden release, mentioning that “operators will no longer have to guess fairly unguessable values (with this) garbage collection of the Docker image layers.”
Dr. Julz also discussed some details of working with Kubernetes and Docker, concluding that “whether you are in Docker, Kubernetes, or Cloud Foundry, you’ll have containerd in the bottom level. We like the containerd approach provisionally.”
The BOSH team reported that it has two new co-chairs, Matt McNeeney from Pivotal and Doug Davis from IBM. Matt also highlighted a few technical developments that are being encompassed in the BOSH v2.14 update. This list includes continued work on faster deploys and updates, as well as several updates for stemcells. In addition, “the Open Service Broker API is working on service instance actions, such as how a broker in a programming way can use an API and do things like backup and restore, etc.,” according to Matt.
The essential need for Cloud Foundry docs
Ben Tarnoff discussed the maintenance of Cloud Foundry documentation. He described three groups of people using these docs:
- Operators who need to install, configure, and manage Cloud Foundry
- Developers who need to know how to run and manage their apps
- “Tire kickers” and others who need to know how Cloud Foundry works
Pivotal employees currently create 90% of the docs, Ben said. This fact has led to a concern that accuracy and completeness may suffer due to time constraints on the Pivotal staff. According to him, this “could possibly lead to fewer people using Cloud Foundry,” which is something nobody wants. “All (the Cloud Foundry Foundation) members have a stake,” Ben noted. And the creation and maintenance of the documentation is essential as “without docs, Cloud Foundry is unusable,” he observed.
Ben added that he and others are now cultivating Cloud Foundry docs evangelists within member companies, and urged anyone with an interest in contributing to contact the docs team. He also provided a link to a guide on creating Cloud Foundry documentation.
Boston summit is approaching
Call attendees were reminded that the Cloud Foundry Summit 2018 has been moved to new date and location this year and will be held April 18–20 in Boston. Swarna Podila from the Cloud Foundry Foundation said the schedule includes a Hackathon User Day, and that the attendee signup is on track with that of a last year. There is also a contributor code available now, she added.
Swarna also drew attention to the Cloud Foundry Day that will be held on May 1 in Copenhagen, just prior to the KubeCon conference. The call for papers for this event is still open and will close on Friday, March 16.
The next CAB call is scheduled for Wednesday, March 21, beginning at 8 a.m. Pacific Time. Anyone who is interested in contributing to the global Cloud Foundry community is encouraged to attend. Ongoing information can be found within this Slack channel.