OpenStack Liberty Design Summit

This is a presentation aimed at a DevOps or Developer in an IT organization and presents an in depth exploration of MySQL replication with Trove and Kilo capabilities.

The presentation provides a brief overview of the Trove architecture, and will then explore different configuration options for replication and touch on the different kinds of replication that Trove supports.  It will explain how to create and manage a replicated MySQL instance(s) in Trove.  First it will summarize v1 replication capabilities released in Juno, explaining read-only slave replication for MySQL.  Next, it will provide an update on v2 replication releasing in Kilo and new capabilities for MySQL replication, including global transaction identifier (GTID) based replication failover.  It will explain how GTID works in Trove and how users will benefit from it.  Lastly, it will provide visibility to upcoming features related to MySQL replication and what users can look forward to in releases after Kilo.

Overall, this presentation will help the participant understand how to configure, operate and troubleshoot MySQL replication with OpenStack Trove in Kilo.

 

Speakers: Amrith Kumar (Tesora), George Lorch (Percona)

 

OpenStack, Docker, and Cloud Foundry are the three most popular open source projects according to a recent cloud software survey. Docker has taken the cloud world by storm as a revolutionary way to not only run isolated application containers, but also to package them. But how does Docker fit into the paradigm of IaaS and PaaS? More specifically, how does it integrate with OpenStack and Cloud Foundry, the world's most popular infrastructure and platform service implementations?   

In this talk we will: 
1. Talk about the changes happening in the Cloud Foundry and OpenStack code bases to better integrate with Docker, and each other. 
2. Discuss the rewrite of the Cloud Foundry application runtime (Diego) to support applications deployed in Docker containers. 
3. Show how we can leverage BOSH to deploy this converged platform on OpenStack. 
4. Describe the service broker architecture used to plug a Docker container service into Cloud Foundry, and how we implemented it for the IBM PaaS offering, IBM Bluemix. 
5. Dive deep into how we use another OpenStack service, Swift object storage, in our Cloud Foundry-based PaaS platform as well. 
6. Give recommendations on ideal architectures for deploying Dockerized applications on OpenStack and Cloud Foundry. 

Come join us at this session to understand how the three leading open source cloud technologies are evolving to work together to support next generation workloads!

For more than a year, Ceph has become increasingly popular and saw several deployments inside and outside OpenStack. The community and Ceph itself has greatly matured.

Ceph is a fully open source distributed object store, network block device, and file system designed for reliability, performance, and scalability from terabytes to exabytes. Ceph utilizes a novel placement algorithm (CRUSH), active storage nodes, and peer-to-peer gossip protocols to avoid the scalability and reliability problems associated with centralized controllers and lookup tables.

The community has been really active integrating Ceph into OpenStack. This is getting better every releases.

With Juno we reached a critical step in terms of feature, robustness and stability. Kilo is really promising but we are not done yet.

In this session, Sebastien Han and Josh Durgin from Red Hat will describe the current state of the integration of Ceph into OpenStack and where are we heading to in term of roadmap. They will go through all the OpenStack project.

In this talk, Kyle Mestrey (Neutron PTL), Colin Dixon (OpenDaylight Technical Steering Committee Chair) and Chris Wright (Red Hat Director of Networking) will discuss the past, present and future of the relationship between OpenStack and OpenDaylight.

If OpenStack has an obvious open source "sister-project" in the networking space, it's OpenDaylight. Like OpenStack, OpenDaylight is a large, community-driven open source project backed by a consortium of companies and individuals with no single dominant player. This makes OpenDaylight an obvious choice for a an OpenStack Neutron provider. Unsurprisingly, OpenDaylight has a Neutron plugin and we are working to improve it to better meet both communities' needs. We'll cover the current OpenDaylight support for OpenStack Neutron, give a quick demo, present our future plans, and (most importantly) ask for feedback about where we should be focusing our efforts.

This presentation will show a new approach to deploying OpenStack within containers. This approach results in new composable building blocks to deploy OpenStack. The work shown in this presentation is based upon the Kolla project. 

With a single node OpenStack deployment the audience will learn how to deploy the main OpenStack services using Docker containers. The benefits and drawbacks of this containerized approach with respect to developing and deploying OpenStack will be discussed. The ability to simultaneously deploy services from different OpenStack versions, enable deployment of a mix of both package and source based services will be described, as will the speed advantages of deploying services via containers versus other tools such as packstack. 

The presenter will conclude with demonstrating the Kolla system including individual atomic upgrades of a nova-compute libvirt container, while under live use.

Vagrant by HashiCorp is a powerful open source tool to maintain and build reproducible development environments by integrating configuration management software like Ansible, Puppet, or Chef.

It does not matter if you want to build simple single throw away machine to play around with a new software or to build complex multi machine long running environments used as staging environment, to prepare migrations, or to run performance measurements, with Vagrant it is possible to build environments of every scale.

With a plugin it is possible to boostrap Vagrant environments on top of OpenStack based clouds. In this session we show you where and how you can start, how to deploy on a OpenStack based cloud, how to build a multi machine environment, and finish with a full blown OpenStack development environment using Packstack on top of a OpenStack public cloud.

The showed examples in this session will be published on Github.

Freezer is a Backup as a Service platform for Openstack cloud instances.

It provides a Web UI panel in Horizon, API endpoints to store meta data and backup configurations.

 

The client component saves you time and money by executing efficiently data backup and restore leveraging Swift Storage.

 

 

It supports Windows and Linux and perform incremental encrypted backup, achieving high integrity and consistency for even the main data base technologies (i.e. MySQL, MongoDB, ElasticSearch, MSSQL).

 

Freezer provides unique features, like encrypting and segmenting your data and upload segments on different cloud providers.

 

 

 

Diskimage-builder (DIB) is an awesome method for creating guest images for both metal and vm use.

DIB is generally considered part of TripleO, but it can be used for any style cloud that would benefit from automated, repeatable, formula driven guest images.

In this presentation, I would like to demonstrate some of the basics of getting started with DIB, and how to create your own custom elements, and how to contribute to the project upstream. I will also demonstrate image building images with DIB and assertion testing of images.

 

Introducing Magnum a multi-tenant Containers-as-a-Service designed for OpenStack that combines OpenStack, Docker, Kubernetes, and Flannel to produce a containers solution that works like other OpenStack services. In this session, we will detail and demonstrate Magnum to show you the features and capabilities, as well as an overview of the software architecture that allows for extending it.

MariaDB Galera cluster is a synchronous multi-master cluster with many intriguing features like synchronous replication, active-active multi-master topology, automatic node provisioning, etc. This presentation will cover many of the best practices including pitfalls that Database Administrators and DevOps must keep in mind while managing the MariaDB Galera cluster.

Several key open source projects have emerged in the virtualization space in the past few years -- OpenDaylight, OpenStack, Open vSwitch, OPNFV -- and the communities have been working together to integrate their respective pieces. Panelists represent each of these projects and discuss how they collaborate to enable a network-based cloud. Colin Dixon, OpenDaylight; David Lenrow, OpenStack; Justin Pettit, Open vSwitch; Chris Price, OPNFV. Moderator: Phil Robb, OpenDaylight.

OpenStack components have finally matured to the point where we can build Big Data projects under one framework.

This session will exlore the foundational elements needed to deploy meaningful, long lived Hadoop clusters on bare metal via OpenStack APIs.  In the past, Hadoop use cases were largely limited to deployments on virtual machines. With the introduction of OpenStack Data Processing (Sahara) and OpenStack (Ironic) we can begin to explore having the best of both worlds.

It’s no news that containers represent a portable unit of deployment, and OpenStack has proven an ideal environment for running container workloads.  However, where it usually becomes more complex is that many times an application is often built out of multiple containers. What’s more, setting up a cluster of container images can be fairly cumbersome because you need to make one container aware of another and expose intimate details that are required for them to communicate which is not trivial especially if they’re not on the same host.


 

These scenarios have instigated the demand for some kind of orchestrator.  The list of container orchestrators is growing fairly fast.  This session will compare the different orchestation projects out there - from Heat to Kubernetes to TOSCA - and help you choose the right tool for the job.

Openstack provides a really good and robust infrastructure as a service however doing Platform as a Service is the next challenge on the cloud architecture.

Apache Mesos is a highly available resource management software for datacenters which can run on top of any cloud, physical server or container. 

Google Kubernetes is a cluster containter management system which allows you to control and deploy large clusters of containers. 

Using any of them (separated or in conjunction), you can deploy a highly available Platform as a Service allowing our users to deploy highly available stacks within minutes.

 

In this talk we will cover topics such as:

• Architecture (Openstack - Kubernetes - Mesos)


• Managing your pool of Containers 


• Managing your pool of Resources


• High availability


• Designing your Platform services


• Security


• Rolling out new services

 

 

Storage is one of the critical parts of any cloud environment. It should be easy to provision, fully accessible and reliable as possible, the question is how do you do it without going out of pocket?

The Answer is to use commodity hardware with Open Source software to turn it into an affordable distributed network storage.

LINBIT bases its work in this area on the existing DRBD software, which got included into the upstream Linux kernel as of version 2.6.33 (released 2010). DRBD has a proven track record and many deployments in high available systems on all major Linux distributions.

In order to address the Scale out needs and cover Disaster Recovery setups, a new major release of DRBD was developed: DRBD 9. Together with a new feature-rich core, a new management tool, called ´drbdmanage´, has been developed to facilitate storage cluster management by tightly integrating local storage (LVM) and management of the data replication (DRBD) across all nodes part of the storage pool. On top of this there is a cinder driver that binds the whole stack to the OpenStack world.

This stack can now deliver a reliable block storage with high-end IOPs and a complete integration into OpenStack. It can either use regular TCP/IP or RDMA, conventional spinning hard disks or high-speed SSDs, synchronous or asynchronous replication, works for local (within a data center) as for remote (disaster recovery) replication. Due to the high performance this stack delivers it is very well suited for database workloads (structured data) and workloads that require a conventional file system on a block device. This should not be confused with an object storage.

One of the great Container advances in 2014 was the advent of Docker.  However, many people still don't realise that Docker itself is really a Container application i.e. a consumer of containers technology rather than a provider of it (the containers currently used by Docker are provided by the Linux Kernel).  This confusion comes about because Docker is really the first application in history to take advantage of containers for application compact packaging and transport in a manner that simply cannot be easily replicated with hypervisor technology.  However, successful as it is, Docker merely represents the first real Containerized application and necessarily begs the question "what other containerized applications might there be in the future and how do we produce them?"

In order to answer the first part of the question, we will explore some potential uses of containers to yield things such as easy multi-tenancy for any application and also look at how NFV can be more easily done by containers using Firewall as a Service as an example.  To answer the second half, we will introduce and describe libcontainer.  Back at the end of 2013, both Parallels and Docker were working on container libraries with a view to supporting the creation of novel container applications.  Parallels did so because as a supplier of container technoloy it saw its future tied to separating containers from hypervisors and Docker did so to try to untie itself from the LXC container orchestration system.  Both projects discovered each other in April 2014 and agreed to a formal merger in June.  That merger is now nearing completion within the libcontainer repository and we will describe the resulting API and what this means both in terms of container orchestration systems (who are the first natural users) and for applications wishing to take advantage of container properties.

People attending this session will gain an idea of some of the alternative uses of containers, how to add containers to their application, and what the current state of the libcontainer API is and how it may be extended in the future.

My name is David Vossel. I’m a core developer of the Pacemaker project and author of Pacemaker Remote. I want to share our success with scaling the Pacemaker cluster resource manager to meet the requirements necessary automate recovery of OpenStack controller and compute nodes.

OpenStack’s architecture consists of a set of distributed components capable of scaling horizontally across 100s and even 1000s of nodes. By introducing Pacemaker we are essentially giving the cluster the equivalent of a PID 1, a distributed init system capable of reliably monitoring and recovering all the OpenStack components across the entire cluster.

At this point those of you with previous High Availability experience might be scratching your head in confusion, and rightfully so. Traditionally High Performance Clusters and High Availability clusters have been mutually exclusive. From this standpoint the concept of a "PID 1" within a scalable system seems impractical, but times are changing. High Availability no longer means what it used to mean. Recent architecture improvements to Pacemaker’s ability to scale have brought these two cluster concepts into the same space. As a result, we now have a cluster resource manager capable of managing OpenStack at scale. Now what was previously thought to be impractical is quickly becoming an essential element in what will drive the long term success of OpenStack.

OpenStack projects provide rich APIs with which operators and developers can write tooling to manage OpenStack resources. Every project has its own client, and there are a number of SDKs built around the APIs. However, the only official libraries are written in Python, leaving those of us who must develop in an alternate language to choose from unofficial libraries of varying quality, upkeep, and feature implementation. Compare that to Amazon, which offers official SDKs for most major languages, guaranteed to keep up with changing APIs and new features.


The StackForge puppet modules contain Ruby plugins, known idiomatically as “types and providers”, which need to interact with the OpenStack APIs in order to automate OpenStack deployments. Originally these were written by essentially shelling out to the respective command-line client for the service being managed. For a number of reasons, this approach became unsatisfactory, and we needed to choose an alternative. That decision became a choice between a limited number of imperfect options. This talk, aimed at developers and operators, will tell the story of the motivating factors behind the change to our provider backend, what options were available to us, and the various requirements that led to our ultimate design decision. The presentation will focus on the issues faced in the puppet modules, but the ideas extend to other third party software. This will be an opportunity for developers and operators to discuss their experiences with writing tooling around the OpenStack APIs.