OpenStack Summit November 2014 Paris

This session is a technical deep dive on the OpenStack Neutron's Network Virtualization capabilities with default NSX Plugin and demonstrates an OpenStack Cloud with KVM, Xen, vSphere, Hyper-V, Docker, & Bare-metal compute platforms communicating over a single virtual Network.

The good, the bad & the ugly from a field deployment practitioners perspective. We will  also cover one of Neutron's Network Virtualization plugin's detailed overview and deep dive into real life benefits & challenges. We will be covering NSX Plugin - a virtual networking platform powering many OpenStack production environments as the networking engine behind Neutron. In this session we will explore the distributed systems architecture of the NSX Controller Cluster, the core functionality and behavior of NSX primary system components, and the logical networking devices and security tools NSX produces for consumption. High availability deployments, and packet flows for common scenarios will be discussed. 




And finally, we'll take a look at how the physical network fabric can be architected for Virtualized Network deployment architectures, be it with out without NSX.

Everyone is excited about OpenStack these days, and while there s plenty of flavors of OpenStack for your datacenter, there is limited data for making decisions on the technology stack that runs OpenStack. Furthermore, OpenStack consists of many projects (e.g., Nova, Cinder, Neutron, Marconi, Trove, Ironic) with pluggable backends, which are powered by many different vendors.

 

With so much choice out there, you need the right information to evaluate each vendor's tools for performance and ability to handle cloud scale workloads.

 

In this session, you'll learn about the Rally + OSProfiler tool, which helps you compare vendors and their drivers in action in OpenStack deployments. You'll see how to get multiple data points like benchmarking graphs, code profiling graphs/data, bottlenecks across multiple OpenStack services--all of which can help you compare each vendor for your needs.

 

Rally + OSProfiler also helps driver vendors to improve their performance by digging into the same benchmarking and profiling data, which will improve the driver quality starting from the code development phases to the production and post-production phase.

 

If you're trying to evaluate OpenStack vendors and performance, this session is for you.




 

Over the last months, we could see more and more OpenStack deployments running in production.

Installing an OpenStack cloud that can scale does not only mean setting up packages and run your favorite automation tool to configure all the projects together.

It also means:

• test deployments (ability to reproduce the infrastructure)
  
  


• adding new features and fix bugs in components (continuous integration)
  
  


• manage upgrades (OpenStack releases, dependencies and operating systems)
  
  


• migrate the production with new features (continuous delivery) without downtime
  Here are the challenges: how to deal with staying as close as possible to the latest features available in OpenStack and how to upgrade an OpenStack cloud in production as often as possible.

We can see over the OpenStack distros market that they all provide a nice way to deploy OpenStack in 5 minutes from a great GUI. But do they really care about upgrades? Are they much more flexible than other solutions? Are they really production-ready?
 
In this presentation, I would like to present the path we take at eNovance to build, deploy and manage OpenStack in production, trying to respect all the requirements above. There is no magic behind it, we just love automation.
 
keywords: jenkins, puppet, ansible, eDeploy, packaging, CI, CD

Setting up an OpenStack cloud in the production environment is not an easy task , but there are a number of open source projects to solve the OpenStack deployment problem, including Open Crowbar, Fuel, Compass, Forman, and TripleO, etc. Why not just one project. Come listen to the developers who started these projects explain why they chose to build their tools, why they chose to make them open source, what their experience has been with production deployments, what the feedback has been from their users, and what lessons they have learned.

 

P { margin-bottom: 0.08in; direction: ltr; color: rgb(0, 0, 0); widows: 2; orphans: 2; }P.western { font-family: "Cambria",serif; font-size: 12pt; }P.cjk { font-family: "DejaVu Sans"; font-size: 12pt; }P.ctl { font-size: 12pt; }

In the High Energy Physics (HEP) and Astronomy communities, we have been accustomed to handling many different Virtual Machine (VM) types on multiple OpenStack clouds for several years. Manually copying the VM images to the distributed repositories is labour intensive and prone to error. To reduce the management overhead and the number of errors associated with distributing VM images, we have developed an image distribution service called Glint. Glint is being developed as an OpenStack service, adhering to OpenStack's development and deployment architecture and accessible through modifications to the Horizon dashboard. The service uses keystone authentication and leverages the glance API to control image distribution across the network.

 

Glint provides functions to allow users to identify remote repositories and to distribute images to those repositories. Glint maintains a list of remote repositories for each tenant and, for each user of the remote repository, the user's credentials. Having defined both the repositories and the required credentials, the user can display a matrix of repositories and images, and use it to control the distribution of images. Within the cells of the image distribution matrix, check-boxes indicate the presence (checked) or absence (unchecked) of images within repositories. Users can toggle one or more check-boxes and press the "Save" key to effect image distribution. A separate thread is created for each selection and all operations are performed in parallel.

 

This presentation, will discuss the experience of HEP users over the past several months, highlighting the user interfaces, processing internals, and future developments.

This session s goal is to illustrate how DevOps can use Heat to orchestrate the deployment and scaling of complex applications on top of OpenStack. In this example, we'll use the example of deploying OpenShift Origin (a PaaS) with multiple Brokers & Nodes, MongoDB, DNS requirements -  all of which can easily be deployed and managed using Heat (OpenStack's Native Orchestration tooling). We ll also cover creating images with OpenStack s Disk Builder and registering the images with Glance.

Starting with a walk-thru of the example deployment Heat Templates for OpenShift Origin (available in openstack github repository) We ll walk thru the existing templates and enhance them to provide additional functionalities such as positioning alarms, responding to alarms, adding instances, and auto-scaling.

As Heat is just one of a number of effective means for deploying and managing applications on OpenStack, we'll also give a quick overview of alternative examples as well including a walk-thru of an HA deployment using Puppet.  

 

 

 

So now that we’ve introduced NFV.. what’s the next step. In ETSi’s terminology for NFV.. The next step would be running a VNF (Virtual Network Function) on NFVi ( Network Function Virtualization Infrastructure) using some type of VNF manager. Ericsson and AT&T will demonstrate a key part of the mobility system, the IMS component, as a VNF provisioned via OpenStack based Cloud Execution Environment, orchestrated and managed by a Cloud Manager... and in the end we will be making an actual call through this demo system.

Just when you've safely got all your applications stood up in Grizzly, bam, it's time for Havana. So you scramble, but before you finish shutting workloads down, irritating users, and getting new machines, it Icehouse! Can you stop the madness?

 

 

It's no secret that OpenStack's upgrade path is ... less than optimal.  When you're ready to make the jump, you can simply go, buy new hardware and install a brand-new shiny OpenStack cluster with one of the many tools on the market.  But what are you going to do with applications that are already installed and working in your existing cloud? How to avoid the extended downtime while you ask all your users to shut down their workloads and move to the new installation?

 

 

And how much it will cost you to install a complete set of hardware for a replacement cloud with the same capacity as the original one?

 

 

Fortunately, there's Pumphouse. Pumphouse enables you to migrate virtual servers from a legacy OpenStack cloud to a running Icehouse installation, preserving the runtime parameters and metadata of those virtual servers as much as possible, without having to duplicate your entire hardware setup.  

 

 

In this session, I plan to explain use cases we ve been trying to solve, describe the migration strategy and migration paths we ve implemented, and give an overview of major limitations and requirements of our approach. I will also give a live(ly) demo of how the application works. We'll also look at the complementary tools required to make the deployment production ready.

There are all sorts of ways to stand-up an OpenStack environment on your workstation but I have seen very few ways to stand-up just an OpenStack Swift cluster.

If there are tools available, they stand-up an all-in-one environment that is not representative of an actual OpenStack Swift cluster.

In this talk, I am going to stand-up a stand-alone, multi-node OpenStack Swift cluster and go through how to use it with the swift command line tools.


There are all sorts of ways to stand-up an OpenStack environment on your workstation but I have seen very few ways to stand-up just an OpenStack Swift cluster.

If there are tools available, they stand-up an all-in-one cluster that is not representative of an actual OpenStack Swift cluster.

In this talk, I am going to stand-up a stand-alone, multi-node OpenStack Swift cluster and go through how to use it with the swift command line tools.