OpenStack Mitaka Design Summit

With the ever increasing adoption of Openstack in Enterprises and transforming from Sandbox research projects into viable Product Grade deployments the ask for architecting the deployments properly is fast becoming a necessity. This session would would walk through all the required tasks to be considered by an Openstack Architect while designing an Enterprise Openstack Cloud .

Openstack Design and Architecture :
Process of Designing and Planning a Minimum Viable Platform to start off an Openstack Architecture. A Cloud Discovery Workshop Template used by the Red Hat Cloud Practice will be discussed. This session helps prepare the architecture team and customers to collaborate on the solution architecture. Some topics to be considered for Openstack Architecture Design Solution Architectures based on Cloud Discovery Worksop .

Openstack Base Deployment :
         Control Plane Recommendations .
         Compute Recommendations .
         Networking Recommendations .
         Failure Domain Recommendations .
         Availability Recommendations

Openstack Services - Deploying and Extending OpenStack Core Services:
 The core components will be covered in addition to tech preview components. . Horizon . Keystone . Nova . Neutron . Cinder . AMQP . Glance . Heat . Swift . Ceilometer . Sahara . Trove . Tempest . Rally

Operating and Managing Openstack:
We will dive into how to operate and manage an OpenStack cloud. . Ceilometer . Nagios or other Montoring Tools . Database Patching . OS Patching . Maintenance Tasks . Hypervisor Maintenance . Controller Maintenance

"Rule The Stack" is a community competition held at the Summit that challenges OpenStack wizards to build a complete OpenStack infrastructure with compute, storage, and networking. Participants compete on speed, accuracy and sophistication of their deployment.

In this session, the winners of the previous 3 Rule the Stack competitions will reveal the tips and tricks they used to reliably provision OpenStack in just minutes. Learn how these techniques extend beyond the competition and can be adapted to be used in your own data center.  If you are interested in trying your hand in this year's competition, we will provide a USB key for you to give it a shot.

Think you have what it takes to "Rule the Stack"?  Join us to learn from past champions and discuss new tricks!

We had presented our cloud design at OpenStack Paris Summit (http://bit.ly/1DbJPUO) and started the operation after the conference. In this talk, we are going to share some important lessons and processes learned after the one year of OpenStack operation. This talk will help people who just want to start OpenStack operation or think of an operation by a small number of people.

1.   Team Building
It is essential to organize DevOps team to keep up with an active OpenStack development. We created DevOps team from scratch. We share the process of the team building and each member's skill doing DevOps.

2.   Monitoring System
Monitoring is important to keep the system stable. We share items we are currently monitoring (about 60,000 items) and show some important items to prevent service disruption. Alos, we share some custom scripts for OpenStack health check (e.g. RabbitMQ, MySQL and OpenStack services).

3.   Log Analytics
Logs (e.g. OpenStack debug log, Syslog, Auth log and Operation log) give you very important information and we can find potential problems/risks by analyzing those logs. We are getting more than 40GB logs a day and it is difficult to find important information among them. We demonstrate our Elasticsearch based log analytics/visualization tool to sort out useful information.

4.   Continuous Integration
Once you start a cloud service, it is difficult to stop the service though there are many necessary updates. We have updated the environment more than 100 times without downtime. We demonstrate Neutron Agent update that is one of the most difficult part of current OpenStack. We also share CI/CD tools and own tools used for system validation after updates.

5.   Daily Operation
We share our daily works.

1. Tools help you to monitor the system efficiently 


2. Tools help you to check security alert 


3. Issue tracking and management 


4. Tools and procedures used for emergency operation (remote operation tools)

Thanks to the community, it becomes easier to deploy OpenStack by many tools(e.g. Juju, RDO and Fuel); however, there is still less information about keep running/updating OpenStack without downtime. We are going to share our experiences and own tools developed through the private cloud operation. Also, we share future challenges to make OpenStack operation more efficient. Today, there are still some manual operations but our goal is to help OpenStack operators sleep better by automating most of the operations.

Your OpenStack cloud has been deployed on a Long Term Service release such as Ubuntu 14.04 using the Icehouse release. Now that Icehouse is out of support from core OpenStack developers and moved into the hands of the Distros its time to start planning the move from Icehouse to Kilo, Juno, Liberty or beyond. Upgrading a live cloud is no trivial task and this talk aims to walk you through the dos, don'ts, and how tos for planning and implementing your cloud upgrade.

Automated deployment has become an important differentiator for OpenStack based products. This presentation highlights similarities and differences, across several OpenStack vendors.

To automate deployment is an absolute necessity in running an OpenStack environment, but which approach should you choose? Some vendors want you to deploy with Puppet, others with Chef, still others with Juju. Some major public OpenStack providers manage their infrastructure with Ansible or Ironic. In this presentation, you'll learn about a variety of automated deployment approaches for OpenStack and their pros and cons.

We will be covering the RHEL OSP Director (TripleO), SUSE Cloud (Chef/Crowbar), Ubuntu OpenStack (Juju), and Rackspace (Ansible).

High availability of the cloud and applications is a requirement for enterprises. There are three fundamental levels at which “high availability” (HA) can be provided in an Openstack-based cloud:

• Controller and core-services level


• Virtual machine (VM) level


• Application level

In this talk, join engineers from ZeroStack Inc. as we take a deep-dive into clustering, high availability of services and VMs. Based on our experience with building and deploying a highly-reliable, scale on demand Openstack based private cloud solution, we provide a case study with design insights, lessons learned and best practices.

In the first part of this talk, we describe and demonstrate how various services that constitute an Openstack controller can be created and managed in a highly available way to provide Reliable Openstack:

• Stateless services: Nova, Neutron, Cinder, Glance, Keystone, Heat


• Stateful services: MySQL, Message queues

In the second part of the talk, we switch gears to talk about high-availability at the VM-level. In the basic case, we discuss how Openstack notifications can be used to detect  faults of compute instances in order to restart them. In the more advanced context of a remote controller, connectivity cannot be used as a proxy for liveness - we discuss how VM-level HA can be still be achieved to run applications reliably.

Finally, in the third part of our talk, we explain how high availability may be achieved at the application level in Openstack-based clouds. Modern applications are increasingly designed in a distributed manner to survive failures of individual nodes. In addition, we explain how concepts of “affinity” and “anti-affinity” can be used along with the notion of host-aggregates to provide tolerance to failures.

Designing a Private OpenStack cloud is complex. It can take months of design and test effort to optimize the hardware and software components. What hardware configuration works best for your management/control plane? What is the “best” hardware configuration for a given workload? What workloads will you initially run (e.g., low latency, compute intensive, high transaction, etc.)? Do you know what workloads will be running in your cloud three months after deployment?

This presentation will cover best practices gleaned across server and services teams as well as the HP Helion Public Cloud in designing and running hardware stacks in OpenStack clouds.  It will explore the best practices and set-ups for control planes optimized for the different OpenStack services, compute configurations that factor in key workload considerations, and the storage and networking architectures that make a difference in how your cloud will handle data when using object and block storage.

The Openstack cookbook project(s) have been growing rapidly and becoming more mature and stable with every release.

These cookbooks provide a way to not only deploy, but also manage the OpenStack service configurations. 

This session will explore the current state of the OpenStack cookbook projects and allow you to better understand the following topics:
- What is Chef and why is it such a great match for OpenStack?
- What is the current state of the OpenStack Chef cookbook community?
- How to I get starting using the cookbooks?
- What are the strengths and weaknesses of the cookbooks?
- Tips and techniques for using the cookbooks

Size your OpenStack environment is not an easy task.

In this session we will cover how to size your controller nodes to host all your OpenStack services as well as Ceph nodes and Overcommit CPU and Memory based on real use cases and experiences.

VMs? Containers? Baremetal? How do I scale? We will cover diferent approaches to do the sizing and we will also talk about the most bottlenecks that you might find while deploying an OpenStack cloud.

Swift and Ceph are both very popular distributed and flexible storage systems providing object storage based on commodity hardware. However, they are very different. This presentation will provide a comprehensive comparison of Swift and Ceph. We will study some real-world object storage requirements and show some test results of both Swift and Ceph based on modeling of real-world scenarios. We will also discuss the pros and cons of building a object storage system with Swift and Ceph, not only the performance and features, but also the cost of constructing and operating such storage systems. We will take the "unified storage" feature of Ceph into account, which may save the cost if the user also want a distributed block storage system and file system.