EduCloud

h1. Ambiente de Desenvolvimento

h2. Lista de Servidores

* educloud00 - 200.145.46.166

* educloud01 - 200.145.46.167

* educloud02 - 200.145.46.168

* educloud03 - 200.145.46.169

* educloud04 - 200.145.46.170

* educloud05 - 200.145.46.174

* educloud06 - 200.145.46.175

* educloud07 - 200.145.46.173

h3. Desabilitados

* educloud05 - 200.145.46.171

* educloud06 - 200.145.46.172

h1. Introduction

This document refers to the installation manual of the main components of

OpenStack. The version of each component used can be found in the respective

sections of the components.

This document was produced by the Center for Scientific Computing, UNESP, with

funding from Intel and UNESP.

OpenStack OpenStack is a global collaboration of developers and cloud computing

technologists producing the ubiquitous open source cloud computing platform for 

public and private clouds. The project aims to deliver solutions for all types

of clouds by being simple to implement, massively scalable, and feature rich.

The technology consists of a series of interrelated projects delivering various

components for a cloud infrastructure solution.

The OpenStack project is divided into sub projects that have a specific role in

the big picture.

The main components are: Cloud Compute (Nova) Cloud Storage (Swift), Image 

registration and delivery (Glance), Identity (Keystone) and Dashboard

(Horizon).

Each component is independent of each other and can be installed on separate

machines, or all in one. In the environment of UNESP, OpenStack was installed in

seven machines, described in section "Environment used."

This document is modified version of OpenStack Install and Deploy Manual [1] 

with minor adjustments and changes to resolve problems encountered during 

installation and adjustment to the environment in which it was installed.

h1. OpenStack Core Components

OpenStack is a collection of open source technology that provides massively

scalable open source cloud computing software. Currently OpenStack develops two

related projects: OpenStack Compute, which offers computing power through

virtual machine and network management, and OpenStack Object Storage which is

software for redundant, scalable object storage capacity. Closely related to the

OpenStack Compute project is the Image Service project, named Glance. OpenStack

can be used by corporations, service providers, VARS, SMBs, researchers, and

global data centers looking to deploy large-scale cloud deployments for private

or public clouds.

The main components are: Cloud Compute (Nova) Cloud Storage (Swift), Image

registration and delivery (Glance), Identity (Keystone) and Dashboard

(Horizon).

They are presented here in an order for educational purposes only to a 

straightforward procedure for installation. But following a brief description of

each component.

h2. Keystone

Keystone is an OpenStack project that provides Identity, Token, Catalog and 

Policy services for use specifically by projects in the OpenStack family. It

implements OpenStack’s Identity API.

h2. Cloud Compute (Nova)

Nova is the project name for OpenStack Compute, a cloud computing fabric

controller, the main part of an IaaS system. Individuals and organizations can

use Nova to host and manage their own cloud computing systems. Nova originated

as a project out of NASA Ames Research Laboratory.

h2. Object Storage (Swift)

OpenStack Object Storage (Swift) is a system to store objects in a massively

scalable large capacity system with built-in redundancy and failover. Object

Storage has a variety of applications, such as backing up or archiving data,

serving graphics or videos (streaming data to a user's browser), storing

secondary or tertiary static data, developing new applications with data

storage integration, storing data when predicting storage capacity is difficult,

and creating the elasticity and flexibility of cloud-based storage for your web

applications.

h2. Image Service (Glance)

OpenStack Image Service (Glance) is a lookup and retrieval system for virtual

machine images. It can be configured in three ways: using OpenStack Object Store

to store images; using Amazon's Simple Storage Solution (S3) storage directly;

or using S3 storage with Object Store as the intermediate for S3 access.

h1. Environment Proposed

This document aims to guide you in setting up a test environment or development.

The original documentation suggests many machines. To install OpenStack here,

you will need only one or two machines.

You can install all services on one machine only (all-in-one). Or you can

install OpenStack controller (all services except the nova-compute) on machine A

and a compute cloud controller on machine B.

For a production environment it is advisable to separate the elements to ensure

a high availability and redundancy.

Settings used in this document:

 - Cloud Controller:

 - Cloud Computer Node:

All machines are installed with Ubuntu Server 12.04 LTS.

h1. Initial configuration

Before starting the installation and configuration of each component must first

to make some adjustments.

h2. Network Configuration

For both conserving network resources and ensuring that network administrators

understand the needs for networks and public IP addresses for accessing the APIs

and VMs as necessary, this section offers recommendations and required minimum

sizes. Throughput of at least 1000 Mbps is suggested.

For OpenStack Compute, networking is configured on multi-node installations

between the physical machines on a single subnet. For networking between virtual

machine instances, three network options are available: flat, DHCP, and VLAN.

Two NICs (Network Interface Cards) are recommended on the server running

nova-network.

Management Network (RFC1918 IP Range, not publicly routable): This network is

utilized for all inter-server communications within the cloud infrastructure.

Recommended size: 255 IPs (CIDR /24)

Public Network (Publicly routable IP range): This network is utilized for

providing Public IP accessibility to the API endpoints within the cloud

infrastructure. Minimum size: 8 IPs (CIDR /29)

VM Network (RFC1918 IP Range, not publicly routable): This network is utilized

for providing primary IP addresses to the cloud instances. Recommended size:

1024 IPs (CIDR /22)

Floating IP network (Publicly routable IP Range): This network is utilized for

providing Public IP accessibility to selected cloud instances. Minimum size:

16 IPs (CIDR /28)

In this installation we will use eth0 to public interface and eth1 for

management interface.

h2. Installing Network Time Protocol (NTP)

To keep all the services in sync, you need to install NTP, and if you do a

multi-node configuration you will configure one server to be the reference

server.

# apt-get install -y ntp

Set up the NTP server on your controller node so that it receives data by

modifying the ntp.conf file and restarting the service. As root:

# sed -i 's/server ntp.ubuntu.com/server ntp.ubuntu.com\nserver 127.127.1.0\

nfudge 127.127.1.0 stratum 10/g' /etc/ntp.conf

# service ntp restart

Set up the NTP client on your compute node so that the time between controller

node and compute node is synchronized. Do the following as a cron job on compute

node.

# ntpdate 'controllernode ip'

# hwclock -w

h2. Storage

Many cloud computing use cases require persistent remote storage. Storage

solutions are often divided into three categories: object storage, block

storage, and file storage.

Here we will use a "object storage" and a "block storage".

h3. Object storage (swift)

With object storage, files are exposed through an HTTP interface, typically with

a REST API. All client data access is done at the user level: the operating

system is unaware of the presence of the remote storage system. In OpenStack,

the Object Storage service provides this type of functionality. Users access and

modify files by making HTTP requests. Because the data accesss interface provided

by an object storage system is at a low level of abstraction, people often build

on top of object storage to build file-based applications that provide a higher

level of abstraction. For example, the OpenStack Image service can be configured

to use the Object Storage service as a backend. Another use for object storage

solutions is as a content delivery network (CDN) for hosting static web content

(e.g., images, and media files), since object storage already provides an HTTP

interface.

h3. Block storage (SAN)

With block storage, files are exposed through a low-level computer bus interface

such as SCSI or ATA, that is accessible over the network. Block storage is

synonymous with SAN (storage area network). Clients access data through the

operating system at the device level: users access the data by mounting the

remote device in a similar manner to how they would mount a local, physical disk

(e.g., using the "mount" command in Linux). In OpenStack, the nova-volume

service that forms part of the Compute service provides this type of

functionality, and uses iSCSI to expose remote data as a SCSI disk that is

attached to the network.

Because the data is exposed as a physical device, the end-user is responsible

for creating partitions and formatting the exposed disk device. In addition,

in OpenStack Compute a device can only be attached to one server at a time, so

block storage cannot be used for to share data across virtual machine instances

concurrently.

h1. Installation Assumptions

OpenStack Compute has a large number of configuration options. To simplify this

installation guide, we make a number of assumptions about the target

installation:

 * You have a collection of compute nodes, each installed with Ubuntu Server

12.04

 * You have designated one of the nodes as the Cloud Controller, which will run

all of the services (RabbitMQ, MySQL, Identity, Image, nova-api, nova-network,

nova-scheduler, nova-volume) except for nova-compute.

 * The disk partitions on your cloud controller are being managed by the Logical

Volume Manager (LVM)

 * Your Cloud Controller has an LVM volume group named "nova-volumes" to provide

persistent storage to guest VMs. Either create this during the installation or

leave some free space to create it prior to installing nova services.

 * Ensure that the server can resolve its own hostname, otherwise you may have

problems if you are using RabbitMQ as the messaging backend (RabbitMQ is the default

messaging back-end on Ubuntu, on Fedora the default backend is Qpid).

 * 192.168.69.1 is the primary IP for our controller host on eth0 and

192.168.69.2 is the primary IP for our computer node on eth0.

 * FlatDHCP with a single network interface.

 * KVM as the hypervisor.

 * Ensure the operating system is up-to-date by running apt-get update and

apt-get upgrade prior to the installation.

 * Ensure that all hosts are with ntp and correct time.

This installation process walks through installing a cloud controller node and a

compute node using a set of packages that are known to work with each other.

The cloud controller node contains all the nova- services including the API

server and the database server. The compute node needs to run only the

nova-compute service. You only need one nova-network service running in a

multi-node install.

h1. Keystone

The OpenStack Identity service manages users, tenants (accounts or projects) and

offers a common identity system for all the OpenStack components.

The Identity services has two primary functions:

 1. User management: keep track of users and what they are permitted to do

 2. Service catalog: Provide a catalog of what services are available and where

their API endpoints are located.

h2. User management

The three main concepts of Identity user management are:

* Users

* Tenants

* Roles

A user represents a human user, and has associated information such as username,

password and email.

A tenant can be thought of as a project, group, or organization. Whenever you

make requests to OpenStack services, you must specify a tenant. For example, if

you query the Compute service for a list of running instances, you will receive

a list of all of the running instances in the tenant you specified in your

query.

A role captures what operations a user is permitted to perform in a given tenant.

h3. Service management

The two main concepts of Identity service management are:

* Services

* Endpoints

The Identity service also maintains a user that corresponds to each service

(e.g., a user named nova, for the Compute service) and a special service tenant,

which is called service.

h3. Installing Keystone

<pre>

# apt-get install keystone

</pre>

Delete the keystone.db file created in the /var/lib/keystone directory.

<pre>

# rm /var/lib/keystone/keystone.db

</pre>

Install mysql:

<pre>

# apt-get install python-mysqldb mysql-server

</pre>

Use sed to edit /etc/mysql/my.cnf to change bind-address from localhost

(127.0.0.1) to any (0.0.0.0) and restart the mysql service, as root:

<pre>

# sed -i 's/127.0.0.1/0.0.0.0/g' /etc/mysql/my.cnf

# service mysql restart

</pre>

To configure the MySQL database, create the keystone database.

<pre>

# mysql -u root -p

mysql> CREATE DATABASE keystone;

mysql> GRANT ALL ON keystone.* TO 'keystone'@'%' IDENTIFIED BY 'keystonepass';

mysql> FLUSH PRIVILEGES;

mysql> quit;

</pre>

Edit _*keystone.conf*_ to use mysql:

<pre>

[sql]

connection = mysql://keystone:keystonepass@192.168.69.1/keystone

</pre>

Change in _*keystone.conf*_ the ADMIN_TOKEN:

<pre>

admin_token = 012345SECRET99TOKEN012345

</pre>

Restart the keystone service and populate with initial data:

<pre>

# service keystone restart

# keystone-manage db_sync

</pre>

h2. Configuring Services to work with Keystone

Create the file _*/root/openstackrc*_, with theses lines

<pre>

export SERVICE_ENDPOINT=http://192.168.69.1:35357/v2.0/

export SERVICE_TOKEN=012345SECRET99TOKEN012345

</pre>

Theses environment variables are useful to avoid execute commands with long args, like --token or --endpoint.

Reload the file:

<pre>

# source /root/openstackrc

</pre>

Create the *tenants*: _openstackDemo_ and _service_:

<pre>

# keystone tenant-create --name openstackDemo --description "Default Tenant"  --enabled true

# keystone tenant-create --name service --description "Service Tenant"  --enabled true

</pre>

Create the *user* _admin_, replace the tenant_id by openStackDemo tenant_id:

<pre>

# keystone user-create --tenant_id 9c401c9d2b9d41bcabda6919d4aec63a --name admin --pass adminpass --enabled true

</pre>

Create the *roles*: _admin_ and _user_:

<pre>

# keystone role-create --name admin

# keystone role-create --name user

</pre>

Grant _admin_ *role* to *user* _admin_:

<pre>

# keystone user-role-add --user [admin_user_id] --tenant_id [openstackDemo_tenant_id] --role [admin_role]

</pre>

Create an user to each service, replace the tenant_id by the service tenant id:

<pre>

# keystone user-create --tenant_id 92920816c7704a8a95c916d34dc7a05c --name glance --pass glancepass --enabled true

# keystone user-create --tenant_id 92920816c7704a8a95c916d34dc7a05c --name nova --pass novapass --enabled true

# keystone user-create --tenant_id 92920816c7704a8a95c916d34dc7a05c --name swift --pass swiftpass --enabled true

</pre>

Add the users of each service to admin *role*:

<pre>

# keystone user-role-add --user [glance_user_id] --tenant_id [service_tenant_id] --role [admin_role]

# keystone user-role-add --user [nova_user_id] --tenant_id [service_tenant_id] --role [admin_role]

# keystone user-role-add --user [swift_user_id] --tenant_id [service_tenant_id] --role [admin_role]

</pre>

h2. Creating the services:

Until now, we just created: tenants, users and roles. The Keystone manage the services and yours endpoints too. In this way, the OpenStack components query to keystone where each service is located:

Run the follow commands, to create the services:

<pre>

# keystone service-create --name keystone --type identity --description "Keystone Identity Service" 

# keystone service-create --name nova --type compute --description "Nova Compute Service"

# keystone service-create --name volume --type volume --description "Nova Volume Service"

# keystone service-create --name glance --type image --description "Glance Image Service"

# keystone service-create --name swift --type object-store --description "Object Storage Service"

</pre>

Run the follow commands, to create the endpoints of each service:

<pre>

# keystone endpoint-create --region RegionOne --service_id [keystone_service_id] --publicurl http://192.168.69.1:5000/v2.0 --internalurl http://192.168.69.1:5000/v2.0 --adminurl http://192.168.69.1:35357/v2.0

# keystone endpoint-create --region RegionOne --service_id [compute_service_id] --publicurl 'http://192.168.69.1:8774/v2/%(tenant_id)s' --internalurl 'http://192.168.69.1:8774/v2/%(tenant_id)s' --adminurl 'http://192.168.69.1:8774/v2/%(tenant_id)s'

# keystone endpoint-create --region RegionOne --service_id [volume_service_id] --publicurl 'http://192.168.69.1:8776/v1/%(tenant_id)s' --internalurl 'http://192.168.69.1:8776/v1/%(tenant_id)s' --adminurl 'http://192.168.69.1:8776/v1/%(tenant_id)s'

# keystone endpoint-create --region RegionOne --service_id [glance_service_id] --publicurl http://192.168.69.1:9292/v1 --internalurl http://192.168.69.1:9292/v1 --adminurl http://192.168.69.1:9292/v1

# keystone endpoint-create --region RegionOne --service_id [swift_service_id] --publicurl 'http://192.168.69.1:8888/v1/AUTH_%(tenant_id)s' --adminurl 'http://192.168.69.1:8888/' --internalurl 'http://192.168.69.1:8888/v1/AUTH_%(tenant_id)s'

</pre>

h2. Checking the keystone installation:w

<pre>

# sudo apt-get install curl openssl

</pre>

Do a REST request to keystone-api using curl:

<pre>

# curl -d '{"auth": {"tenantName": "openstackDemo", "passwordCredentials": {"username": "admin", "password": "adminpass"}}}' -H "Content-type: application/json" http://192.168.69.1:35357/v2.0/tokens  | python -mjson.tool

</pre>

The output should have the services, endpoints and a valid token for 24 hours:

<pre>

{

    "access": {

        "serviceCatalog": [

            {

                "endpoints": [

                    {

                        "adminURL": "http://192.168.69.1:8776/v1/9c401c9d2b9d41bcabda6919d4aec63a", 

                        "internalURL": "http://192.168.69.1:8776/v1/9c401c9d2b9d41bcabda6919d4aec63a", 

                        "publicURL": "http://192.168.69.1:8776/v1/9c401c9d2b9d41bcabda6919d4aec63a", 

                        "region": "RegionOne"

                    }

                ], 

                "endpoints_links": [], 

                "name": "volume", 

                "type": "volume"

            }, 

            {

                "endpoints": [

                    {

                        "adminURL": "http://192.168.69.1:9292/v1", 

                        "internalURL": "http://192.168.69.1:9292/v1", 

                        "publicURL": "http://192.168.69.1:9292/v1", 

                        "region": "RegionOne"

                    }

                ], 

                "endpoints_links": [], 

                "name": "glance", 

                "type": "image"

            }, 

            {

                "endpoints": [

                    {

                        "adminURL": "http://192.168.69.1:8774/v2/9c401c9d2b9d41bcabda6919d4aec63a", 

                        "internalURL": "http://192.168.69.1:8774/v2/9c401c9d2b9d41bcabda6919d4aec63a", 

                        "publicURL": "http://192.168.69.1:8774/v2/9c401c9d2b9d41bcabda6919d4aec63a", 

                        "region": "RegionOne"

                    }

                ], 

                "endpoints_links": [], 

                "name": "nova", 

                "type": "compute"

            }, 

            {

                "endpoints": [

                    {

                        "adminURL": "http://192.168.69.1:35357/v2.0", 

                        "internalURL": "http://192.168.69.1:5000/v2.0", 

                        "publicURL": "http://192.168.69.1:5000/v2.0", 

                        "region": "RegionOne"

                    }

                ], 

                "endpoints_links": [], 

                "name": "keystone", 

                "type": "identity"

            }, 

            {

                "endpoints": [

                    {

                        "adminURL": "http://192.168.69.1:8888/", 

                        "internalURL": "http://192.168.69.1:8888/v1/AUTH_9c401c9d2b9d41bcabda6919d4aec63a", 

                        "publicURL": "http://192.168.69.1:8888/v1/AUTH_9c401c9d2b9d41bcabda6919d4aec63a", 

                        "region": "RegionOne"

                    }

                ], 

                "endpoints_links": [], 

                "name": "swift", 

                "type": "object-store"

            }

        ], 

        "token": {

            "expires": "2012-06-08T15:31:46Z", 

            "id": "05b818ff23564d5599c97ea5e1df7bbe", 

            "tenant": {

                "description": "Default Tenant", 

                "enabled": true, 

                "id": "9c401c9d2b9d41bcabda6919d4aec63a", 

                "name": "openstackDemo"

            }

        }, 

        "user": {

            "id": "1fcfbe778fc3428aa30db782056b34d7", 

            "name": "admin", 

            "roles": [

                {

                    "id": "a2d6da77c0a54105aab94484e0d2088b", 

                    "name": "admin"

                }

            ], 

            "roles_links": [], 

            "username": "admin"

        }

    }

}

</pre>

You can list users, roles, tenants and services:

<pre>

# keystone user-list

+----------------------------------+---------+-------+--------+

|                id                | enabled | email |  name  |

+----------------------------------+---------+-------+--------+

| 029c5749548946f7b560b2706d31d488 | True    | None  | glance |

| 1fcfbe778fc3428aa30db782056b34d7 | True    | None  | admin  |

| 4b75079aeb1b408ebdb286bfb85e719f | True    | None  | swift  |

| e25f81d50eb84bdb92907adbd0e41f25 | True    | None  | nova   |

+----------------------------------+---------+-------+--------+

</pre>

<pre>

# keystone role-list

+----------------------------------+-------+

|                id                |  name |

+----------------------------------+-------+

| 845e83e4d9bf4d8d8188b1e261dfe103 | user  |

| a2d6da77c0a54105aab94484e0d2088b | admin |

+----------------------------------+-------+

</pre>

<pre>

# keystone tenant-list

+----------------------------------+---------------+---------+

|                id                |      name     | enabled |

+----------------------------------+---------------+---------+

| 92920816c7704a8a95c916d34dc7a05c | service       | True    |

| 9c401c9d2b9d41bcabda6919d4aec63a | openstackDemo | True    |

+----------------------------------+---------------+---------+

</pre>

<pre>

# keystone service-list

+----------------------------------+----------+----------------+---------------------------+

|                id                |   name   |      type      |        description        |

+----------------------------------+----------+----------------+---------------------------+

| 00486163c7c64c6a86f577627071aafc | nova     | compute        | Nova Compute Service      |

| 69d3a6b21c9348acb1042d7d9386ff81 | volume   | volume         | Nova Volume Service       |

| 7b09782f9faf448781f5a460acabe258 | swift    | object-store   | Object Storage Service    |

| d6b32583a6694e9b828b2a50037623ba | keystone | identity       | Keystone Identity Service |

| f7f964a71e2a45119dcaede68fafbd78 | glance   | image          | Glance Image Service      |

+----------------------------------+----------+----------------+---------------------------+

</pre>

h1. Installing OpenStack Object Storage - Swift

OpenStack Object Storage (Swift) is a system to store objects in a massively

scalable large capacity system with built-in redundancy and failover. Object

Storage has a variety of applications, such as backing up or archiving data,

serving graphics or videos (streaming data to a user's browser), storing

secondary or tertiary static data, developing new applications with data

storage integration, storing data when predicting storage capacity is difficult,

and creating the elasticity and flexibility of cloud-based storage for your web

applications.

In this environment we use the same controller node as storage too. So the swift and swift-proxy is installed in the controller-node.

Install the swift and dependencies:

<pre>

# apt-get install swift python-xattr python-memcache rsync memcached python-netifaces

</pre>

Unfortunately at the time of writing this manual swift package not automates some tasks, such as the creation of configuration files. We have to do this manually:

<pre>

# mkdir /etc/swift

</pre>

Create the config file _/etc/swift/swift.conf_:

<pre>

[swift-hash]

# random unique string that can never change (DO NOT LOSE)

swift_hash_path_suffix = fLIbertYgibbitZ

</pre>

h2. Install and configure the "object-nodes"

In this case, the object-nodes (computer when data are stored) is the same cloud-controller.

<pre>

# apt-get install swift-account swift-container swift-object xfsprogs

</pre>

Each "Object node" can have many devices Is a requisite use xfs file system.

<pre>

# fdisk /dev/sdb (set up a single partition)

# mkfs.xfs -i size=1024 /dev/sdb1

</pre>

This device should be mount at /srv/node/

<pre>

echo "/dev/sdb1 /srv/node/sdb1 xfs noatime,nodiratime,nobarrier,logbufs=8 0 0" >> /etc/fstab

mkdir -p /srv/node/sdb1

mount /srv/node/sdb1

chown -R swift:swift /srv/node

</pre>

h2. Configure the _rsyncd.conf_

<pre>

uid = swift

gid = swift

log file = /var/log/rsyncd.log

pid file = /var/run/rsyncd.pid

address = 192.168.69.1

[account]

max connections = 2

path = /srv/node/

read only = false

lock file = /var/lock/account.lock

[container]

max connections = 2

path = /srv/node/

read only = false

lock file = /var/lock/container.lock

[object]

max connections = 2

path = /srv/node/

read only = false

lock file = /var/lock/object.lock

</pre>

Edit the _/etc/default/rsync_:

<pre>

RSYNC_ENABLE = true

</pre>

Restart the rsync:

<pre>

service rsync restart

</pre>

Create the _/etc/swift/account-server.conf_:

<pre>

[DEFAULT]

bind_ip = 192.168.69.1

workers = 2

[pipeline:main]

pipeline = account-server

[app:account-server]

use = egg:swift#account

[account-replicator]

[account-auditor]

[account-reaper]

</pre>

Create the _/etc/swift/container-server.conf_:

<pre>

[DEFAULT]

bind_ip = 192.168.69.1

workers = 2

[pipeline:main]

pipeline = container-server

[app:container-server]

use = egg:swift#container

[container-replicator]

[container-updater]

[container-auditor]

</pre>

Create the _/etc/swift/object-server.conf_:

<pre>

[DEFAULT]

bind_ip = 192.168.69.1

workers = 2

[pipeline:main]

pipeline = object-server

[app:object-server]

use = egg:swift#object

[object-replicator]

[object-updater]

[object-auditor]

</pre>

h2. Installing and configuring the swift-proxy

The swift-proxy is the component that acts like a proxy, so you can have multiple object-nodes and one swift-proxy. When an user or openStack component need get a object, its ask for swift-proxy.

Install swift-proxy:

<pre>

# apt-get install swift-proxy memcached

</pre>

Create a self-sign SSL certificate:

<pre>

cd /etc/swift

openssl req -new -x509 -nodes -out cert.crt -keyout cert.key

</pre>

Change the memcached to listen in correct interface, change the /etc/memcached.conf:

<pre>

-l 127.0.0.1

to

-l 192.168.69.1

</pre>

Restart the memcached:

<pre>

service memcached restart

</pre>

Create the file _/etc/swift/proxy-server.conf_:

<pre>

[DEFAULT]

bind_port = 8888

user = swift

[pipeline:main]

pipeline = catch_errors healthcheck cache authtoken keystone proxy-server

[app:proxy-server]

use = egg:swift#proxy

account_autocreate = true

[filter:keystone]

paste.filter_factory = keystone.middleware.swift_auth:filter_factory

operator_roles = admin, swiftoperator

[filter:authtoken]

paste.filter_factory = keystone.middleware.auth_token:filter_factory

# Delaying the auth decision is required to support token-less

# usage for anonymous referrers ('.r:*').

delay_auth_decision = 10

service_port = 5000

service_host = 192.168.69.1

auth_port = 35357

auth_host = 192.168.69.1

auth_token = 012345SECRET99TOKEN012345

admin_token = 012345SECRET99TOKEN012345

auth_protocol = http

[filter:cache]

use = egg:swift#memcache

set log_name = cache

[filter:catch_errors]

use = egg:swift#catch_errors

[filter:healthcheck]

use = egg:swift#healthcheck

</pre>

Create the account, container and object rings. The builder command is basically creating a builder file with a few parameters. The parameter with the value of 18 represents 2 ^ 18th, the value that the partition will be sized to. Set this "partition power" value based on the total amount of storage you expect your entire ring to use. The value of 1 represents the number of replicas of each object, with the last value being the number of hours to restrict moving a partition more than once.

<pre>

cd /etc/swift

swift-ring-builder account.builder create 18 1 1

swift-ring-builder container.builder create 18 1 1

swift-ring-builder object.builder create 18 1 1

</pre>

For every storage device on each node add entries to each ring:

<pre>

swift-ring-builder account.builder add z<ZONE>-<STORAGE_LOCAL_NET_IP>:6002/<DEVICE> 100

swift-ring-builder container.builder add z<ZONE>-<STORAGE_LOCAL_NET_IP_1>:6001/<DEVICE> 100

swift-ring-builder object.builder add z<ZONE>-<STORAGE_LOCAL_NET_IP_1>:6000/<DEVICE> 100

</pre>

In our case, we have only one zone in one storage node with one device (sdb1), so the command should be:

<pre>

swift-ring-builder account.builder add z1-192.168.69.1:6002/sdb1 100

swift-ring-builder container.builder add z1-192.168.69.1:6001/sdb1 100

swift-ring-builder object.builder add z1-192.168.69.1:6000/sdb1 100

</pre>

Verify the ring contents for each ring:

<pre>

swift-ring-builder account.builder

swift-ring-builder container.builder

swift-ring-builder object.builder

</pre>

Rebalance the rings:

<pre>

swift-ring-builder account.builder rebalance

swift-ring-builder container.builder rebalance

swift-ring-builder object.builder rebalance

</pre>

Change the permissions of config files:

<pre>

# chown -R swift:swift /etc/swift/

</pre>

Start the swift-proxy:

<pre>

swift-init proxy start

</pre>

Start all swift services:

<pre>

swift-init main start

swift-init rest start

</pre>

h2. Checking the installation

The file _/root/openstackrc_ will receive more environment variables:

<pre>

# Used for Keystone

export SERVICE_ENDPOINT=http://192.168.69.1:35357/v2.0/

export SERVICE_TOKEN=012345SECRET99TOKEN012345

# Used for swift

export ST_AUTH=http://192.168.69.1:5000/v2.0

export ST_USER=openstackDemo:admin

export ST_KEY=adminpass

export OS_REGION_NAME=RegionOne

</pre>

Reload the file:

<pre>

# source /root/openstackrc

</pre>

Try to get swift status, with the command:

<pre>

# swift -V 2.0 stat

</pre>

List the containers:

<pre>

# swift -V 2.0 list

</pre>

Do some upload files:

<pre>

# swift -V 2.0 upload myfiles bigfile1.tgz

# swift -V 2.0 upload myfiles bigfile2.tgz

</pre>

Download the container "myfiles":

<pre>

# cd /tmp/

# swift -V 2.0 download myfiles

</pre>

h1. Installing OpenStack Image Service - Glance

OpenStack Image Service (Glance) is a lookup and retrieval system for virtual

machine images. It can be configured in three ways: using OpenStack Object Store

to store images; using Amazon's Simple Storage Solution (S3) storage directly;

or using S3 storage with Object Store as the intermediate for S3 access.

Install the glance on the controller node:

<pre>

# apt-get install glance

</pre>

Remove the sqlite file:

<pre>

# rm /var/lib/glance/glance.sqlite

</pre>

h2. Configuring the Image Service database backend

<pre>

# mysql -u root -p

mysql> CREATE DATABASE glance;

mysql> GRANT ALL ON glance.* TO 'glance'@'%' IDENTIFIED BY 'glancepass';

mysql> FLUSH PRIVILEGES;

mysql> quit;

</pre>

Copy the config files to _/etc/glance/_:

*/etc/glance/glance-api.conf*:

<pre>

[DEFAULT]

# Show more verbose log output (sets INFO log level output)

verbose = True

# Show debugging output in logs (sets DEBUG log level output)

debug = False

# Which backend store should Glance use by default is not specified

# in a request to add a new image to Glance? Default: 'file'

# Available choices are 'file', 'swift', and 's3'

default_store = swift

# Address to bind the API server

bind_host = 0.0.0.0

# Port the bind the API server to

bind_port = 9292

# Log to this file. Make sure you do not set the same log

# file for both the API and registry servers!

log_file = /var/log/glance/api.log

# Backlog requests when creating socket

backlog = 4096

# Number of Glance API worker processes to start.

# On machines with more than one CPU increasing this value

# may improve performance (especially if using SSL with

# compression turned on). It is typically recommended to set

# this value to the number of CPUs present on your machine.

workers = 0

# Role used to identify an authenticated user as administrator

#admin_role = admin

# ================= Syslog Options ============================

# Send logs to syslog (/dev/log) instead of to file specified

# by `log_file`

use_syslog = False

# Facility to use. If unset defaults to LOG_USER.

# syslog_log_facility = LOG_LOCAL0

# ================= SSL Options ===============================

# Certificate file to use when starting API server securely

# cert_file = /path/to/certfile

# Private key file to use when starting API server securely

# key_file = /path/to/keyfile

# ================= Security Options ==========================

# AES key for encrypting store 'location' metadata, including

# -- if used -- Swift or S3 credentials

# Should be set to a random string of length 16, 24 or 32 bytes

# metadata_encryption_key = <16, 24 or 32 char registry metadata key>

# ============ Registry Options ===============================

# Address to find the registry server

registry_host = 0.0.0.0

# Port the registry server is listening on

registry_port = 9191

# What protocol to use when connecting to the registry server?

# Set to https for secure HTTP communication

registry_client_protocol = http

# The path to the key file to use in SSL connections to the

# registry server, if any. Alternately, you may set the

# GLANCE_CLIENT_KEY_FILE environ variable to a filepath of the key file

# registry_client_key_file = /path/to/key/file

# The path to the cert file to use in SSL connections to the

# registry server, if any. Alternately, you may set the

# GLANCE_CLIENT_CERT_FILE environ variable to a filepath of the cert file

# registry_client_cert_file = /path/to/cert/file

# The path to the certifying authority cert file to use in SSL connections

# to the registry server, if any. Alternately, you may set the

# GLANCE_CLIENT_CA_FILE environ variable to a filepath of the CA cert file

# registry_client_ca_file = /path/to/ca/file

# ============ Notification System Options =====================

# Notifications can be sent when images are create, updated or deleted.

# There are three methods of sending notifications, logging (via the

# log_file directive), rabbit (via a rabbitmq queue), qpid (via a Qpid

# message queue), or noop (no notifications sent, the default)

notifier_strategy = noop

# Configuration options if sending notifications via rabbitmq (these are

# the defaults)

rabbit_host = localhost

rabbit_port = 5672

rabbit_use_ssl = false

rabbit_userid = guest

rabbit_password = guest

rabbit_virtual_host = /

rabbit_notification_exchange = glance

rabbit_notification_topic = glance_notifications

# Configuration options if sending notifications via Qpid (these are

# the defaults)

qpid_notification_exchange = glance

qpid_notification_topic = glance_notifications

qpid_host = localhost

qpid_port = 5672

qpid_username =

qpid_password =

qpid_sasl_mechanisms =

qpid_reconnect_timeout = 0

qpid_reconnect_limit = 0

qpid_reconnect_interval_min = 0

qpid_reconnect_interval_max = 0

qpid_reconnect_interval = 0

qpid_heartbeat = 5

# Set to 'ssl' to enable SSL

qpid_protocol = tcp

qpid_tcp_nodelay = True

# ============ Filesystem Store Options ========================

# Directory that the Filesystem backend store

# writes image data to

filesystem_store_datadir = /var/lib/glance/images/

# ============ Swift Store Options =============================

# Version of the authentication service to use

# Valid versions are '2' for keystone and '1' for swauth and rackspace

swift_store_auth_version = 2

# Address where the Swift authentication service lives

# Valid schemes are 'http://' and 'https://'

# If no scheme specified,  default to 'https://'

# For swauth, use something like '127.0.0.1:8080/v1.0/'

swift_store_auth_address = http://192.168.69.1:35357/v2.0/

# User to authenticate against the Swift authentication service

# If you use Swift authentication service, set it to 'account':'user'

# where 'account' is a Swift storage account and 'user'

# is a user in that account

swift_store_user = service:glance

# Auth key for the user authenticating against the