Infrastructure is meant to be open, trustworthy and secure. The best way to ensure trust in infrastructure is the use of Open Source software and hardware exclusively at the infrastructure level.

Before beginning this guide, be sure you read the introduction README in the directory above this one. Information on the project, goals, support channels and installs for other versions of OpenStack are available there.

Video Guide

The video for this guide is located on Vimeo.

Installation

Assuming a fresh install of Ubuntu 14.04 LTS Desktop, you'll need to locally login to each rig and install the openssh-server to allow remote ssh access:

sudo apt-get install openssh-server

Remotely log into your new server and install git with aptitude:

sudo su
apt-get -y install git

Checkout the StackGeek OpenStack setup scripts from Github:

git clone git://github.com/StackGeek/openstackgeek.git
cd openstackgeek/icehouse

Network Interfaces

You need to manually configure your ethernet interface to support a non-routable static IPv4 address and an auto configured IPv6 address.

./openstack_networking.sh

The script will output a short configuration block which should be placed manually in /etc/network/interfaces. Be sure to edit the IP adddress before you save the file! I suggest you use an ordered set of IPs like .100, .101, .102, etc. for your rigs.

# loopback
auto lo
iface lo inet loopback

# primary interface
auto eth0
iface eth0 inet static
  address 10.0.1.100
  netmask 255.255.255.0
  gateway 10.0.1.1
  dns-nameservers 8.8.8.8

# ipv6 configuration
iface eth0 inet6 auto

You will also need to edit your /etc/hosts file to contain an entry for your controller and any compute rigs. Here's an example:

127.0.0.1   localhost
10.0.1.100  hanoman
10.0.1.101  ravana

Reboot the rig after saving the file.

Privacy and Tracking Notice

A few of these scripts contain tracking pings and are used to analyze the install process flow. The IP address of the machine(s) you are installing will be reported to https://www.stackmonkey.com/. No other personal information is transmitted by the tracking pings. You may examine the Open Source code for handling the ping requests here.

You may run the following script if you would like to disable the tracking pings in these scripts:

./openstack_disable_tracking.sh

Another Note: Please also be aware that the openstack_setup.sh script below sends your configuration file to a pastebin knockoff hosted on stackgeek.com and keeps it until you delete it (instructions below). If you don't want this functionality, please edit the openstack_setup.sh script to your liking.

Test and Update

After editing the network, you'll need to test your rig for virtualization support:

./openstack_server_test.sh

If your rig doesn't support virtualization, you will need to check your virtualization settings in bios or upgrade your hardware. If it does support virtualization, you'll be prompted to update your Ubuntu install:

./openstack_system_update.sh

The update should come back pretty quick as you've already updated the system.

Setup

Note: Be sure to take a look at the scripts before you run them. Keep in mind the setup scripts will periodically prompt you for input, either for confirming installation of a package, or asking you for information for configuration.

Start the installation by running the setup script:

./openstack_setup.sh

You will be asked whether or not this rig is to be configured as a controller. If you answer yes, the result of the setup will be a setuprc file in the install directory. The setup script will also output a URL which is used to copy the existing setup to a compute rig. Here's an example URL:

https://sgsprunge.appspot.com/I2DIkNZxJyPhhIJc

If you indicated the rig is not a controller node, you will be prompted for the URL spit out by the controller installation as mentioned above. Paste this URL in and hit enter to start the compute rig install.

Note: If you are installing a compute rig, you may skip to the Cinder Setup section below.

Install Splunk (Controller Only)

If you would like to use Splunk for debugging and monitoring purposes, install it now:

./openstack_splunk.sh

Splunk will be configured to monitor the OpenStack packages logfiles. You may access splunk through the following URL (assuming you use the controller's correct IP address):

http://10.0.1.100:8000

Database Setup (Controller Only)

The next part of the setup installs MySQL and RabbitMQ. This is only required for the controller rig. Skip this step if you are setting up a compute rig for your cluster. Start the install on the controller rig by typing:

./openstack_mysql.sh

The install script will install Rabbit and MySQL. During the MySQL install you will be prompted for the MySQL password you entered earlier to set a password for the MySQL root user. You'll be prompted again toward the end of the script when it creates the databases.

The MySQL install script now runs the command 'mysql_secure_installation' to secure your MySQL install. Answer the questions this script presents to you to secure your install properly.

Keystone Setup (Controller Only)

Keystone is used by OpenStack to provide central authentication across all installed services. Start the install of Keystone by typing the following:

./openstack_keystone.sh

When the install is done, test Keystone by setting the environment variables using the newly created stackrc file. Note: This file can be sourced any time you need to manage the OpenStack cluster from the command line.

. ./stackrc
keystone user-list

Keystone should output the current user list to the console:

+----------------------------------+---------+---------+--------------------+
|                id                |   name  | enabled |       email        |
+----------------------------------+---------+---------+--------------------+
| 5474c43e65c840b5b371d695af72cba4 |  admin  |   True  | xxxxxxxx@gmail.com |
| dec9e0adf6af4066810b922035f24edf |  cinder |   True  | xxxxxxxx@gmail.com |
| 936e0e930553423b957d1983d0a29a62 |   demo  |   True  | xxxxxxxx@gmail.com |
| 665bc14a5da44e86bd5856c6a22866fb |  glance |   True  | xxxxxxxx@gmail.com |
| bf435eb480f643058e27520ee3737685 |   nova  |   True  | xxxxxxxx@gmail.com |
| 7fa480363a364d539278613aa7e32875 | quantum |   True  | xxxxxxxx@gmail.com |
+----------------------------------+---------+---------+--------------------+

Glance Setup (Controller Only)

Glance provides image services for OpenStack. Images are comprised of prebuilt operating system images built to run on OpenStack. There is a list of available images on the OpenStack site.

Start the Glance install by typing:

./openstack_glance.sh

Once the Glance install completes, you should be able to query the system for the available images:

glance image-list

The output should be something like this:

+--------------------------------------+--------------+-------------+--------+---------+--------+
| ID                                   | Name         | Disk Format | Format | Size    | Status |
+--------------------------------------+--------------+-------------+--------+-----------+--------+
| df53bace-b5a0-49ba-9b7f-4d43f249e3f3 | Cirros 0.3.0 | qcow2       | bare   | 9761280 | active |
+--------------------------------------+--------------+-------------+--------+---------+--------+

Cinder Setup

Cinder is used to provide additional volume attachments to running instances and snapshot space. Start the install of Cinder by typing:

./openstack_cinder.sh

Once the install of Cinder is complete, determine your space requirements and run the loopback volume creation script (keep in mind you have to create a loopback file that is at least 1GB in size):

./openstack_loop.sh

You should now be able to query installed storage types:

cinder type-list

You may then create a new volume to test:

cinder create --volume-type Storage --display-name test 1

Note: If you are installing a compute rig, you may skip to the *Nova Compute Setup section below.*

Nova Setup (Controller Only)

Nova provides multiple services to OpenStack for controlling networking, imaging and starting and stopping instances. If you are installing a compute rig, please skip to the following section to install the base nova-compute methods needed for running a compute rig.

Start the controller's nova install by typing the following:

./openstack_nova.sh

When the install is complete, you may query the running services by doing the following:

nova service-list

You should see output that looks similar to this:

+------------------+--------+----------+---------+-------+----------------------------+
| Binary           | Host   | Zone     | Status  | State | Updated_at                 |
+------------------+--------+----------+---------+-------+----------------------------+
| nova-cert        | tester | internal | enabled | up    | 2014-02-20T10:37:25.000000 |
| nova-conductor   | tester | internal | enabled | up    | 2014-02-20T10:37:17.000000 |
| nova-consoleauth | tester | internal | enabled | up    | 2014-02-20T10:37:25.000000 |
| nova-network     | tester | internal | enabled | up    | 2014-02-20T10:37:25.000000 |
| nova-scheduler   | tester | internal | enabled | up    | 2014-02-20T10:37:24.000000 |
+------------------+--------+----------+---------+-------+----------------------------+

Nova Compute Setup (Compute Rigs Only)

If you are installing a controller, this step has already been completed using the Nova Setup section above. You may skip this if you are installing a controller rig.

You may run this on any number of compute rigs. Start the Nova Compute setup on a given compute rig by typing the following:

./openstack_nova_compute.sh

Once the compute rig has been configured, you may log back into the controller rig and run the nova service list command again:

nova service-list

You should see new entries for the newly added compute rig:

+------------------+---------+----------+---------+-------+----------------------------+
| Binary           | Host    | Zone     | Status  | State | Updated_at                 |
+------------------+---------+----------+---------+-------+----------------------------+
| nova-cert        | nero    | internal | enabled | up    | 2014-04-13T17:20:52.000000 |
| nova-compute     | booster | nova     | enabled | up    | 2014-04-13T17:20:55.000000 |
| nova-compute     | nero    | nova     | enabled | up    | 2014-04-13T17:20:55.000000 |
| nova-conductor   | nero    | internal | enabled | up    | 2014-04-13T17:20:52.000000 |
| nova-consoleauth | nero    | internal | enabled | up    | 2014-04-13T17:20:52.000000 |
| nova-network     | booster | internal | enabled | up    | 2014-04-13T17:20:52.000000 |
| nova-network     | nero    | internal | enabled | up    | 2014-04-13T17:20:52.000000 |
| nova-scheduler   | nero    | internal | enabled | up    | 2014-04-13T17:20:52.000000 |
+------------------+---------+----------+---------+-------+----------------------------+

Flat Networking Setup for IPv4 (Controller Only)

This guide completely ignores the Neutron/Quantum project. If you are interested in Neutron, this is not the place to seek help.

Note: If you want to run IPv4 + IPv6, please skip to the next section and do NOT run this section's commands.

Begin by creating an IPv4 private network range which blocks out the 10.0.47.0 network (assuming the ethernet interface is eth0):

nova-manage network create private --fixed_range_v4=10.0.47.0/24 --num_networks=1 --bridge=br100 --bridge_interface=eth0 --network_size=255

You'll need to add a route in your router to point to the new network managed by the controller (pseudo command here):

route add 10.0.47.0 255.255.255.0 gw 10.0.1.200

You can view the networks by querying nova:

nova network-list

Output should look like this:

+--------------------------------------+---------+---------------+
| ID                                   | Label   | CIDR          |
+--------------------------------------+---------+---------------+
| 22aca431-14b3-43e0-a762-b02914770e6d | private | 10.0.1.224/28 |
+--------------------------------------+---------+---------------+

Flat Networking Setup for IPv4 + IPv6 (Controller Only)

Before you can add an IPv6 prefix to your OpenStack controller, you will need to configure your router to enable IPv6 on your provider. Your milage may vary by router type and provider. We've found the Asus routers + Comcast to be the easiest to configure: simply navigate to the IPv6 settings and then select 'native' or 'native with DHCP-PD' in your router's admin interface to turn on IPv6.

Note: If your provider doesn't support IPv6 and you have an IPv6 capable router, you can use Huricane Electric's Tunnel Broker to enable IPv6 on your network.

After configuring your router for IPv6, your router interface should show a LAN IPv6 prefix and length. Make note of the address, as you'll use it in a minute to add a prefix to OpenStack.

Now configure IPv6 forwarding support on the controller:

./openstack_ipv6.sh

Just in case, restart the Nova services to sync up the network:

./openstack_restart_nova.sh

Create an IPv4 private network range using sample networks of 10.0.47.0 for IPv4 and 2601:9:1380:821::/64 for an IPv6 prefix (again, assuming the ethernet interface is eth0):

nova-manage network create private --fixed_range_v4=10.0.47.0/24 --fixed_range_v6=2601:9:1380:821::/64 --num_networks=1 --bridge=br100 --bridge_interface=eth0 --network_size=255

You'll need to add a route in your router to point to the new network managed by the controller (pseudo command here, using 10.0.1.200 as the controller node):

route add 10.0.47.0 255.255.255.0 gw 10.0.1.200

You can view the private network by querying nova:

nova network-list

Output should look like this:

+--------------------------------------+---------+---------------+
| ID                                   | Label   | CIDR          |
+--------------------------------------+---------+---------------+
| 22aca431-14b3-43e0-a762-b02914770e6d | private | 10.0.1.224/28 |
+--------------------------------------+---------+---------------+

Floating IP Setup (Controller Only)

If you have a block of externally routed IP addresses (public IPs) you may create a floating IP entry for OpenStack:

nova-manage floating create 208.128.7.128/25

This example would allow a floating IP address to be assigned to instance from the range of 208.128.7.129 to 208.128.7.254.

If you added it, you can view the available floating pool addresses by querying nova again:

nova floating-ip-bulk-list

Output should look like this (truncated for space):

+------------+---------------+---------------+------+-----------+
| project_id | address       | instance_uuid | pool | interface |
+------------+---------------+---------------+------+-----------+
| None       | 208.128.7.129 | None          | nova | 10.0.2.15 |
| None       | 208.128.7.130 | None          | nova | 10.0.2.15 |
+------------+---------------+---------------+------+-----------+

Finally, edit the /etc/nova/nova.conf file to enable assigning the floating IPs to newly launched instances:

auto_assign_floating_ip=true

Note: As with the private IP space added earlier, you'll need to configure your router to route the external addresses to the controller's IP address. Your mileage will vary, depending on your current network setup.

Horizon Setup (Controller Only)

Horizon provides OpenStack's managment interface. Install Horizon by typing:

./openstack_horizon.sh

Now reboot the controller rig:

reboot

Once the rig comes back up, you should be able to log into your OpenStack cluster with the following URL format (changing the IP of course):

http://10.0.1.100/horizon

Your user/pass combination will be 'admin' and whatever you entered for a password earlier. If you accidentally run this command before adding the network above, you may see errors in the UI.

Note: If you log into the dashboard and get errors regarding quotas, log out of the UI by clicking on 'sign out' at the top right and then reboot the rig. The errors should go away when you log back in.

Install the StackMonkey Virtual Appliance

StackMonkey is a pool instance of a highly distributed cloud framework. If you elect to install the appliance, this OpenStack node will provide a small portion of its compute power to help build a highly distributed cloud. You will earn Bitcoin doing this.

The virtual appliance setup can be run by typing the following command:

./openstack_stackmonkey_va.sh

More information about the project can be viewed on the StackMonkey pool's site (requires auth to Google account). There is also a video guide that walks you through setting up your first appliance.

OpenStack Cheat Sheet

An OpenStack Command Line Cheat Sheet is available on Anystacker's site. Commands can be run once the setuprc file has been sourced:

. ./setuprc

Delete the Paste File

The URL created for a multi-rig install is stored on an AppEngine application based on Rupa's sprunge project. You should delete the paste after you are done with your setup for security's sake:

curl -X DELETE https://sgsprunge.appspot.com/I2DIkNZxJyPhhIJc

If you have any questions, issues or concerns, please feel free to join IRC, post on the forum, or create a ticket!

Low Power Nanoparticles

Emphasis

*italic*   **bold**
_italic_   __bold__

Links

An [example](http://url.com/ "Title")

Images

![alt text](/path/img.jpg "Title")
![alt text][id]
[id]: /url/to/img.jpg "Title"

Headers

Header 1
========

Header 2
--------

# Header 1 #

## Header 2 ##

###### Header 6

Lists

1.  Foo
2.  Bar

*   A list item.
*   Bar

*   Abacus
    * answer
*   Bubbles
    1.  bunk
    2.  bupkis
        * BELITTLER
    3. burper
*   Cunning

Blockquotes

> Email-style angle brackets
> are used for blockquotes.

> > And, they can be nested.

> #### Headers in blockquotes
> 
> * You can quote a list.
> * Etc.

Code Spans

`<code>` spans are delimited
by backticks.

You can include literal backticks
like `` `this` ``.

Preformatted Code Blocks

This is a normal paragraph.

    This is a preformatted
    code block.

Horizontal Rules

---

* * *

- - - -

Manual Line Breaks

Roses are red,   
Violets are blue.

This guide is being updated with the new Installing OpenStack Grizzly in 10 Minutes guide. While the guide below mostly works for installing OpenStack Essex, it is strongly suggested you follow the other guide to install the Grizzly version of OpenStack.

Requirements

StackGeek provides these scripts and this guide which will give you a working installation of OpenStack Essex in about 10 minutes. Before you start your OpenStack setup, please read the following requirements carefully:

1. You need a box with at least 8GB of RAM, 4 processing cores, (2) hard drives, and (1-2) ethernet cards.
2. You need a clean install of Ubuntu 12.04.1 LTS 64-bit server on your box. This guide will NOT work with Ubuntu 12.10.
3. A good dubstep track (this is optional).

Note: Only the primary ethernet card needs to be connected to the network. If you only have one ethernet card, you can hack the scripts to use the primary interface for your private network.

Video Guide

The video guide for this tutorial is on Vimeo.

Forum Discussion

There is now a forum discussion area on Google Groups for posting technical questions regarding the guide.

Download the Setup Scripts

Login to your box and install git with apt-get. We'll become root and do an update first.

sudo su
apt-get update
apt-get install git

Now checkout the StackGeek OpenStack setup scripts from Github:

git clone git://github.com/StackGeek/openstackgeek.git
cd openstackgeek/essex

Install the Base Scripts

Be sure to take a look at the scripts before you run them. Keep in mind the setup scripts will periodically prompt you for input, either for confirming installation of a package, or asking you for information for configuration.

Start the installation by running the first script:

./openstack_base_1.sh

When the script finishes you'll see instructions for manually configuring your network. You can edit the interfaces file by doing a:

vim /etc/network/interfaces

Copy and paste the network code provided by the script into the file and then edit:

auto eth0 
iface eth0 inet static
  address 10.0.1.20
  network 10.0.1.0
  netmask 255.255.255.0
  broadcast 10.0.1.255
  gateway 10.0.1.1
  dns-nameservers 8.8.8.8

auto eth1

Change the settings for your network configuration and then restart networking and run the next script:

/etc/init.d/networking restart
./openstack_base_2.sh

After the second script finishes, you'll need to set up a logical volume for Nova to use for creating snapshots and volumes. Nova is OpenStack's compute controller process.

Here's the output from the format and volume creation process:

root@precise:/home/kord/openstackgeek# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xb39fe7af.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-62914559, default 2048): 
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-62914559, default 62914559): 
Using default value 62914559

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
root@precise:/home/kord/openstackgeek# pvcreate -ff /dev/sdb1
  Physical volume "/dev/sdb1" successfully created
root@precise:/home/kord/openstackgeek# vgcreate nova-volumes /dev/sdb1
  Volume group "nova-volumes" successfully created
root@precise:/home/kord/openstackgeek#

Note: Your device names may vary.

Installing MySql

The OpenStack components use MySQL for storing state information. Start the install script for MySQL by entering the following:

./openstack_mysql.sh

You'll be prompted for a password to be used for each of the components to talk to MySQL:

Enter a password to be used for the OpenStack services to talk to MySQL (users nova, glance, keystone): f00bar

During the installation process you will be prompted for a root password for MySQL. In our install example we use the same password, 'f00bar'. At the end of the MySQL install you'll be prompted for your root password again.

mysql start/running, process 8796
#######################################################################################
Creating OpenStack databases and users.  Use your database password when prompted.

Run './openstack_keystone.sh' when the script exits.
#######################################################################################
Enter password:

After MySQL is running, you should be able to login with any of the OpenStack users and/or the root admin account by doing the following:

mysql -u root -pf00bar
mysql -u nova -pf00bar nova
mysql -u keystone -pf00bar keystone
mysql -u glance -pf00bar glance

Installing Keystone

Keystone is OpenStack's identity manager. Start the install of Keystone by doing:

./openstack_keystone.sh

You'll be prompted for a token, the password you entered for OpenStack's services, and your email address. The email address is used to populate the user's information in the database.

Enter a token for the OpenStack services to auth wth keystone: r4th3rb3t0k3n
Enter the password you used for the MySQL users (nova, glance, keystone): f00bar
Enter the email address for service accounts (nova, glance, keystone): user@foobar.com

You should be able to query Keystone at this point. You'll need to source the stackrc file before you talk to Keystone:

. ./stackrc
keystone user-list

Keystone should return a list of users:

+----------------------------------+---------+------------------------+--------+
|                id                | enabled |         email          |  name  |
+----------------------------------+---------+------------------------+--------+
| b32b9017fb954eeeacb10bebf14aceb3 | True    | kordless@foobar222.com | demo   |
| bfcbaa1425ae4cd2b8ff1ddcf95c907a | True    | kordless@foobar222.com | glance |
| c1ca1604c38443f2856e3818c4ceb4d4 | True    | kordless@foobar222.com | nova   |
| dd183fe2daac436682e0550d3c339dde | True    | kordless@foobar222.com | admin  |
+----------------------------------+---------+------------------------+--------+

Installing Glance

Glance is OpenStack's image manager. Start the install of Glance by doing:

./openstack_glance.sh

Note: You can safely ignore the SADeprecationWarning warning thrown by Glance when it starts.

The script will download an Ubuntu 12.04 LTS cloud image from StackGeek's S3 bucket. Go grab some coffee while it's downloading. Once it's done, you should be able to get a list of images:

glance index

Here's the expected output:

ID                                   Name                  Disk Format    Container Format   Size          
------------------------------------ --------------------- -------------- ------------------ ----------
71b8b5d5-a972-48b3-b940-98a74b85ed6a Ubuntu 12.04 LTS      qcow2          ovf                226426880

We'll cover adding images via Glance in another guide soon.

Installing Nova

We're almost done installing! The last component is the most important one as well. Nova is OpenStack's compute and network manager. It's responsible for starting instances, creating snapshots and volumes, and managing the network. Start the Nova install by doing:

./openstack_nova.sh

A Bit on Networking First

You'll immediately be prompted for a few items, including your existing network interface's IP address, the fixed network address, and the floating pool addresses:

####################################################################################################
The IP address for eth0 is probably 10.0.1.35. Keep in mind you need an eth1 for this to work.
####################################################################################################
Enter the primary ethernet interface IP: 10.0.1.35
Enter the fixed network (eg. 10.0.2.32/27): 10.0.2.32/27
Enter the fixed starting IP (eg. 10.0.2.33): 10.0.2.33
#######################################################################################
The floating range can be a subset of your current network.  Configure your DHCP server
to block out the range before you choose it here.  An example would be 10.0.1.224-255
#######################################################################################
Enter the floating network (eg. 10.0.1.224/27): 10.0.1.224/27
Enter the floating netowrk size (eg. 32): 32

Note: The script isn't very sophisticated and doesn't use defaults, so be sure you type in things carefully! You can rerun the script if you mess up. There's a nice subnet calculator here if you need help with network masks. For reference, the /27 above is called the 'mask bits' in the calculator.

The fixed network is a set of IP addresses which will be local to the compute nodes. Think of these addresses as being held and routed internally inside any of the compute node instances. If you decide to use a larger network, you could use something like 10.0.4.0/24 and a starting address of 10.0.4.1.

The floating network is a pool of addresses which can be assigned to the instances you are running. For example, you could start a web server and map an external IP to it for serving a site on the Internet. In the example above we use a private network because we're doing this at the house, but if your routing equipment/network allows it you could assign externally routed IPs to OpenStack instances.

Finish Installing Nova

Nova should finish installing after you enter all the network information. When it's done, you should be able to get a list of images from Glance via Nova:

nova image-list

And get the expected output we saw earlier from Glance:

root@precise:/home/kord/openstackgeek# nova image-list
+--------------------------------------+------------------+--------+--------+
|                  ID                  |       Name       | Status | Server |
+--------------------------------------+------------------+--------+--------+
| 71b8b5d5-a972-48b3-b940-98a74b85ed6a | Ubuntu 12.04 LTS | ACTIVE |        |
+--------------------------------------+------------------+--------+--------+

Installing Horizon

Horizon is the UI and dashboard controller for OpenStack. Install it by doing:

./openstack_horizon.sh

When it's done installing, you'll be given a URL to access the dashboard. You'll be able to login with the user 'admin' and whatever you entered earlier for your password. If you've forgotten it, simply grep for it in your environment:

env |grep OS_PASSWORD

Start Launching Instances

That's it! You can now watch the introduction video guide which gives an overview of creating a new project, users, and instances.

Be sure to drop us a line if you have any questions or corrections for this guide!

Some things that are magic

Emphasis

*italic*   **bold**
_italic_   __bold__

Links

An [example](http://url.com/ "Title")

Images

![alt text](/path/img.jpg "Title")
![alt text][id]
[id]: /url/to/img.jpg "Title"

Headers

Header 1
========

Header 2
--------

# Header 1 #

## Header 2 ##

###### Header 6

Lists

1.  Foo
2.  Bar

*   A list item.
*   Bar

*   Abacus
    * answer
*   Bubbles
    1.  bunk
    2.  bupkis
        * BELITTLER
    3. burper
*   Cunning

Blockquotes

> Email-style angle brackets
> are used for blockquotes.

> > And, they can be nested.

> #### Headers in blockquotes
> 
> * You can quote a list.
> * Etc.

Code Spans

`<code>` spans are delimited
by backticks.

You can include literal backticks
like `` `this` ``.

Preformatted Code Blocks

This is a normal paragraph.

    This is a preformatted
    code block.

Horizontal Rules

---

* * *

- - - -

Manual Line Breaks

Roses are red,   
Violets are blue.

I’ve been thinking about what he said since, and it appears everything Rackspace wants to achieve with its Open Source strategy is actually based on trust. All good ecosystems rely on trust, whether that’s the school you trust with your child's education, or the bank you trust with your cash or the technology bits you trust with your data. Without trust, no ecosystem remains stable. Trust also empowers positive change and innovation. People who want their ideas to have impact must entrust other people to amplify, execute and improve on what they’ve created. That’s why the most powerful innovators make ideas readily and equally available to markets, governments and society.

Trust is also a necessary requirement of any commodity. When you buy gold, pig iron, pork bellies or crude oil, you’ve got to trust that you’re getting what your contract says you’re going to get. You’ve got to trust that when you say “gold” and I say “gold” we’re talking about the same thing. No more, no less.

To that end, an Open Sourced OpenStack gives way to methods for trusting the underlying infrastructures that runs our code, stores our data and makes our technology startup innovation process successful. This trust in infrastructure comes about when you have access to and are able to understand all the hardware, software and services your company uses day to day. While there will be many of us who don't choose to look behind that curtain of transparency for all the components we use to build our business, there will be a few of us who can and will.

At no other moment in time has trust been at such a premium. Recent revelations show the NSA has its fingers in every aspect of technology in our lives, including our phones, our operating systems, our clouds, and even the processor chips in our computers. All of these current events serve to highlight how precarious and precious the establishment of trust has become in the communications and interactions occurring between all of us.

It's not a surprise most communications occurring today on the Internet take place via software APIs. These APIs are critical to establishing trust in the way we interact with each other.

APIs Define Interactions

APIs exist to provide programmers an easy way to 'wrap' a set of function calls which reside inside a larger set of separate files. You can imagine these function wrappers as envelopes with a label on the outside summarizing what is on the inside of the envelope. Inside each envelope are more envelopes with labels and/or letters, any of which you may choose to open and read, given you have the ability to open the envelopes and view the underlying code.

Let's take a look at a simple two file example of an API. The first file contains code that wraps a fictitious Open Source API called MiCloud:

# clusterbuster.py - a simple "API" for snakeoi.ly site
# THIS SOFTWARE IS PROVIDED BY BUSTER KNUTS ''AS IS'' ETC. ETC.
# 
# import the multi-tenant infrastructure cloud library
import MiCloud

def build_cluster(num_servers):
  cluster = MiCloud.create_cluster("Bob")
  for x in range(num_servers):
    node = MiCloud.grab_available_node()
    instance = node.start_instance()
    ip = MiCloud.get_ip()
    instance.assign_ip(ip)
    cluster.add_instance_to_cluster(instance)
    print "instance %s started" % x
  print "cluster built"

The code here provides a simple loop to iterate over several MiCloud calls. Our programmer can now write a small amount of code in a second file to start ten servers:

import clusterbuster

# start the snakoi.ly cluster
clusterbuster.build_cluster(10)

This second code snippet embodies the essence of an API: It makes it easy to do powerful things with a few lines of code. It also enables the underlying code to change the way it does things 'under the hood' without our programmer having to know or do anything different.

There are a few crackpots who think API parity between OpenSource software and closed/proprietary services like AWS are important. Contrary to these individual's claims, API trust is actually a far more important topic for consideration.

APIs Define Levels of Trust

Let's consider a scenario where another programmer is using a similar 'cloudy' API as the one above, but isn't able to see the first file because a) the code is closed source and b) it's being hosted on a service provider's infrastructure. In this example, the first file (again, hidden from public view) has been modified slightly by a large corporation to include code which checks to see how much a customer paid the service provider last month and if it was below a certain amount, starts an instance for them on an older part of the cloud provider's infrastructure:

  user_value = customer.last_month_invoice_amount()
  if user_value > 50000 or random.random() > 0.5:
    node = MiCloud.grab_available_node()
  else:
    node = MiCloud.grab_available_node_on_crappy_old_greasy_servers()

This decidedly evil example could present itself in the real world via proprietary software libraries or Web APIs, both of which could run non-Open Sourced code and non-transparent infrastructure.

If you think you can assume to trust proprietary APIs and closed source code created by companies who's primary purpose is increasing revenue, think again. Bruce Schneier's post from 2007 revealed what might have been a possible backdoor in the algorithm used by Microsoft's CryptoAPI. Fast forward to today, Microsoft is now being accused of giving the NSA a backdoor to Outlook and Skype. They are claiming they had no choice.

We all want to trust companies to do the right thing with our data. We want to trust Microsoft writes completely secure code we can run and we want to trust Amazon gives us fair, safe and secure computing with the AWS APIs. However, there’s no basis for that trust until you can see into the source code they are running or fully understand how they build and run the services they provide. This is especially true when companies are being forced into compromising situations by certain governments.

SaaS Services Benefit from Implied Trust

When Raffy Marty and I founded Loggly, I quickly realized how important our user's log data could be. Shortly after launching Loggly, we received a request from a customer to delete their account and all the data they sent us. It turned out one of their developers left debug statements in production code, which ended up forwarding their Loggly account all of their user's unencrypted usernames and passwords! Whoops. We both recalled stories of similar requests by Splunk customers struggling with purging data from their installs - for credit card numbers! Double whoops.

Incidents like these serve to illustrate a broader point which I completely missed at the time, but Raffy was quick to point out: Our customer's customers had no idea they also needed to trust Loggly with their data. Our customers assumed they could trust Loggly to do the right thing with that data because they were doing business with us, regardless of our intent or coding abilities. Further, the implied trust chain also required all those people also trust Amazon, because Loggly used the EC2 APIs to start and run our instances.

The fact is, if I use a proprietary service provider because I don't want to run the services myself, then there really is no way to know for certain they will act responsibly with my data. I must implicitly trust them to do the right thing, in all cases. Unfortunately, you can't really trust a service built on closed technologies because you can't see inside the service. The combination of desired outcomes (easy infrastructure) and risk bias (implied trust) presents itself as a dangerous one because leads to cognitive dissonance - literally believing two things at once: I have to TRUST this service because I NEED this service.

I believe, in order to achieve real trust, we have to open everything. And by everything I mean EVERYTHING on the Internet in between my brain and yours. Working together to build that trust enables better outcomes for customers, ensures there’s a sustainable innovation ecosystem and makes technology progressively more accessible to a wider and wider community.

A trust based initiative is worth fighting for and one I’m focused on building in the coming years. I trust you will join me! :)

Subdomain Handling

Webapp2 provides a method called DomainRoute which takes a subdomain as an argument and uses it to match a set of routes you pass to it. Here's a snippet of that in action:

routes = [
    # handle specific subdomain/hostname
    DomainRoute(config.subdomain_hostname, [
        Route('/', handler='handlers.PageHandler:subdomain', name='pages-subdomain'),
    ]),

    # handle other hostnames and domains
    Route('/', handler='handlers.PageHandler:root', name='pages-root'),
]

Try It Out

You can clone my example repo and add it to AppEngine Launcher to test the code. Check out the code locally by doing the following:

git clone git://github.com/kordless/webapp2-starter.git

You'll also need to modify your local hosts file for testing. Add the following to the bottom of your /etc/hosts file:

sublocalhost 127.0.0.1

Add the new project by going to File..Add Existing Application and browsing to the directory where you checked it out. Be sure to set the port to 8282 if you want to use the links I provide below.

Click on add. Click on the run button to start the app. You should now be able to hit the following urls:

• http://localhost:8282
• http://sublocalhost:8282

Notice you get different results for the two pages.

Production Configuration

For this to work in production on AppEngine, you'll need to add the full subdomain+domain to Google Apps. In the screenshot below, I've added a subdomain oi.utter.io to the utter.io domain I configured the first time through domain setup for my AppEngine project.

Now I'm in production, my config file looks like this:

# config file
if os.environ['SERVER_SOFTWARE'].startswith('Dev'):
    subdomain_hostname = 'sublocalhost'
else:
    subdomain_hostname = 'oi.utter.io'

With this technique I've been able to keep the code in a single repository, deployed to a single AppEngine project, yet serve two distinct subdomains. Very handy!

There is very little documentation available describing this process. This configuration was put together by studying the source code for the driver!

For this guide, OpenStack Folsom was installed on Ubuntu Server 12.04 using the Ubuntu Cloud Archive Repositories from http://ubuntu-cloud.archive.canonical.com/ubuntu.

The OpenStack configuration files are complex, and the configuration process for adding a NetApp box has a few caveats which are described here.

Configuration Files

All configuration is done in /etc/cinder directory.

/etc/cinder/cinder.conf

These are options which needs to be added to cinder.conf for the NetappNFS driver to work correctly:

# Make sure that you don't use nova.volume.netapp_nfs.NetAppNFSDriver
volume_driver=cinder.volume.netapp_nfs.NetAppNFSDriver

# Where the file with shares is located
nfs_shares_config=/etc/cinder/shares.conf

# Where to mount volumes
nfs_mount_point_base=/mnt/cinder-volumes

# Driver sends command to create clones and snapshots via DFM, 
# so we need to configure, it
netapp_wsdl_url=http://172.21.1.22/dfm.wsdl

netapp_login=dfmlogin
netapp_password=dfmpassword

netapp_server_hostname=172.21.1.21

# I'm not sure whether it is necessary to define
# netapp_storage_service
netapp_storage_service=Test-Cloud

/etc/cinder/shares.conf

This file includes Netapp volume/qtree paths on filer which will be mounted to control-node and used for cinder volume creation. Add one path per line in following format:

filername:/vol/CINDER_VOLUMES

Also, there are two things to consider when editing:

• Assure that there is no empty line in the file, because cinder is dumb and will try to mount empty path, which ends up with error.
• It is necessary to use hostnames of filers instead of IP addresses. These hostnames has to be same as hostnames of filers in DFM (OnCommand).

Double check you use the correct hostname for the filers if you get a snapshot creation fail:

2012-12-12 13:21:03 16643 TRACE cinder.openstack.common.rpc.amqp WebFault: Server raised fault: '(22255:EOBJECTNOTFOUND) There is no host, aggregate, volume, qtree, resource group, resource pool, or dataset named 192.168.0.2.'

/etc/cinder/rootwrap.d/volume.filters

Append following lines to the end of this file:

stat: CommandFilter, /usr/bin/stat, root
mount: CommandFilter, /bin/mount, root
df: CommandFilter, /bin/df, root
truncate: CommandFilter, /usr/bin/truncate, root
chmod: CommandFilter, /bin/chmod, root
rm: CommandFilter, /bin/rm, root

/etc/cinder/api-paste.ini

The [filter:authtoken] section has to be configured as it is described in cinder installation guide.

After all that configuration you can restart cinder services:

$ sudo service cinder-volume restart 
$ sudo service cinder-api restart 
$ sudo service cinder-scheduler restart

Now you can try to create volume from CLI:

$ cinder create --display_name test 1

or via Dashboard/Horizon:

Bugs Encountered

I patched the file nova/virt/libvirt/driver.py and added the NfsDriver to the list of drivers. There is more info on that process here.

Blueprint of NetappNFSDriver

The blueprints for the driver are here: https://blueprints.launchpad.net/cinder/+spec/netapp-nfs-cinder-driver