Earlier this month we moved to a new open source contribution process for Cloud Foundry. As part of the new process, we also want to share more information about what code is coming in the future. This post is the first in what will be a regular series on the Cloud Foundry roadmap.
During the Cloud Foundry Anniversary event we made a point to call out that 80% of our work is really “below the water line”. We are doing a lot of work on the core infrastructure, and only a small fraction of what we do surfaces itself as a visible feature.
For those of you watching the repos, I want to give you a little context on some of the pieces that are sitting around in the code, or are in the process of being added.
We have been working on a major deconstruction of the core cloud controller (see the event slides 7-9). This involves systematically removing responsibility from the cloud controller and moving these pieces into independently scalable components, which run with different levels of isolation. If terms like cloud controller, router, and dea are new to you, review this presentation.
If you look closely at the current code base you can see the new User Account and Authentication (UAA) component. We’ve been validating UAA on CloudFoundry.com where it is performing authentication for a subset of the accounts. The UAA code has been in the public GitHub repository for several months, and we have rolled pieces of it incrementally into CloudFoundry.com in phased deployments. We have one more turn of the deployment crank and when this is done, UAA will be the source of all authentication, and the old authentication system embedded in cloud controller can be removed. The UAA component is key for us as we start enabling more advanced forms of authentication and integration.
The deconstruction effort is nearly complete and with that behind us, the last major new replacement component is landing in the code base as we speak. What’s left of the old cloud controller is being replaced with an all new system.
Over the next several days you will see the “cloud_controller_ng” repo appear and will see the first batch of commits. Architecturally, the new cloud controller will adopt the more traditional Sinatra/Sequel framework used in several other components. Functionally, the new cloud controller exposes a new set of objects that provide additional scoping and sharing semantics designed to support operational collaboration and advanced, pooled quota controls. Watch for this repo, and then carefully read the new model and note the new “org” and “app-space” objects.
In the future, this sort of development will happen directly in the Gerrit-based open repos. Moving in code at this stage of development is not our normal mode of operation, but during the final steps of the transition, we have a handful of repos whose move is still in-flight.
The next major component to watch for is the next-generation vmc client. The vmc gem exposes the core cloud foundry API as a simple-to-use set of ruby objects. Unfortunately, the way the API is exposed, some of the key functionality (create and update applications) is poorly exposed through the object model. You literally have to cheat and use pieces of the cli class hierarchy in order to use the gem with these functions. The NG version of vmc addresses this with a completely clean and well-factored object model. In addition, it’s made major improvements in its approach to extensibility. Its approach to scripting and integration is well thought out. And finally it eliminates the use of fake tables in its output.
I’ll do my best to keep you updated as there is a lot of activity in the code base. On your own though, the best way to stay up to date and engaged is to join the code review discussions or the project-level discussions on vcap or BOSH.
Mark Lucovsky, VP of Engineering – Cloud Foundry
About the Author
BiographyMore Content by Mark Lucovsky