Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
A quick way to install swift onto a single machine for testing development
branch: master

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
chef
tests
LICENSE
README.textile
boot.txt
swift-install
swift-solo-tests
swift-test-setup

README.textile

swift-solo

swift-solo is an automated way to get a working Openstack Swift development setup working on a single machine, quickly, using Chef.

Setup

  • Ubuntu 10.04 (others may work)
  • Chef 0.9.X
  • Git

If starting from a raw ubuntu instance, you can run the commands in boot.txt to bootstrap chef and git.

Execution

The swift-install script will start chef-solo. The swift servers, the location of their data stores, and ports, are
configured (to a degree) with the swift.json file in the chef directory.

The repository to sync for the swift code can be configured in the chef/cookbooks/swift/attributes/swift.rb file. There are a few other configurable bits, and this will likely expand. Please open issues or make pull requests for configurations that you want or added.

swift-test-setup runs a simple recipe to install python-cloudfiles and swift-solo-tests will run everything it finds in the test directory, which right now has one script that will create an account, add an object and retrieve it.

We encourage you to read how the recipes work and they are basically an automation of the SAIO – Swift All In One instructions.

Overview

The running Swift service is provided by 5 connected servers: object, container, account, auth, and proxy.

The object, container and account are where actual data is stored. The implementation of these services are all similar, they all represent different granularity of rings mapping the names of entities in swift and their physical location. Object contains the actual blobs, container indexes the objects and account indexes the containers.

The auth server provides authentication and the proxy server provides the API to GET and POST data from the other services.

Chef Recipes

chef-solo does the heavy lifting. The chef/swift.json contains all the configuration for setting up the rings and servers and the chef runlist (which for now starts of the swift::default recipe).

swift::default:
setup the base environment
install swift from a repo
install rsync, which is needed to keep the rings synchronized between nodes
manage rsyncd.conf, with the various server information
runs the recipes for each service
builds the rings and rebalances them

swift::install:
Syncs the repository and installs swift

swift::demo_device:
creates an xfs filesystem on a loopback file device as a test playground for the server data. In general this won’t be needed on real servers, since there will be /dev/sd? drives to work off of, but on the virtual machines for testing purposes we create this and mount it into /mnt/sdb1. The idea of putting it in its own recipe was so it was easier to turn off/rip out later.

There is a recipe for each of the swift servers
swift::object-server
swift::container-server
swift::account-server
swift::auth-server
swift::proxy-server

These take the data from swift.json and create the swift server config files, and startup the server. It loops over the multiple entries since we have multiple servers of each type on the same machine. These recipes add their info to the rsyncd.conf template variable with the server information and create an /etc/init.d file for startup and reboots.

License

Apache 2

Copyright 2010, Cloudscaling

Something went wrong with that request. Please try again.