233864ff32
The publishing docs expect the documentation to be present in the /doc directory not the /docs directory. If the documentation is in the /docs directory, according to fungi the docs won't be published properly. Change-Id: I718fec7e69d298a5cb2376ca4e2455e12169566e Partially-Implements: blueprint kola-tox-doc
131 lines
4.5 KiB
ReStructuredText
131 lines
4.5 KiB
ReStructuredText
Swift in Kolla
|
|
==============
|
|
|
|
Overview
|
|
--------
|
|
Currently Kolla can deploy the "core" services required for a working Swift, in either an AIO or
|
|
multi node setup:
|
|
|
|
- swift-proxy
|
|
- swift-account
|
|
- swift-container
|
|
- swift-object
|
|
|
|
There are a variety of other services such the replicator, expirer, rsyncd, etc. which actually make
|
|
Swift useful, which are in progress and hope to be finished in liberty-rc1.
|
|
|
|
Prerequisites
|
|
-------------
|
|
Before running Swift we need to generate "rings", which are binary compressed files that at a high
|
|
level let the various Swift services know where data is in the cluster. Again, we hope to be able to
|
|
generate these automatically for liberty-rc1.
|
|
|
|
Swift also expects block devices to be available and partitioned on the host, which Swift uses in
|
|
combination with the rings to store data. Swift demos commonly just use directories created under
|
|
/srv/node to simulate these devices. In order to ease "out of the box" testing of Kolla, we offer a
|
|
similar setup with a data container. *Note*, data containers are very inefficient for this purpose.
|
|
In production setups operators will want to provision disks according to the Swift operator guide,
|
|
which can then be added the rings and used in Kolla.
|
|
|
|
For an AIO setup, the following commands can be used, locally, to generate rings containing the data
|
|
container directories:
|
|
|
|
::
|
|
|
|
export KOLLA_INTERNAL_ADDRESS=1.2.3.4
|
|
|
|
# Object ring
|
|
docker run \
|
|
-v /etc/kolla/config/swift/:/etc/kolla/config/swift/ \
|
|
kollaglue/centos-binary-swift-base \
|
|
swift-ring-builder /etc/kolla/config/swift/object.builder create 10 3 1
|
|
|
|
for partition in sdb1 sdb2 sdb3; do
|
|
docker run \
|
|
-v /etc/kolla/config/swift/:/etc/kolla/config/swift/ \
|
|
kollaglue/centos-binary-swift-base swift-ring-builder \
|
|
/etc/kolla/config/swift/object.builder add z1-${KOLLA_INTERNAL_ADDRESS}:6000/${partition} 1
|
|
done
|
|
|
|
# Account ring
|
|
docker run \
|
|
-v /etc/kolla/config/swift/:/etc/kolla/config/swift/ \
|
|
kollaglue/centos-binary-swift-base \
|
|
swift-ring-builder /etc/kolla/config/swift/account.builder create 10 3 1
|
|
|
|
for partition in sdb1 sdb2 sdb3; do
|
|
docker run \
|
|
-v /etc/kolla/config/swift/:/etc/kolla/config/swift/ \
|
|
kollaglue/centos-binary-swift-base swift-ring-builder \
|
|
/etc/kolla/config/swift/account.builder add z1-${KOLLA_INTERNAL_ADDRESS}:6001/${partition} 1
|
|
done
|
|
|
|
# Container ring
|
|
docker run \
|
|
-v /etc/kolla/config/swift/:/etc/kolla/config/swift/ \
|
|
kollaglue/centos-binary-swift-base \
|
|
swift-ring-builder /etc/kolla/config/swift/container.builder create 10 3 1
|
|
|
|
for partition in sdb1 sdb2 sdb3; do
|
|
docker run \
|
|
-v /etc/kolla/config/swift/:/etc/kolla/config/swift/ \
|
|
kollaglue/centos-binary-swift-base swift-ring-builder \
|
|
/etc/kolla/config/swift/container.builder add z1-${KOLLA_INTERNAL_ADDRESS}:6002/${partition} 1
|
|
done
|
|
|
|
for ring in object account container; do
|
|
docker run \
|
|
-v /etc/kolla/config/swift/:/etc/kolla/config/swift/ \
|
|
kollaglue/centos-binary-swift-base swift-ring-builder \
|
|
/etc/kolla/config/swift/${ring}.builder rebalance
|
|
done
|
|
|
|
Similar commands can be used for multinode, you will just need to run the the 'add' step for each IP
|
|
in the cluster.
|
|
|
|
For more info, see
|
|
http://docs.openstack.org/kilo/install-guide/install/apt/content/swift-initial-rings.html
|
|
|
|
Deploying
|
|
---------
|
|
Once the rings are in place, deploying Swift is the same as any other Kolla Ansible service. Below
|
|
is the minimal command to bring up Swift AIO, and it's dependencies:
|
|
|
|
::
|
|
|
|
ansible-playbook \
|
|
-i ansible/inventory/all-in-one \
|
|
-e @/etc/kolla/globals.yml \
|
|
-e @etc/kolla/passwords.yml \
|
|
ansible/site.yml \
|
|
--tags=rabbitmq,mariadb,keystone,swift
|
|
|
|
Validation
|
|
----------
|
|
A very basic smoke test:
|
|
|
|
::
|
|
|
|
$ swift stat
|
|
Account: AUTH_4c19d363b9cf432a80e34f06b1fa5749
|
|
Containers: 1
|
|
Objects: 0
|
|
Bytes: 0
|
|
Containers in policy "policy-0": 1
|
|
Objects in policy "policy-0": 0
|
|
Bytes in policy "policy-0": 0
|
|
X-Account-Project-Domain-Id: default
|
|
X-Timestamp: 1440168098.28319
|
|
X-Trans-Id: txf5a62b7d7fc541f087703-0055d73be7
|
|
Content-Type: text/plain; charset=utf-8
|
|
Accept-Ranges: bytes
|
|
|
|
$ swift upload mycontainer README.rst
|
|
README.md
|
|
|
|
$ swift list
|
|
mycontainer
|
|
|
|
$ swift download mycontainer README.md
|
|
README.md [auth 0.248s, headers 0.939s, total 0.939s, 0.006 MB/s]
|