openstack-ansible is an open source project started by Rackspace to make deploying large OpenStack clouds easier. You describe your OpenStack environment in configuration files and openstack-ansible uses Ansible to lay down OpenStack from source and runs most OpenStack services inside LXC containers. The Kilo version of openstack-ansible was released last month. With that release came some significant changes from the Icehouse/Juno openstack-ansible code. This started as a Rackspace project, the Icehouse and Juno versions have Rackspace specific bits inside. Like a playbook to make it easier for our RPC support team to interact with an environment or our monitoring as a service code that was bundled in with openstack-ansible. However, our awesome team saw an opportunity to turn this into a community driven official OpenStack project. They removed all Rackspace specific bits so that openstack-ansible can be used by anyone with no reference to Rackspace or RPC. ...

openstack-ansible (OSAD), is a deployment method that uses Ansible to lay down OpenStack inside LXC containers. It makes deploying large OpenStack deployments easier. Deploying most components of OpenStack inside LXC containers also makes upgrading as easy as downloading the new playbooks and running. Here are some tips on managing the cluster once you’re up and runnning. Since the inventory includes all your hosts and containers, you can use Ansible to manage OpenStack and system administration tasks. ...

My post on using openstack-ansible to deploy OpenStack in LXC containers in a two-node configuration with two NICs. One NIC is used for management, API and VM to VM traffic, the other NIC is for external network access. This is just for testing and messing around with deploying OpenStack in containers. An advantage to deploying with Ansible and containers is the easier upgrade path it provides. I’ll show a simple example of that in place upgrade with going from Icehouse to Juno with just running a few playbooks. ...

Just a couple notes. I recently added a Swift node to my OpenStack deployment in my closet. For some reason I kept wanting to point Cyberduck to the infra1_swift_proxy_container at port 8080. Instead, you want to point it to port 5000 for Keystone auth, duh. By default SSL is not enabled in Swift so you can download the HTTP OpenStack profile OpenstackSwift(HTTP).cyberduckprofile. “Username:” in Cyberduck wants tenant:user, so out of the box you could use admin:admin, and the “Secret Key” would be the admin users password. ...

Building on my previous post on installing Rackspace Private Cloud in a two node configuration, this update changes that slightly to allow for external network access and floating IPs to work with this deployment. My previous post used all VXLAN interfaces from a single physical NIC. That would not allow external/floating IPs to work, or at least I couldn’t get it to work. Since I have two physical NICs on these servers this guide will use both - em1 for br-mgmt, br-vxlan, br-storage via VXLAN interfaces since I don’t want to use VLANs, and p4p1 for br-vlan, which has direct access to my external network, 192.168.1.0/24. ...

If you want to run your own private Docker registry here’s a quick and easy way to do that using Rackspace Cloud Files as the backend storage. Cloud Files is based on OpenStack Swift, so it comes with all the built in features and reliability that’s designed into Swift. Since this is Docker we’ll do it with the official Docker registry container, install docker-registry-driver-swift, and pass in our Cloud Files/Rackspace information when we run the container. ...