Ext osad initial-eval-march2015

1© 2011 Cisco and/or its affiliates. All rights reserved.

Daneyon HansenSoftware Engineer

March 18, 2015

© 2011 Cisco and/or its affiliates. All rights reserved. 2

• Because deploying OpenStack for production is still:

1. Difficult

2. Error prone

3. Unreliable

4. Inflexible

5. One of the biggest barriers to adoption


• Proven

Based on RackSpace’s experience in building and operating OpenStack clouds, public and private

• Mindset of an operator

• I personally have felt the pain

• Limited mature solutions

• A new approach to solving a problem

• Recent generalization of project


• An open source project

• Great community support

• Deployment automation, config management & orchestration using Ansible

• Containerized services

• Scalable logging

• Deployment and Ops

• Reliable deployments


• Deployment flexibility

• Production-style networking design

• Solid documentation

• Solid release management

• HA

• Well tested- CICD, Gating, etc..

• 6 cores from RAX


• Nearly every config has been tweaked

• No patched code

• Memcached and Apache2 for Keystone

• Https/Memcached/Galera for Horizon

• Kernel params (Neutron block writes, file desc, memsize)

• Only where it makes sense


• Neutron L3 Agent HA

• Dynamic inventory management

• Random password generator

• Heat template


• Simple

Easy to learn

Yaml-based

• Scales up/down

• Agentless

Nothing to install on remote hosts

Push-based

• Secure transport using SSH

• Idempotent

• Thin abstraction layer


• Automated

• Uses familiar tools and techniques

• NIC Bonding

• AT&T tool for Neutron L3 Agent HA

• Includes ongoing ops

• HAProxy is a SPOF and not containerized

• Well tested

https://github.com/stackforge/os-ansible-deployment/blob/master/playbooks/roles/os_neutron/files/neutron-ha-tool.py


• GPLv3 license

• Ansible creator stepped on toes


• LXC

• Easy to use:

lxc-ls, lxc-attach

• Simple functionality:

provide isolation on a shared OS

• Supports multiple processes within a container

• Container Affinity

• Common base image

• Ansible drives container config

• Supports LVM backend

• Not all services are containerized

• Auto start/restart of containers



• Networks for host management, container management, storage, Neutron overlay and floating-ip’s

• Not all are mandatory

• NIC bonding support

• Physical network <> Linux Bridge <> Container ethX

• Network namespaces for container networking isolation

• Host networking setup is manual

BP for automating setup using the debops.ifupdown galaxy role

https://blueprints.launchpad.net/openstack-ansible/+spec/improved-network-generation


• Uses ML2 and Linux Bridge

• VXLAN tenant networking

• L3/DHCP/Meta/Metering/LB agents run in a shared container

• Must share namespace

• DVR in Juno branch, but for experimentation only.

• No plans for support in Kilo due to OVS requirement. Happy with HA tool solution.


• Cinder for Block

LVM and NetApp backend support

Multi-backend support

• Swift or RAX Cloud Files for Object

• NFS with NetApp Cinder backend

• Support for multiple AZ’s

• No Ceph support (roadmap). Ceph has an Ansible playbook

• Support for network segmentation of storage traffic

https://github.com/ceph/ceph-ansible


• Leverages openstack-infra for CICD

• Gating

Lint check

Commit checks- AIO for integration testing

Includes Tempest tests

External CI on real multi-node

• Spec testing within Ansible playbooks

Can be improved



http://youtu.be/P8bAXNUkl1I

http://youtu.be/P8bAXNUkl1I


Thank you.