OpenStack Mitaka Design Summit

 Is OpenStack commercially viable for service providers?

Any service provider looking to develop its cloud solution business wants a service that can be brought to market quickly and cost effectively. It needs to provide differentiation, and to be able to scale as the service grows.

How to achieve that? Build or buy? or any combination?

In this session we will go through some of the challenges we faced when creating OpenStack based Cloud Service Providers in the early days and how we would do some things differently.

Amazon Web Services has had regions across the globe and Availability Zones (AZ) as standard offering for years. The tiering and choice of locations is best practice that OpenStack architects should embrace as they build a blueprint for geo-distributed OpenStack clouds. The notion of different regions and AZ allows smaller “blast zones” in the event of outages plus enables use cases such as active/standby clouds, tenant data replication and new tiered application architectures. All of these use cases are extremely attractive but if not undertaken correctly, a geo-distributed OpenStack endeavour can be unpredictable, costly and complex.

The cornerstone to a winning Geo-Distributed OpenStack Clouds architecture is the networking layer.  While there are existing network architectures that leverage existing routing protocols and tunnelling mechanisms, OpenStack offers an opportunity to rethink and implement a lightweight mechanism based on a radically simpler software based implementation.

In this session, learn how PLUMgrid is leveraging existing OpenStack compatible technologies and extending it to support a geo-distributed OpenStack cloud architecture. We will delve into technical implementation, physical infrastructure considerations and use case examples.

Today’s telecom services are driven by demand for cloud-based services. Customers want dynamic,
on-demand cloud services over any combination of virtual and physical networks. The most urgent problem service providers have today is automating the delivery of network services and accelerating cloud service rollouts.

Service Function Chaining provides end-to-end network service delivery automation that operates completely independent of whether the network is physical or virtual. It integrates with today’s network infrastructure to create a network service abstraction layer that isolates operations from tedious and diverse configurations at the network layer, making the service layer simple, generic, and programmable. Network service can be auto provisioned and deployed on both general COTS platforms and legacy network devices in your data center using service function chaining, in which a wide variety of service functions scattered over the newtork may be chained together in a flexible and agile manner to provide desired service treatment. Scale-out of these service functions to handle added load or scale-in to reduce the resource usage is an integral part of the service function chaining solution.

This presentation will talk about how you can integrate the service function chaining feature, which is being developed as part of OpenStack Neutron, into your Cloud Platform to auto provision differentiated Cloud services in an agile and flexible way, and how to turbo-charge your cloud using service chaining. The following topics will be covered:

1. Overview of OpenStack Neutron Service Function Chaining Solution
2. How to define the service chains in a simple, prescriptive manner to create cloud services tailored to the needs of individual customers
3. How to ensure vendor independence and be agnostic of underlying network technology
4. How to achieve scalability and elasticity (scale-out and scale-in) of service functions on your cloud platform
5. How to integrate container technologies, such as Docker, with Service Function Chaining

Managing multiple sites of OpenStack is a headache.  Each site is an individual silo, with its separate identity management, resources, networks, images, etc.

Tricircle project uses a top-level OpenStack to manage multiple bottom-level OpenStack instances with site-to-site connectivity, to provide the same overlay across sites.  This allows for a tenant to deploy VMs from the same virtual network on different OpenStack instances.

In this session, we will deep dive into the Tricircle project, covering aspects such as cross-site overlay network, image synchronization, VM migration, etc.

We will present our current design and roadmaps.

Abstract: Based on the results of OpenStack user surveys, KVM is the de facto hypervisor used to underpin OpenStack clouds and Open vSwitch the most common network plug-in. However, as OpenStack matures to run production workloads and broadens its reach beyond the core users, it is inevitable that additional hypervisors, containers, bare metal workload will gain a foothold.  

The whole notion of supporting a multi-hypervisor OpenStack environment is need driven. To illustrate, imagine that some databases in a business are virtualized on ESXi while the corresponding web servers are virtualized using KVM. In addition to the diversity, it is highly likely all these hypervisors and Docker container will be running concurrently in the same OpenStack cluster. As a result, a different approach to interconnecting is required to provide common network substrate.

We’ll discuss how multi-hypervisor networking in OpenStack can be achieved. This session will cover the technology options, the benefits of each and dive into various use cases where a multi-hypervisor OpenStack environment is desirable.

By definition, DefCore picks what is required for vendors to use the OpenStack trademark. Ideally, that allows workloads to interoperate between vendors.  A common baseline may help users but can impact vendor differentiation.

So does that mean we are picking winners?  Join us at this session and we'll give you the background and review the critical issues to answer that question.

What is DefCore?  With a growing number of OpenStack projects, we define what is the minimum set of OpenStack capabilities and components that must be enabled.  We go further and define the actual tests (from Tempest) that vendor clouds must pass.  

Why? DefCore is trying to define the minimum set of capabilities for INTEROPERABLE CLOUDS; it is not about an OpenStack distribution or release but trying to create a multi-vendor ecosystem.

After attending this session, you will know what DefCore is, how capabilities get defined, and how it is decided what is and what is not part of DefCore.

After we cover the basics, we'll bring you up to speed on the hard questions that DefCore is trying to address.

 The term hybrid cloud is often used to describe a “cloud burst” scenario – extending the organic datacenter to the cloud, either by moving specific applications/workloads that are suitable for cloud offloading, or by using more advanced solutions that provide additional resource capacity from the public cloud provider.

In this session, we will present a different approach to managing a “hyper cloud” – a cloud over clouds that is completely OpenStack-based, centrally managed, does not require any organic datacenter to begin with and which provides a single overlay network.

We will touch on the following aspects: central management, overlay network, image portability & synchronization and zero-configuration VM migration.

Provisioning servers has long been service providers’ bread and butter, but in recent years customers’ demand for higher-performing bare-metal instances has increased dramatically, along with their interest in integrating bare-metal infrastructure with virtualized public clouds. This shift in the types of infrastructure customers are demanding is motivating service providers to create more efficient ways of both provisioning bare-metal infrastructure and integrating it into their customers’ overall infrastructure mix, and OpenStack has recently emerged as a key platform in making both of these developments possible. 

Focusing on the creation of a hybridized, OpenStack-based bare-metal and virtual cloud infrastructure, this technical talk will look at the challenges encountered as well as the solutions developed to successfully deliver bare-metal instances with Ironic and hybrid bare-metal and virtual infrastructure. Specific topics that will be covered include:

• Networking model and automation


• Deployment of cells


• Integration with 3rd party software


• Security