Voting Open for OpenStack Summit Tokyo Submissions: Container deployment, management, security and operations – oh my!

This week we have been providing a preview of Red Hat submissions for the upcoming OpenStack Summit to be held October 27-30, in Tokyo, Japan. Today’s grab bag of submissions focus on containers the relationship between them and OpenStack as well as how to deploy, manage, secure, and operate workloads using them. This was already a hotbed of new ideas and discussion at the last summit in Vancouver and we expect things will only continue to heat up in this area as a result of recent announcements in the lead up to Tokyo!

The OpenStack Foundation manages allows its members to vote the topics and presentations they would like to see as part of the selection process. To vote for one of the listed sessions, click on the session title below and you will be directed to the voting page. If you are a member of the OpenStack Foundation, just login. If you are not, you are welcome to join now – it is simple and free.

Please make sure to vote before the deadline on Thursday, July 30 2015, at 11:59pm PDT.

Application & infrastructure continuous delivery using OpenShift and OpenStack
  • Mike McGrath – Senior Principal Architect, Atomic @ Red Hat
Atomic Enterprise on OpenStack
  • Jonathon Jozwiak – Principal Software Engineer @ Red Hat
Containers versus Virtualization: The New Cold War?
  • Jeremy Eder – Principal Performance Engineer @ Red Hat
Container security: Do containers actually contain? Should you care?
  • Dan Walsh – Senior Principal Software Engineer @ Red Hat
Container Security at Scale
  • Scott McCarty – Product Manager, Container Strategy @ Red Hat
Containers, Kubernetes, and GlusterFS, a match made in Tengoku
  • Luis Pabón – Principal Software Engineer @ Red Hat
  • Stephen Watt – Chief Architect, Big Data @ Red Hat
  • Jeff Vance – Principal Software Engineer @ Red Hat
Converged Storage in hybrid VM and Container deployments using Docker, Kubernetes, Atomic and OpenShift
  • Stephen Watt – Chief Architect, Big Data @ Red Hat
Deploying and Managing OpenShift on OpenStack with Ansible and Heat
  • Diane Mueller – Director Community Development, OpenShift @ Red Hat
  • Greg DeKoenigsberg –  Vice President, Community @ Ansible
  • Veer Michandi – Senior Solution Architect @ Red Hat
  • Ken Thompson – Senior Cloud Solution Architect @ Red Hat
  • Tomas Sedovic – Senior Software Engineer @ Red Hat
Deploying containerized applications across the Open Hybrid Cloud using Docker and the Nulecule spec
  • Tushar Katarki – Integration Architect @ Red Hat
  • Aaron Weitekamp – Senior Software Engineer @ Red Hat
Deploying Docker and Kubernetes with Heat and Atomic
  • Steve Gordon – Senior Technical Product Manager, OpenStack @ Red Hat
Develop, Deploy, and Manage Applications at Scale on an OpenStack based private cloud
  • James Labocki – Product Owner, CloudForms @ Red Hat
  • Brett Thurber – Principal Software Engineer @ Red Hat
  • Scott Collier – Senior Principal Software Engineer @ Red Hat
How to Train Your Admin
  • Aleksandr Brezhnev – Senior Principal Solution Architect @ Red Hat
  • Patrick Rutledge – Principal Solution Architect @ Red Hat
Minimizing or eliminating service outages via robust application life-cycle management with container technologies
  • Tushar Katarki – Integration Architect @ Red Hat
  • Aaron Weitekamp – Senior Software Engineer @ Red Hat
OpenStack and Containers Advanced Management
  • Federico Simoncelli – Principal Software Engineer @ Red Hat
OpenStack & The Future of the Containerized OS
  • Daniel Riek – Senior Director, Systems Design & Engineering @ Red Hat
Operating Enterprise Applications in Docker Containers with Kubernetes and Atomic Enterprise
  • Mike McGrath – Senior Principal Architect, Atomic @ Red Hat
Present & Future-proofing your datacenter with SDS & OpenStack Manila
  • Luis Pabón – Principal Software Engineer @ Red Hat
  • Sean Murphy – Product Manager, Red Hat Storage @ Red Hat
  • Sean Cohen – Principal Product Manager, OpenStack @ Red Hat
Scale or Fail – Scaling applications with Docker, Kubernetes, OpenShift, and OpenStack
  • Grant Shipley – Senior Manager @ Red Hat
  • Diane Mueller – Director Community Development, OpenShift @ Red Hat

Thanks for taking the time to help shape the next OpenStack summit!

Voting Open for OpenStack Summit Tokyo Submissions: Deployment, management and metering/monitoring

Another cycle, another OpenStack Summit, this time on October 27-30 in Tokyo. The Summit is the best opportunity for the community to gather and share knowledge, stories and strategies to move OpenStack forward. With more than 200 breakout sessions, hands-on workshops, collaborative design sessions, tons of opportunity for networking and perhaps even some sightseeing, the Summit is the even everyone working or planning to work with OpenStack should attend.

Critical subjects, awesome sessions

To select those 200+ sessions the community proposes talks that are selected by your vote, and we would like to showcase our proposed sessions about some of the most critical subjects of an OpenStack cloud: deployment, management and metering/monitoring.

There are multiple ways to deploy, manage and monitor clouds, but we would like to present our contributions to the topic, sharing both code and vision to tackle this subject now and in the future. With sessions about TripleO, Heat, Ironic, Puppet, Ceilometer, Gnocchi and troubleshooting, we’ll cover the whole lifecycle of OpenStack, from planning a deployment, to actually executing and then monitoring and maintaining it on the long term. Click on the links below to read the abstracts and vote your the topics you want to see in Tokyo.

Deployment and Management

OpenStack on OpenStack (TripleO): First They Ignore You..
  • Dan Sneddon – Principal OpenStack Engineer @ Red Hat
  • Keith Basil – Principal Product Manager, OpenStack Platform @ Red Hat
  • Dan Prince – Principal Software Engineer @ Red Hat
Installers are dead, deploying our bits is a continuous process
  • Nick Barcet – Director of OpenStack Product Management @ Red Hat
  • Keith Basil – Principal Product Manager, OpenStack Platform @ Red Hat
TripleO: Beyond the Basic Openstack Deployment
  • Steven Hillman – Software Engineer @ Cisco Systems
  • Shiva Prasad Rao – Software Engineer @ Cisco Systems
  • Sourabh Patwardhan – Technical Leader @ Cisco Systems
  • Saksham Varma – Software Engineer @ Cisco Systems
  • Jason Dobies – Principal Software Engineer @ Red Hat
  • Mike Burns – Senior Software Engineer @ Red Hat
  • Mike Orazi – Manager, Software Engineering @ Red Hat
  • John Trowbridge – Software Engineer, Red Hat @ Red Hat
Troubleshoot Your Next Open Source Deployment
  • Lysander David – IT Infrastructure Architect @ Symantec
Advantages and Challenges of Deploying OpenStack with Puppet
  • Colleen Murphy – Cloud Software Engineer @ HP
  • Emilien Macchi – Senior Software Engineer @ Red Hat
Cloud Automation: Deploying and Managing OpenStack with Heat
  • Snehangshu Karmakar – Cloud Curriculum Manager @ Red Hat
Hands-on lab: Deploying Red Hat Enterprise Linux OpenStack Platform
  • Adolfo Vazquez – Curriculum Manager @ Red Hat
TripleO and Heat for Operators: Bringing the values of Openstack to Openstack Management
  • Graeme Gillies – Principal Systems Administrator @ Red Hat
The omniscient cloud: How to know all the things with bare-metal inspection for Ironic
  • Dmitry Tantsur – Software Engineer @ Red Hat
  • John Trowbridge – Software Engineer @ Red Hat
Troubleshooting A Highly Available Openstack Deployment.
  • Sadique Puthen – Principal Technical Support Engineer @ Red Hat
Tuning HA OpenStack Deployments to Maximize Hardware Capabilities
  • Vinny Valdez – Sr. Principal Cloud Architect @ Red Hat
  • Ryan O’Hara – Principal Software Engineer @ Red Hat
  • Dan Radez – Sr. Software Engineer @ Red Hat
OpenStack for Architects
  • Michael Solberg – Chief Field Architect @ Red Hat
  • Brent Holden – Chief Field Architect @ Red Hat
A Day in the Life of an Openstack & Cloud Architect
  • Vijay Chebolu – Practice Lead @ Red Hat
  • Vinny Valdez – Sr. Principal Cloud Architect @ Red Hat
Cinder Always On! Reliability and scalability – Liberty and beyond
  • Michał Dulko – Software Engineer @ Intel
  • Szymon Wróblewski – Software Engineer @ Intel
  • Gorka Eguileor – Senior Software Engineer @ Red Hat

Metering and Monitoring

Storing metrics at scale with Gnocchi, triggering with Aodh
  • Julien Danjou – Principal Software Engineer @ Red Hat

Voting Open for OpenStack Summit Tokyo Submissions: Storage Spotlight

The OpenStack Summit will take place on October 27-30 in Tokyo, will be a five-day conference for OpenStack contributors, enterprise users, service providers, application developers and ecosystem members.  Attendees can expect visionary keynote speakers, 200+ breakout sessions, hands-on workshops, collaborative design sessions and lots of networking. In keeping with the Open-Source spirit, you are in the front seat to cast your vote for the sessions that are important to you!

Today we will take a peak at some recommended storage related session proposals for the Tokyo summit, be sure to vote for your favorites! To vote, click on the session title below and you will be directed to the voting page. If you are a member of the OpenStack Foundation, just login. If you are not, you are welcome to join now – it is simple and free.

Please make sure to vote before the deadline on Thursday, July 30 2015, at 11:59pm PDT.

Block Storage

OpenStack Storage State of the Union
  • Sean Cohen, Principal Product Manager @ Red Hat
  • Flavio Percoco, Senior Software Engineer @ Red Hat
  • Jon Bernard ,Senior Software Engineer @ Red Hat
Ceph and OpenStack: current integration and roadmap
  • Josh Durgin, Senior Software Engineer @ Red Hat
  • Sébastien Han, Senior Cloud Architect @ Red Hat
State of Multi-Site Storage in OpenStack
  • Sean Cohen, Principal Product Manager @ Red Hat
  • Neil Levine, Director of Product Management @ Red Hat
  • Sébastien Han, Senior Cloud Architect @ Red Hat
Block Storage Replication with Cinder
  • John Griffith, Principal Software Engineer @ SolidFire
  • Ed Balduf, Cloud Architect @ SolidFire
Sleep Easy with Automated Cinder Volume Backup
  • Lin Yang, Senior Software Engineer @ Intel
  • Lisa Li Software, Engineer @ Intel
  • Yuting Wu, Engineer @ Awcloud
Flash Storage and Faster Networking Accelerate Ceph Performance
  • John Kim, Director of Storage Marketing @ Mellanox Technologies
  • Ross Turk, Director of Product Marketing @ Red Hat Storage

File Storage

Manila – An Update from Liberty
  • Sean Cohen, Principal Product Manager @ Red Hat
  • Akshai Parthasarathy Technical Marketing Engineer @ NetApp
  • Thomas Bechtold, OpenStack Cloud Engineer @ SUSE
Manila and Sahara: Crossing the Desert to the Big Data Oasis
  • Ethan Gafford, Senior Software Engineer @ Red Hat
  • Jeff Applewhite, Technical Marketing Engineer, NetApp
  • Weiting Chen, Software Engineer @ Intel
GlusterFS making things awesome for Swift, Sahara, and Manila.
  • Luis Pabón, Principal Software Engineer @Red Hat
  • Thiago da Silva, Senior Software Engineer @ Red Hat
  • Trevor McKay, Senior Software Engineer @ Red Hat

Object Storage

Benchmarking OpenStack Swift
  • Thiago da Silva, Senior Software Engineer @ Red Hat
  • Christian Schwede, Principal Software Engineer @ Red Hat
Truly durable backups with OpenStack Swift
  • Christian Schwede, Principal Software Engineer @ Red Hat
Encrypting Data at Rest: Let’s Explore the Missing Piece of the Puzzle
  • Dave McCowan, Technical Leader, OpenStack @ Cisco
  • Arvind Tiwari, Technical Leader @ Cisco

 

DevOps, Continuous Integration, and Continuous Delivery

As we all turn our eyes towards Tokyo for the next OpenStack Summit edition the time has come to make your voice heard as to which talks you would like to attend while you are there. Remember, even if you are not attending the live event many sessions get recorded and can be viewed later so make your voice heard and influence the content!

Let me suggest a couple talks under the theme of DevOps, Continuous Integration, and Continuous Delivery – remember to vote for your favorites by midnight Pacific Standard Time on July 30th and we will see you in Tokyo!

Continuous Integration is an important topic, we can see this through   the amount of effort  deployed by the OpenStack CI team. OpenStack deployments all over the globe cover a wide range of possibilities (NFV, Hosting, extra services, advanced data storage, etc). Most of them come with their technical specificities including hardware, uncommon configuration, network devices, etc.

This make these OpenStack installation unique and hard to test. If we want to properly make them fit in the CI process, we need new methodology and tooling.

Rapid innovation, changing business landscapes, and new IT demands force businesses to make changes quickly. The DevOps approach is a way to increase business agility through collaboration, communication, and integration across different teams in the IT organization.

In this talk we’ll give you an overview of a platform, called Software Factory, that we develop and use at Red Hat. It is an open source platform that is inspired by the OpenStack’s development’s workflow and embeds, among other tools, Gerrit, Zuul, and Jenkins. The platform can be easily installed on an OpenStack cloud thanks to Heat and can rely on OpenStack to perform CI/CD of your applications.

One of the best success stories to come out of OpenStack is the Infrastructure project. It encompasses all of the systems used in the day-to-day operation of the OpenStack project as a whole. More and more other projects and companies are seeing the value of the OpenStack git workflow model and are now running their own versions of OpenStack continuous integration (CI) infrastructure. In this session, you’ll learn the benefits of running your own CI project, how to accomplish it, and best practices for staying abreast of upstream changes.

In order to provide better quality while keeping up on the growing number of projects and features lead Red Hat to adapt it’s processes.  Moving from a 3 team process (Product Management, Engineering and QA) to a feature team approach each embedding all the actors of the delivery process was one of the approach we took and which we are progressively spreading.

We delivered a very large number of components that needs to be engineered together to deliver their full value, and which require delicate assembly as they work together as a distributed system. How can we do this is in in a time box without giving up on quality?

Learn how to get a Vagrant environment running as quickly as possible, so that you can start iterating on your project right away.

I’ll show you an upstream project called Oh-My-Vagrant that does the work and adds all the tweaks to glue different Vagrant providers together perfectly.

This talk will include live demos of building docker containers, orchestrating them with kubernetes, adding in some puppet, and all glued together with vagrant and oh-my-vagrant. Getting familiar with these technologies will help when you’re automating Openstack clusters.

In the age of service, core builds become a product in the software supply chain. Core builds shift from a highly customized stack which meets ISV software requirements to an image which provides a set of features. IT Organization shift to become product driven organizations.

This talk will dive into the necessary organizational changes and tool changes to provide a core build in the age of service and service contracts.

http://crunchtools.com/files/2015/07/Core-Builds-in-the-Age-of-Service.pdf

http://crunchtools.com/core-builds-service/

We will start with a really brief introduction of Openstack services we will use to build our app. We’ll cover all of the different ways you can control an OpenStack cloud: a web user interface, the command line interface, a software development kit (SDK), and the application programming interface (API).

After this brief introduction on the tools we are going to use in our hands on lab we’ll get our hands dirty and build a application that will make use of an OpenStack cloud.

This application will utilize a number of OpenStack services via an SDK to get its work done. The app will demonstrate how OpenStack services can be used as base to create a working application.

Voting Open for OpenStack Summit Tokyo Submissions: Networking, Telco, and NFV

The next OpenStack Summit is just around the corner, October 27-30, in Tokyo, Japan, and we would like your help shaping the agenda. The OpenStack Foundation manages voting by allowing its members to choose the topics and presentations they would like to see.

Virtual networking and software-defined networking (SDN) has become an increasingly exciting topic in recent years, and a great focus for us at Red Hat. It also lays the foundation for network functions virtualization (NFV) and the recent innovation in the telecommunication service providers space.

Here you can find networking and NFV related session proposals from Red Hat and our partners. To vote, click on the session title below and you will be directed to the voting page. If you are a member of the OpenStack Foundation, just login. If you are not, you are welcome to join now – it is simple and free.

Please make sure to vote before the deadline on Thursday, July 30 2015, at 11:59pm PDT.

OpenStack Networking (Neutron)

OpenStack Networking (Neutron) 101
  • Nir Yechiel – Senior Technical Product Manager @ Red Hat
Almost everything you need to know about provider networks
  • Sadique Puthen – Principal Technical Support Engineer @ Red Hat
Why does the lion’s share of time and effort goes to troubleshooting Neutron?
  • Sadique Puthen – Principal Technical Support Engineer @ Red Hat
Neutron Deep Dive – Hands On Lab
  • Rhys Oxenham – Principal Product Manager @ Red Hat
  • Vinny Valdez – Senior Principal Cloud Architect @ Red Hat
L3 HA, DVR, L2 Population… Oh My!
  • Assaf Muller – Senior Software Engineer @ Red Hat
  • Nir Yechiel – Senior Technical Product Manager @ Red Hat
QoS – a Neutron n00bie
  • Livnat Peer – Senior Engineering Manager @ Red Hat
  • Moshe Levi – Senior Software Engineer @ Mellanox
  • Irena Berezovsky – Senior Architect @ Midokura
Clusters, Routers, Agents and Networks: High Availability in Neutron
  • Florian Haas – Principal Consultant @ hastexo!
  • Livnat Peer – Senior Engineering Manager @ Red Hat
  • Adam Spiers – Senior Software Engineer @ SUSE

Deploying networking (TripleO)

TripleO Network Architecture Deep-Dive and What’s New
  • Dan Sneddon – Principal OpenStack Engineer @ Red Hat

Telco and NFV

Telco OpenStack Cloud Deployment with Red Hat and Big Switch
  • Paul Lancaster – Strategic Partner Development Manager @ Red Hat
  • Prashant Gandhi – VP Products & Strategy @ Big Switch
OpenStack NFV Cloud Edge Computing for One Cloud
  • Hyde Sugiyama – Senior Principal Technologist @ Red Hat
  • Timo Jokiaho – Senior Principal Technologist @ Red Hat
  • Zhang Xiao Guang – Cloud Project Manager @ China Mobile
Rethinking High Availability for Telcos in the new world of Network Functions Virtualization (NFV)
  • Jonathan Gershater – Senior Principal Product Marketing Manager @ Red Hat

Performance and accelerated data-plane

Adding low latency features in Openstack to address Cloud RAN Challenges
  • Sandro Mazziotta – Director NFV Product Management @ Red Hat
Driving in the fast lane: Enhancing OpenStack Instance Performance
  • Stephen Gordon – Senior Technical Product Manager @ Red Hat
  • Adrian Hoban – Principal Engineer, SDN/NFV Orchestration @ Intel
OpenStack at High Speed! Performance Analysis and Benchmarking
  • Roger Lopez – Principal Software Engineer @ Red Hat
  • Joe Talerico – Senior Performance Engineer @ Red Hat
Accelerate your cloud network with Open vSwitch (OVS) and the Data Plane Development Kit (DPDK)
  • Adrian Hoban – Principal Engineer, SDN/NFV Orchestration @ Intel
  • Seán Mooney  – Network Software Engineer @ Intel
  • Terry Wilson – Senior Software Engineer @ Red Hat

Voting Open for OpenStack Summit Tokyo Submissions: OpenStack for the Enterprise

In the lead up to OpenStack Summit Hong Kong, the last OpenStack Summit held in the Asia-Pacific region, Radhesh Balakrishnan – General Manager for OpenStack at Red Hat – defined this site as the place to follow us on our journey taking community projects to enterprise products and solutions.

We are excited to now be preparing to head back to the Asia-Pacific region for OpenStack Summit Tokyo – October 27-30 – to share just how far we have come on that journey with host of session proposals focussing on enterprise requirements and the success of OpenStack in this space. The OpenStack Foundation manages voting by allowing its members to choose the topics and presentations they would like to see.

To vote, click on the session title below and you will be directed to the voting page. If you are a member of the OpenStack Foundation, just login. If you are not, you are welcome to join now – it is simple and free.

Vote for your favorites by midnight Pacific Standard Time on July 30th and we will see you in Tokyo!

Is OpenStack ready for the enterprise? Is the enterprise ready for OpenStack?

Can I use OpenStack to build an enterprise cloud?
  • Alessandro Perilli – General Manager, Cloud Management Strategies @ Red Hat
Elephant in the Room: What’s the TCO for an OpenStack cloud?
  • Massimo Ferrari – Director, Cloud Management Strategy @ Red Hat
  • Erich Morisse – Director, Cloud Management Strategy @ Red Hat
The Journey to Enterprise Primetime
  • Arkady Kanevsky – Director of Development @ Dell
  • Das Kamhout – Principal Engineer @ Intel
  • Fabio Di Nitto – Manager, Software Engineering @ Red Hat
  • Nick Barcet – Director of OpenStack Product Management @ Red Hat
Organizing IT to Deliver OpenStack
  • Brent Holden – Chief Cloud Architect @ Red Hat
  • Michael Solberg – Chief Field Architect @ Red Hat
How Customers use OpenStack to deliver Business Applications
  • Matthias Pfützner – Cloud Solution Architect @ Red Hat
Stop thinking traditional infrastructure – Think Cloud! A recipe to build a successful cloud environment
  • Laurent Domb – Cloud Solution Architect @ Red Hat
  • Narendra Narang – Cloud Storage Solution Architect @ Red Hat
Breaking the OpenStack Dream – OpenStack deployments with business goals in mind
  • Laurent Domb – Cloud Solution Architect @ Red Hat
  • Narendra Narang – Cloud Storage Solution Architect @ Red Hat

Enterprise Success Stories

OpenStack for robust and reliable enterprise private cloud: An analysis of current capabilities, gaps, and how they can be addressed.
  • Tushar Katarki – Integration Architect @ Red Hat
  • Rama Nishtala – Architect @ Cisco
  • Nick Gerasimatos – Senior Director of Cloud Services – Engineering @ FICO
  • Das Kamhout – Principal Engineer @ Intel
Verizon’s NFV Learnings
  • Bowen Ross – Global Account Manager @ Red Hat
  • David Harris – Manager, Network Element Evolution Planning @ Verizon
Cloud automation with Red Hat CloudForms: Migrating 1000+ servers from VMWare to OpenStack
  • Lan Chen – Senior Consultant @ Red Hat
  • Bill Helgeson – Principal Domain Architect @ Red Hat
  • Shawn Lower – Enterprise Architect @ Red Hat

Solutions for the Enterprise

RHCI: A comprehensive Solution for Private IaaS Clouds
  • Todd Sanders – Director of Engineering @ Red Hat
  • Jason Rist – Senior Software Engineer @ Red Hat
  • John Matthews – Senior Software Engineer @ Red Hat
  • Tzu-Mainn Chen – Senior Software Engineer @ Red Hat
Cisco UCS Integrated Infrastructure for Red Hat OpenStack
  • Guil Barros – Principal Product Manager, OpenStack @ Red Hat
  • Vish Jakka – Product Manager, UCS Solutions @ Cisco
Cisco UCS & Red Hat OpenStack: Upstream Partnership to Streamline OpenStack
  • Guil Barros – Principal Product Manager, OpenStack @ Red Hat
  • Vish Jakka – Product Manager, UCS Solutions @ Cisco
  • Arek Chylinski – Technologist @ Intel
Deploying and Integrating OpenShift on Dell’s OpenStack Cloud Reference Architecture
  • Judd Maltin – Systems Principal Engineer @ Dell
  • Diane Mueller – Director Community Development, OpenShift @ Red Hat
Scalable and Successful OpenStack Deployments on FlexPod
  • Muhammad Afzal – Architect, Engineering @ Cisco
  • Dave Cain Reference Architect and Technical Marketing Engineer @ NetApp
Simplifying Openstack in the Enterprise with Cisco and Red Hat
  • Karthik Prabhakar – Global Cloud Technologist @ Red Hat
  • Duane DeCapite – Director of Product Management, OpenStack @ Cisco
It’s a team sport: building a hardened enterprise ecosystem
  • Hugo Rivero – Senior Manager, Ecosystem Technology Certification @ Red Hat
Dude, this isn’t where I parked my instance!?
  • Steve Gordon – Senior Technical Product Manager, OpenStack @ Red Hat
Libguestfs: the ultimate disk-image multi-tool
  • Luigi Toscano – Senior Quality Engineer @ Red Hat
  • Pino Toscano – Software Engineer @ Red Hat
Which Third party OpenStack Solutions should I use in my Cloud?
  • Rohan Kande – Senior Software Engineer @ Red Hat
  • Anshul Behl – Associate Quality Engineer @ Red Hat

Securing OpenStack for the Enterprise

Everything You Need to Know to Secure an OpenStack Cloud (but Were Afraid to Ask)
  • Jonathan Gershater – Senior Principal Product Marketing Manager @ Red Hat
  • Ted Brunell – Senior Solution Architect @ Red Hat
Towards a more Secure OpenStack Cloud
  • Paul Lancaster – Strategic Partner Development Manager @ Red Hat
  • Malini Bhandaru – Architect & Engineering Manager @ Intel
  • Dan Yocum – Senior Operations Manager, Red Hat
Hands-on lab: configuring Keystone to trust your favorite OpenID Connect Provider.
  • Pedro Navarro Perez – Openstack Specialized Solution Architect @ Red Hat
  • Francesco Vollero – Openstack Specialized Solution Architect @ Red Hat
  • Pablo Sanchez – Openstack Specialized Solution Architect @ Red Hat
Securing OpenStack with Identity Management in Red Hat Enterprise Linux
  • Nathan Kinder – Software Engineering Manager @ Red Hat
Securing your Application Stacks on OpenStack
  • Jonathan Gershater – Senior Principal Product Marketing Manager @ Red Hat
  • Diane Mueller – Director, Community Development for OpenShift @ Red Hat

Celebrating Kubernetes 1.0 and the future of container management on OpenStack

This week, together with Google and others we celebrated the launch of Kubernetes 1.0 at OSCON in Portland as well as the launch of the Cloud Native Computing Foundation or CNCF (https://cncf.io/), of which Red Hat, Google, and others are founding members. Kubernetes is an open source system for managing containerized applications providing basic mechanisms for deployment, maintenance, and scaling of applications. The project was originally created by Google and is now developed by a vibrant community of contributors including Red Hat.

As a leading contributor to both Kubernetes and OpenStack it was also recently our great pleasure to welcome Google to the OpenStack Foundation. We look forward to continuing to work with Google and others on combining the container orchestration and management capabilities of Kubernetes with the infrastructure management capabilities of OpenStack.

Red Hat has invested heavily in Kubernetes since joining the project shortly after it was launched in June 2014, and are now the largest corporate contributor of code to the project other than Google itself. The recently announced release of Red Hat’s platform-as-a-service offering, OpenShift v3, is built around Kubernetes as the framework for container orchestration and management.

As a founding member of the OpenStack Foundation we have been working on simplifying the task of deploying and managing container hosts – using Project Atomic –  and configuring a Kubernetes cluster on top of OpenStack infrastructure using the Heat orchestration engine.

To that end Red Hat engineering created the heat-kubernetes orchestration templates to help accelerate research and development into providing deeper integration between Kubernetes and the underlying OpenStack infrastructure. The templates continue to evolve to include coverage for other aspects of container workload management such as auto-scaling and were recently demonstrated at Red Hat summit:

The heat-kubernetes templates were also ultimately leveraged in bootstrapping the OpenStack Magnum project which provides an OpenStack API for provisioning container clusters using underlying orchestration technologies including Kubernetes. The aim of this is to make containers first class citizens within OpenStack just like virtual machines and bare-metal before them, with the ability to share tenant infrastructure resources (e.g. networking and storage) with other OpenStack-managed virtual machines, baremetal hosts, and the containers running on them. Providing this level of integration requires providing or expanding OpenStack implementations of existing Kubernetes plug-in points as well as defining new plug-in APIs where necessary while maintaining the technical independence of the solution. All this must be done while allowing application workloads to remain independent of the underlying infrastructure and allowing for true open hybrid cloud operation. Similarly on the OpenStack side additional work is required so that the infrastructure services are able to support the use cases presented by container-based workloads and remove redundancies between the application workloads and the underlying hardware to optimize performance while still providing for secure operation.

Containers on OpenStack Architecture

Magnum, and the OpenStack Containers Team, provide a focal point to coordinate these research and development efforts across multiple upstream projects as well as other projects within the OpenStack ecosystem itself to achieve the goal of providing a rich container-based experience on OpenStack infrastructure.

As a leading contributor to both OpenStack and Kubernetes we at Red Hat look forward to continuing to work on increased integration with both the OpenStack and Kubernetes communities and our technology partners at Google as these exciting technologies for managing the “data-centers of the future” converge.

Containerize OpenStack with Docker

Written by: Ryan Hallisey

Today in the cloud space, a lot of buzz in the market stems from Docker and providing support for launching containers on top of an existing platform. However, what is often overlooked is the use of Docker to improve deployment of the infrastructure platforms themselves; in other words, the ability to ship your cloud in containers.


Hallisay-fig1

 

Ian Main and I took hold of a project within the OpenStack community to address this unanswered question: Project Kolla. Being one of the founding members and core developers for the project, I figured we should start by using Kolla’s containers to get this work off the ground. We began by deploying containers one by one in an attempt to get a functioning stack. Unfortunately, not all of Kolla’s containers were in great shape and they were being deployed by Kubernetes. First, we decided to get the containers working, then deal with how they’re managed later. In the short term, we used a bash script to launch our containers, but it got messy as Kubernetes was opening up ports to the host and declaring environment variables for the containers, and we needed to do the same. Eventually, we upgraded the design to use an environment file that was populated by a script, which proved to be more effective. This design was adopted by Kolla and is still being used today[1].

With our setup script intact, we started a hierarchical descent though the OpenStack services, starting with MariaDB, RabbitMQ, and Keystone. Kolla’s containers were in great shape for these three services, and we were able to get them working relatively quickly. Glance was next, and it proved to be quite a challenge. Quickly, we learned that the Glance API container and Keystone were causing one another to fail.

Hallisay-fig1

 

The culprit was that Glance API and Keystone containers were racing to see which could create the admin user first. Oddly enough, these containers worked with Kubernetes, but I then realized Kubernetes restarts containers until they succeed, avoiding the race conditions we were seeing. To get around this, we made Glance and the rest of the services wait for Keystone to be active before they start. Later, we pushed this design into Kolla, and learned that Docker has a restart flag that will force containers to restart if there is an error.[2] We added the restart flag to our design so that containers will be independent of one another.

The most challenging service to containerize was Nova. Nova presented a unique challenge not only because it was made up of the most number of containers, but because it required the use of super privileged containers. We started off using Kolla’s containers, but quickly learned there were many components missing. Most significantly, the Nova Compute and Libvirt containers were not mounting the correct host’s directories, exposing us to one of the biggest hurdles when containerizing Nova: persistent data and making sure instances still exist after you kill the container. In order for that to work, Nova Compute and Libvirt needed to mount /var/lib/nova and /var/lib/libvirt from the host into the container. That way, the data for the instances is stored on the host and not in the container[3].

 

echo Starting nova compute

docker run -d –privileged \

            –restart=always \

            -v /sys/fs/cgroup:/sys/fs/cgroup \

            -v /var/lib/nova:/var/lib/nova \

            -v /var/lib/libvirt:/var/lib/libvirt \

            -v /run:/run \

            -v /etc/libvirt/qemu:/etc/libvirt/qemu \

            –pid=host –net=host \

            –env-file=openstack.env kollaglue/centos-rdo-nova-compute-nova:latest

 

A second issue we encountered when trying to get the Nova Compute container working was that we were using an outdated version of Nova. The Nova Compute container was using Fedora 20 packages, while the other services were using Fedora 21. This was our first taste of having to do an upgrade using containers. To fix the problem, all we had to do was change where Docker pulled the packages from and rebuild the container, effectively a one line change in the Dockerfile:

From Fedora:20

MAINTAINER Kolla Project (https://launchpad.net/kolla)

To

From Fedora:21

MAINTAINER Kolla Project (https://launchpad.net/kolla)

OpenStack services have independent lifecycles making it difficult to perform rolling upgrades and downgrades. Containers can bridge this gap by providing an easy way to handle upgrading and downgrading your stack.

Once we completed our maintenance on the Kolla containers, we turned our focus to TripleO[4]. TripleO is a project in the OpenStack community that aims to install and manage OpenStack. The name TripleO means OpenStack on OpenStack, where it deploys a so called undercloud, and uses that OpenStack setup to deploy an overcloud, also known as the user cloud.

Our goal was to use the undercloud to deploy a containerized overcloud on bare metal. In our design, we chose to deploy our overcloud on top of Red Hat Enterprise Linux Atomic Host[5]. Atomic is a bare bones Red Hat Enterprise Linux-based operating system that is designed to run containers. This was a perfect fit because it’s a bare and simple environment with nice set of tools for launching containers.

 

[heat-admin@t1-oy64mfeu2t3-0-zsjhaciqzvxs-controller-twdtywfbcxgh ~]$ atomic –help

Atomic Management Tool

positional arguments:

{host,info,install,stop,run,uninstall,update}

commands

host                            execute Atomic host commands

info                             display label information about an image

install                          execute container image install method

stop                            execute container image stop method

run                               execute container image run method

uninstall                      execute container image uninstall method

update                        pull latest container image from repository

optional arguments:

-h, –help                  show this help message and exit

 

Next, we had help from Rabi Mishra in creating a Heat hook that would allow Heat to orchestrate container deployment. Since we’re on Red Hat Enterprise Linux Atomic Host, the hook was running in a container and it would start the heat agents; thus allowing for heat to communicate with Docker[6]. Now we had all the pieces we needed.

In order to integrate our container work with TripleO, it was best for us to copy Puppet’s overcloud deployment implementation and apply our work to it. For our environment, we used devtest, the TripleO developer environment, and started to build a new Heat template. One of the biggest differences between using containers and Puppet, was that Puppet required a lot of setup and config to make sure dependencies were resolved and services were being properly configured. We didn’t need any of that. With Puppet, the dependency list looked like[7]:

 

puppetlabs-apache
puppet-ceph

44 packages later…

puppet-openstack_extras
puppet-tuskar

 

With Docker, we were able to replace all of that with:

 

atomic install kollaglue/centos-rdo-<service>

 

We were able to use a majority of the existing environment, but now starting services was significantly simplified.

Unfortunately, we were unable to get results for some time because we struggled to deploy a bare metal Red Hat Enterprise Linux Atomic Host instance. After consulting Lucas Gomes on Red Hat’s Ironic (bare metal deployment service) team, we learned that there was an easier way to accomplish what we were trying to do. He pointed us in the direction of a new feature in Ironic that added support for full image deployment[8]. Although there was a bug in Ironic when using the new feature, we fixed it and started to see our Red Hat Enterprise Linux Atomic Host running. Now that we were past this, we could finally create images and add users, but Nova Compute and Libvirt didn’t work. The problem was that Red Hat Enterprise Linux Atomic Host wasn’t loading the kernel modules for kvm. On top of that, Libvirt needed proper permission to access /dev/kvm and wasn’t getting it.

 

#!/bin/sh

 

chmod 660 /dev/kvm

            chown root:kvm /dev/kvm


echo “Starting libvirtd.”
exec /usr/sbin/libvirtd

 

Upon fixing these issues, we could finally spawn instances. Later, these changes were adopted by Kolla because they represented a unique case that could cause Libvirt to fail[9].

To summarize, we created a containerized OpenStack solution inside of the TripleO installer project, using the containers from the Kolla project. We mirrored the TripleO workflow by using the undercloud (management cloud) to deploy most of the core services in the overcloud (user cloud), but now those services are containerized. The services we used were Keystone, Glance, and Nova; with services like Neutron, Cinder, and Heat soon to follow. Our new solution uses Heat (the orchestration service) to deploy the containerized OpenStack services onto Red Hat Enterprise Linux Atomic Host, and has the ability to plug right into the TripleO-heat-templates. Normally, Puppet is used to deploy an overcloud, but now we’ve proven you can use containers. What’s really unique about this, is that now you can shop for your config in the Docker Registry instead of having to go through Puppet to setup your services. This allows for you to pull down a container where your services come with the configuration you need. Through our work, we have shown that containers are an alternative deployment method within TripleO that can simplify deployment and add choice about how your cloud is installed.

The benefits of using Docker in a regular application are the same as having your cloud run in containers; reliable, portable, and easy life cycle management. With containers, lifecycle management greatly improves TripleO’s existing solution. The upgrading and downgrading process of an OpenStack service becomes far simpler; creating faster turnaround times so that your cloud is always running the latest and greatest. Ultimately, this solution provides an additional method within TripleO to manage the cloud’s upgrades and downgrades, supplementing the solution TripleO currently offers.

Overall, integrating with TripleO works really well because OpenStack provides powerful services to assist in container deployment and management. Specifically, TripleO is advantageous because of services like Ironic (the bare metal provisioning service) and Heat (the orchestration service), which provide a strong management backbone for your cloud. Also, containers are an integral piece of this system, as they provide a simple and granular way to perform lifecycle management for your cloud. From my work, it is clear that the cohesive relationship between containers and TripleO can create a new and improved avenue to deploy the cloud in a unique way to implement get your cloud working the way that you see fit.

TripleO is a fantastic project, and with the integration of containers I’m hoping to energize and continue building the community around the project. Using our integration as a proof of the project’s capabilities, we have shown that using TripleO provides an excellent management infrastructure underneath your cloud that allows for projects to be properly managed and grow.

 

[1]          https://github.com/stackforge/kolla/commit/dcb607d3690f78209afdf5868dc3158f2a5f4722

[2]          https://docs.docker.com/reference/commandline/cli/#restart-policies

[3]          https://github.com/stackforge/kolla/blob/master/docker/nova-compute/nova-compute-data/Dockerfile#L4-L5

[4]          https://www.rdoproject.org/Deploying_RDO_using_Instack

[5]          http://www.projectatomic.io/

[6]          https://github.com/rabi/heat-templates/blob/boot-config-atomic/hot/software-config/heat-docker-agents/Dockerfile

[7]          http://git.openstack.org/cgit/openstack/TripleO-puppet-elements/tree/elements/puppet-modules/source-repository-puppet-modules

[8]          https://blueprints.launchpad.net/ironic/+spec/whole-disk-image-support

[9]          https://github.com/stackforge/kolla/commit/08bd99a50fcc48539e69ff65334f8e22c4d25f6f