Cloud Foundry Advisory Board Meeting, Feb 2017: CAPI and CredHub Updates

Zach Robinson

The ability to disperse workloads to discrete isolation segments through the Cloud Foundry’s Cloud Controller API (CAPI) was a key topic of discussion during the monthly Community Advisory Board (CAB) call on Wednesday, February 17.

The topic had been raised a month earlier, and had been fine-tuned since then, according to new CAPI project manager Zach Robinson of Pivotal Labs. Other topics of discussion during the call included progress on the new CredHub proposal, and several other technical updates from project leaders within the open-source Cloud Foundry community.

CAPI update

Zach noted that isolation-segment functionality was completed last month, but the CLI team asked for some updates. One new feature is to allow users to move existing apps to existing Cloud Foundry spaces, rather than having to open up a new space each time. Blue-Green deploy functionality is scheduled to be completed by next month’s call.

He also noted that new HTTP health-check functionality allows apps to implement its own health check to signal more explicitly that it is ready to receive requests. Zach also provided some other brief updates:

• Securing communication paths to other components.
• Cloud Controller (CC) Bridge components are being removed and instead pulled into CC to talk directly to Diego components over mutual TLS.
• Latest CF Release: Support for global auditor scope.
• Auditor permissions and access without having to be explicitly added to spaces and orgs.
• No access to VCAP services for example.

GitHub repo | Pivotal Tracker

CredHub update

Dmitriy Kalinin

Dmitriy Kalinin of Pivotal Labs said he and his team are now closing in on enabling Config Server to use the proposed CredHub management system. This will enable enterprises to run a single Cloud Foundry deployment across multiple OpenStacks or vSpheres, for example, without the need for multiple APIs.

Dr. Max

Other uses could include running AWS and bosh-lite to “run errands or do some calculations and deploy the workloads on a different set of machines,” he noted.

Following the call, Dr. Max of IBM posted a message to the community saying he would like to move the CredHub proposal (originally submitted by Dan Jahner of Pivotal) into incubation.

GitHub repo | Pivotal Tracker

Other technical reports

Project leaders submitted several other technical reports during the call.

 
BOSH

• Config-server work getting completed.
• MultiCPI work going on.
• CLI v2 coming very soon. In it, bosh-init is being replaced by create-env and delete-env.
• Please refer to the bosh-deployment repository for examples of using CLI v2.

GitHub repo | Pivotal Tracker

CF-extensions

• Process proposal submitted.
• Abacus broker incubated (submitted by SAP).
• CredHub project moving for vote (submitted by Pivotal).

Diego (Eric Malm, Pivotal)

• Reducing dependency on Consul.
• Running route-emitter component in cell-local mode, needs to be exercised in production to test for a bit.
• Exploring moving the locks of components for BBS / auctioneer out of Consul into something backed by relational databases.
• Working on meeting responsiveness for fast fail over and recovering from failures in active components.
• Initial work on per-instance identity.
• Generating per-instance key pairs signed by the platform. Example: apps storing secure creds in CredHub and being able to retrieve from CredHub

GitHub repo | Pivotal Tracker

Garden

One of the community issues raised during the call was the status of Docker authentication in Diego and was answered with the following:

• Docker authentication is at the Garden level.
• All of the action there has to happen when Garden or new grootfs component pulls image from repository that requires authentication.
• Expecting bulk of work to happen there and the rest is just wiring.
• The staging task also need creds available there so need a change in Docker life cycle there.

GitHub repo | Pivotal Tracker

UAA (Dieu Cao, Pivotal)

• New version with breaking changes, see release notes.
• Next version will be 4.0 with consolidation of configuration properties, has a legacy .yaml file for when things were separate will be consolidated for ease of use and documentation.

GitHub repo | Pivotal Tracker

The next meeting is scheduled to be held on Wednesday, March 15, at 8 am Pacific Time.

Want details? Watch the video!