This document provides updates on various Cloud Foundry projects and roadmaps. It discusses improvements and activities for projects including Diego, Garden, Loggregator, Routing, Container Networking, BOSH, and various services. The focus is on areas like security, scaling, performance, developer experience, and enabling new runtimes.
10. Buildpacks / Staging
• Ruby code that detects language,
frameworks, whatnot…
• Compiles the code into executable
binaries (*)
/bin/detect < Am I supposed to run?
/bin/compile < Build the thing
/bin/release < Pass along potential metadata
cflinuxfs2
16. 16
• Security
– Ongoing vulnerability fixing
– Keeping up with dependencies
– Adding TLS between all components
• Scaling and Performance
– Diego scale testing exercised larger set of components
– Routing and Loggregator teams heavily invested in performance
and scaling
17. 17
• V3 APIs
– New application lifecycle capabilities
• Isolation Segments
– “A group of Cloud Foundry resources (compute, network,
logging) to which applications can be directed for deployment.”
– Supporting more complex policies for application deployment
location
20. 20
Responsible for high level integration testing
for the Cloud Foundry platform, final release
integration pipelines, and tooling for generating
BOSH deployments to deploy the platform
from all its integrated components.
• Lead: Davis Sabeti (Pivotal)
• Team: 5 Pivotal, 1 Dell EMC
• Primary Location: San Francisco
Significant Activities:
• cf-release generally released twice a
month
• cf-deployment introduced to community on
2017-01-26
– BOSH deployment manifest for
deploying CF
– Will eventually replace the manifest
generation scripts in cf-release
– Will eventually replace cf-release
entirely
• Shipped cf-deployment-concourse-tasks to
help other teams test against cf-
deployment
22. 22
Enables developers to interact with the Cloud
Foundry platform and its services via the
command line. This team oversees its
development and prioritizes improvements /
additions to this crucial developer experience
component.
• Lead: Dies Köper (Fujitsu)
• Team: 6 Pivotal, 1 Fujitsu, 1 SUSE
• Primary Location: San Francisco
Significant Activities:
• Usability
– Tab completion
– Reworked help content
• Ease of installation
– Reduced executable size
– Package publishing
– Code signing
• Always focused on keeping up with new
features exposed by the CAPI team. Ex:
– Support for v3 API Tasks
– Support for TCP Routing in manifest
files
23. 23
CAPI is the interface for the platform's
functionality, orchestrating a user's interactions
with the system. This team is in charge of
designing, architecting, and prioritizing
development work that keeps the API flexible,
consistent, and extensible.
• Lead: Zach Robinson (Pivotal)
• Team: 7 Pivotal, 2 IBM, 1 SUSE
• Primary Location: San Francisco
Significant Activities:
• v3 Tasks API completed
• Experimental support if v3 APIs for Apps,
Droplets, Isolation Segments, Packages,
Processes, Route Mappings and Service
Bindings
• Enable zero downtime migration for apps
into isolation segments
• Mutual TLS between components
• Eliminate cc-bridge component
• CC API rate limiter
24. 24
Responsible for the UAA service, which aims
to simplify the identity management of users
and user accounts through their Cloud Foundry
credentials.
• Lead: Sree Tummidi (Pivotal)
• Team: 4 Pivotal, 1 VMware, 1 GE
• Primary Location: San Francisco
Significant Activities:
• Constant stream of improvements and bug
fixes
• Azure and Google added / tested as
identity providers
• UAA 4.0.0 in progress
• Working with GE on UAA performance
testing
25. 25
Log Aggregator (Loggregator) is responsible
for platform and application log management.
• Lead: Adam Hevenor (Pivotal)
• Team: 7 Pivotal
• Primary Location: Denver
Significant Activities:
• Performance testing and tuning
• Added App, org and space name to syslog
drains
• Implementing gRPC for Metron to Doppler
connections
• Mutual TLS
• Working on Scalable syslog feature –
allows scaling of syslog drains
independently
• Working on Health Nozzle – operator
feature to provide detailed logging pipeline
diagnostic data
27. 27
Diego is the new container runtime for Cloud
Foundry, replacing the older DEA / Health
Manager architecture.
• Lead: Eric Malm (Pivotal)
• Team: 7 Pivotal, 2 IBM
• Primary Location: San Francisco
Significant Activities:
• Diego 1.0.0 reached on November 29,
2016 (beginning 6 month EOL timeline for
DEA’s)
• 250,000 containers supported
• BBS converted to relational DB backend
for performance (both MySQL and
PostgreSQL)
• Integrated with Container Networking and
Diego Persistence projects
• Working on Loggregator v2 API adoption
• Continued performance testing/tuning
28. 28
Garden is a secure container API and runtime
for the Cloud Foundry runtime. It can be
backed by both Linux and Windows
implementations.
• Lead: Julz Friedman (IBM)
• Team: 3 Pivotal, 2 SAP, 1 IBM, 1
Swisscom
• Primary Location: London / Sofia
Significant Activities:
• Garden-Linux depricated
• AppArmor, user namespaces and
seccomp all enabled by default when
using garden-runc
• Support of C2C team’s requirements /
plugin model
• Single ”gdn” binary – easier to test and
experiment with Garden
• Preparing for ”better DNS” support
(specifically BOSH DNS proposal)
• Establishing perf benchmarks
29. 29
The Garden RootFS (GRootFS) provides the
filesystem management for applications
deployed on the Cloud Foundry platform.
• Lead: George Lestaris (Pivotal)
• Team: 4 Pivotal, 1 IBM
• Primary Location: London
Significant Activities:
• Made filesystem drivers pluggable (btrfs
no longer the only option)
• Added support for overlay-xfs
30. 30
The Garden Windows (Greenhouse) team
works on adding a Windows backend for
Garden and enabling .NET development on
the Cloud Foundry platform.
• Lead: A William Martin (Pivotal)
• Team: 4 Pivotal
• Primary Location: New York
Significant Activities:
• Inception on Windows Server 2016
• Investigating OCI-compliant
Garden/HCSSCIM layer
32. 32
• Volume Services shipping as of cf-release
v242
• Storage services exposed via the Service
marketplace
• Storage can be multi-attach (NFS) or local
scratch space
33. 33
Added the ability to attach data volumes to
applications deployed within Diego, including
the implementation of relevant Service Brokers
and Volume Drivers within Diego Cells.
• Lead: Julian Hjortshoj (Dell EMC)
• Team: 5 Dell EMC
• Primary Location: San Francisco
Significant Activities:
• Ongoing interactions with Kubernetes,
Docker and Mesos communities around a
Common Volume Interface API
• Working with Orange Telecom and Church
of Later Day Saints for ongoing customer
feedback
• Dell EMC technical integrations: ECS and
Isilon
• Read-only mount support
• NFS-broker now supports cf-scaling &
blue/green upgrade
35. 35
Ensures that application requests are passed
through correctly to the correct destination, be
that an application or platform system
component. The Routing project also owns the
development of operator and developer user
experience for managing routes and domains.
Includes HTTP and TCP routers.
• Lead: Shannon Coen (Pivotal)
• Team: 6 Pivotal, 1 IBM, 1 SUSE
• Primary Location: San Francisco
Significant Activities:
• Recently incepted on Routing for Isolation
Segments
• Performance focus since late 2016, with
initial focus on instrumentation
– Numerous perf improvements
identified and shipped
– Performance comparisons being
shared as part of every release
36. 36
Route Services – Released in 2016
Fully Brokered and User Provided Services
Static, Brokered Services
TCP Routing – Released in 2016
37. 37
Core Components
• CF CLI plugin enables administrators to control network
access policies between CF applications
• Policy Server, a central management node, exposes a
JSON REST API used by the CLI plugin
• Garden External Networker, a Garden-runC add-on
deployed to every Diego cell
Batteries included, but swappable
• Flannel CNI plugin, provides IP address management and
network connectivity to app instances (containers)
• VXLAN Policy Agent enforces network policy for network
traffic between applications
• Uses CNI API to support alternative implementations
38. 38
Incubating project charged with developing a
Garden-runC add-on capability that provides
container networking for the Cloud Foundry
platform.
• Lead: Usha Ramachandran (Pivotal)
• Team: 5 Pivotal, 1 IBM
• Primary Location: Santa Monica
Significant Activities:
• Control-plane communications secured via
Mutual TLS
• Configurable subnets and ranges for the
overlay networks
• Stability, Scalability and Hardening
• Planning for policy extension to external
services
39.
40. 40
The Open Service Broker API (OSBAPI)
project allows developers, ISVs, and SaaS
vendors a single, simple, and elegant way to
deliver services to applications running within
cloud native platforms such as Cloud Foundry,
OpenShift, and Kubernetes.
The project includes individuals from Fujitsu,
Google, IBM, Pivotal, RedHat and SAP.
https://www.openservicebrokerapi.org/
Projects:
• Open Service Broker API
Activities:
• Remove CF-isms
• Broker defined schemas for parameters and
binding credentials
• Define approach to extensions / experiments
• Support for Backup / Restore
• Broker “Actions”
41.
42. 42
BOSH is a platform that unifies release
engineering, deployment, and lifecycle
management of small and large-scale cloud
software, on virtually any infrastructure.
BOSH Core
BOSH CPI’s
OpenStack
CPI
SoftLayer CPI
BOSH
Windows
https://bosh.io/
43. 43
BOSH is an open source tool for release
engineering, deployment, lifecycle
management, and monitoring of distributed
systems.
• Lead: Dmitriy Kalinin (Pivotal)
• Team: 15 Pivotal, 1 IBM
• Primary Location: San Francisco, Toronto,
Walldorf
Significant Activities:
• BOSH “2.0”
– Dramatically simplifying BOSH deployment
manifests
• Dynamic IP management
• Global Cloud Config
• 1st class support for multi-AZ job striping
• Manifest enhancements
• Multi-CPI Support
• In progress:
– Config Server
– New Update Strategies
44. 44
The BOSH CPI’s Project is responsible for all
CFF owned CPI’s that are not independent
projects, including AWS, Azure, vSphere,
vCloud, Photon and GCE.
• Lead: Dmitriy Kalinin (Pivotal)
• Team: 2 Pivotal
• Primary Location: San Francisco
Significant Activities:
• In 2016, new CPI’s were developed with
infrastructure partners, including:
– Azure
– GCE
– Photon
45. 45
The BOSH OpenStack CPI Project owns the
OpenStack CPI and cf-openstack-validator.
• Lead: Marco Voelz (SAP)
• Team: 5 SAP, 2 SUSE
• Primary Location: Walldorf
Significant Activities:
• cf-openstack-validator: finally an
automated way to validate your
OpenStack installation for Cloud Foundry
• Supports OpenStack Mitaka
• Now defaults to OpenStack Neutron
Networking
46. 46
The BOSH SoftLayer CPI Project owns the
SoftLayer CPI.
• Lead: Michael Maximillien (IBM)
• Team: 7 IBM
• Primary Location: Distributed
Significant Activities:
• Maintenance
47. 47
The BOSH Windows Project owns the
Windows stemcells and ensuring the BOSH is
able to work with Windows hosts.
• Lead: A William Martin (Pivotal)
• Team: 5 Pivotal
• Primary Location: New York
Significant Activities:
• Tightly coordinated (shared PM) with the
Garden Windows project of the Runtime
PMC
