Cloud Foundry / Cloud Foundry Day at OpenStack Summit 2017

When we have a stable Cloud Foundry (CF) running on our OpenStack, developers only need to care about their apps. Then the problems we need to solve become the following: how can we automate CF on OpenStack infrastructure in an efficient and effective way? How can we manage CF from development, to staging and on through production? How do we backup CF with all of its apps and services such that in the case of disaster we can fully rebuild and restore the system? How can we monitor CF system's me

The Open Service Broker API provides a means of adding new services to your Cloud Foundry application, but usually that means creating a new service broker for each additional service. In this talk, we demonstrate the Brooklyn service broker, which utilizes the open source application blueprinting and management platform Apache Brooklyn to deploy a multitude of services on OpenStack with a single service broker.In this talk, Robert Moss will give examples of services from a range of NoSQL and an

The goal of any PaaS is to abstract away the underlying hardware or software infrastructure. "Here is my application, I don't care how you deploy it, just get it done!" But your target infrastructure will have its own nuances. This is certainly true for OpenStack. Having deployed and automated BOSH and Cloud Foundry hundreds of times, over several versions of OpenStack, we at Stark & Wayne have had the opportunity to see many of the edge cases, and constant sources of implementation pain that oc

Applications that are deployed to the Cloud Foundry platform often rely on external services like databases to provide their functionality. The performance and reliability of these services are therefore key elements in the user experience of the app. Cluster deployments of these services within OpenStack are the preferred way to accomplish these goals. However the manual deployment and removal of these services can be cumbersome and error prone. To circumvent these flaws the service broker itse

Service brokers provide a well-proven way to manage services in Cloud Foundry. This way applications can be easily connected to services like databases or message queues. But there are situations where direct access to a service is required. For this scenario Cloud Foundry provides the concept of generating service keys that hold credentials that allow access to a service instance. But what about situations in which the service is deployed in a private network that is only accessible from Cloud

In this talk we will demonstrate running a containerized Cloud Foundry system on top of OpenStack Magnum (using Kubernetes). We will talk about our experience containerizing Cloud Foundry and how it was made to work on Magnum, as well as running on other Kubernetes systems. We will be sharing interesting improvements and present the challenges of keeping highly available systems online and up-to-date.

According to the 2016 OpenStack survey, Cloud Foundry is the second most popular workload on OpenStack for managing applications. To ensure that Cloud Foundry runs on different OpenStack distributions and configurations is an important and classic interop example.From the OpenStack side, we see efforts towards interoperability between different OpenStack installations: There are challenges done by the foundation, as live on stage at the Barcelona summit. There is RefStack, defining a set of requ