clearlinux/clear-linux-documentation
2
0
Fork 0
mirror of https://github.com/clearlinux/clear-linux-documentation.git synced 2026-09-05 21:31:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

Delete old openstack docs

Browse Source 
Signed-off-by: Leoswaldo Macias <leoswaldo.macias@intel.com>
This commit is contained in:
Leoswaldo Macias
2016-03-31 11:23:50 -06:00
parent ed1e936f54
commit 22067e6126
15 changed files with 1 additions and 4097 deletions
Download Patch File Download Diff File Expand all files Collapse all files
source/openstack_block_storage.rst
-478
View File
@@ -1,478 +0,0 @@
.. _openstack_block_storage:
Block Storage
########################
The OpenStack* Block Storage service (cinder) adds persistent storage to
a virtual machine. Block Storage provides an infrastructure for managing
volumes, and interacts with OpenStack Compute to provide volumes for
instances. The service also enables management of volume snapshots and
volume types.
Install and configure controller node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This section describes how to install and configure the Block
Storage service, code-named cinder, on the controller node. This
service requires at least one additional storage node that provides
volumes to instances.
Prerequisites:
--------------
Before you install and configure the Block Storage service, you
must create a database, service credentials, and API endpoints.
#. To create the database, complete these steps:
* Use the database access client to connect to the database
server as the ``root`` user::
$ mysql -u root -p
* Create the ``cinder`` database::
CREATE DATABASE cinder;
* Grant proper access to the ``cinder`` database::
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'localhost' \
IDENTIFIED BY 'CINDER_DBPASS';
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'%' \
IDENTIFIED BY 'CINDER_DBPASS';
Replace ``CINDER_DBPASS`` with a suitable password.
* Exit the database access client.
#. Source the ``admin`` credentials to gain access to admin-only
CLI commands::
$ source admin-openrc.sh
#. To create the service credentials, complete these steps:
* Create a ``cinder`` user::
$ openstack user create --domain default --password-prompt cinder
User Password:
Repeat User Password:
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | default |
| enabled | True |
| id | bb279f8ffc444637af38811a5e1f0562 |
| name | cinder |
+-----------+----------------------------------+
* Add the ``admin`` role to the ``cinder`` user::
$ openstack role add --project service --user cinder admin
* Create the ``cinder`` and ``cinderv2`` service entities::
$ openstack service create --name cinder \
--description "OpenStack Block Storage" volume
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | OpenStack Block Storage |
| enabled | True |
| id | ab3bbbef780845a1a283490d281e7fda |
| name | cinder |
| type | volume |
+-------------+----------------------------------+
$ openstack service create --name cinderv2 \
--description "OpenStack Block Storage" volumev2
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | OpenStack Block Storage |
| enabled | True |
| id | eb9fd245bdbc414695952e93f29fe3ac |
| name | cinderv2 |
| type | volumev2 |
+-------------+----------------------------------+
.. note::
The Block Storage services requires two service entities.
#. Create the Block Storage service API endpoints::
$ openstack endpoint create --region RegionOne \
volume public http://controller:8776/v1/%\(tenant_id\)s
+--------------+-----------------------------------------+
| Field | Value |
+--------------+-----------------------------------------+
| enabled | True |
| id | 03fa2c90153546c295bf30ca86b1344b |
| interface | public |
| region | RegionOne |
| region_id | RegionOne |
| service_id | ab3bbbef780845a1a283490d281e7fda |
| service_name | cinder |
| service_type | volume |
| url | http://controller:8776/v1/%(tenant_id)s |
+--------------+-----------------------------------------+
$ openstack endpoint create --region RegionOne \
volume internal http://controller:8776/v1/%\(tenant_id\)s
+--------------+-----------------------------------------+
| Field | Value |
+--------------+-----------------------------------------+
| enabled | True |
| id | 94f684395d1b41068c70e4ecb11364b2 |
| interface | internal |
| region | RegionOne |
| region_id | RegionOne |
| service_id | ab3bbbef780845a1a283490d281e7fda |
| service_name | cinder |
| service_type | volume |
| url | http://controller:8776/v1/%(tenant_id)s |
+--------------+-----------------------------------------+
$ openstack endpoint create --region RegionOne \
volume admin http://controller:8776/v1/%\(tenant_id\)s
+--------------+-----------------------------------------+
| Field | Value |
+--------------+-----------------------------------------+
| enabled | True |
| id | 4511c28a0f9840c78bacb25f10f62c98 |
| interface | admin |
| region | RegionOne |
| region_id | RegionOne |
| service_id | ab3bbbef780845a1a283490d281e7fda |
| service_name | cinder |
| service_type | volume |
| url | http://controller:8776/v1/%(tenant_id)s |
+--------------+-----------------------------------------+
$ openstack endpoint create --region RegionOne \
volumev2 public http://controller:8776/v2/%\(tenant_id\)s
+--------------+-----------------------------------------+
| Field | Value |
+--------------+-----------------------------------------+
| enabled | True |
| id | 513e73819e14460fb904163f41ef3759 |
| interface | public |
| region | RegionOne |
| region_id | RegionOne |
| service_id | eb9fd245bdbc414695952e93f29fe3ac |
| service_name | cinderv2 |
| service_type | volumev2 |
| url | http://controller:8776/v2/%(tenant_id)s |
+--------------+-----------------------------------------+
$ openstack endpoint create --region RegionOne \
volumev2 internal http://controller:8776/v2/%\(tenant_id\)s
+--------------+-----------------------------------------+
| Field | Value |
+--------------+-----------------------------------------+
| enabled | True |
| id | 6436a8a23d014cfdb69c586eff146a32 |
| interface | internal |
| region | RegionOne |
| region_id | RegionOne |
| service_id | eb9fd245bdbc414695952e93f29fe3ac |
| service_name | cinderv2 |
| service_type | volumev2 |
| url | http://controller:8776/v2/%(tenant_id)s |
+--------------+-----------------------------------------+
$ openstack endpoint create --region RegionOne \
volumev2 admin http://controller:8776/v2/%\(tenant_id\)s
+--------------+-----------------------------------------+
| Field | Value |
+--------------+-----------------------------------------+
| enabled | True |
| id | e652cf84dd334f359ae9b045a2c91d96 |
| interface | admin |
| region | RegionOne |
| region_id | RegionOne |
| service_id | eb9fd245bdbc414695952e93f29fe3ac |
| service_name | cinderv2 |
| service_type | volumev2 |
| url | http://controller:8776/v2/%(tenant_id)s |
+--------------+-----------------------------------------+
.. note::
The Block Storage services requires endpoints for each service
entity.
Install and configure components
--------------------------------
#. Install OpenStack Block Storage Controller bundle::
# swupd bundle-add openstack-block-storage-controller
#. Custom configurations will be located at ``/etc/cinder``.
* Create ``/etc/cinder`` directory::
# mkdir /etc/cinder
* Create empty cinder configuration file in
``/etc/cinder/cinder.conf``::
# touch /etc/cinder/cinder.conf
#. Edit the ``/etc/cinder/cinder.conf`` file and complete the following
actions:
* In the ``[database]`` section, configure database access. Replace
``CINDER_DBPASS`` with the password you chose for the
database::
[database]
...
connection=mysql://cinder:CINDER_DBPASS@controller/cinder
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` section,
configure RabbitMQ message queue access. Replace ``RABBIT_PASS``
with the password you chose for the account in
RabbitMQ::
[DEFAULT]
...
rpc_backend = rabbit
[oslo_messaging_rabbit]
...
rabbit_host = controller
rabbit_userid = openstack
rabbit_password = RABBIT_PASS
* In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections, configure
Identity service access. Replace ``CINDER_PASS`` with the password you
chose for the ``cinder`` user in the Identity service.::
[DEFAULT]
...
auth_strategy = keystone
[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = cinder
password = CINDER_PASS
* In the ``[DEFAULT]`` section, configure the ``my_ip`` option to
use the management interface IP address of the controller node::
[DEFAULT]
...
my_ip = 10.0.0.11
#. Populate the Block Storage database::
# su -s /bin/sh -c "cinder-manage db sync" cinder
Configure Compute to use Block Storage
--------------------------------------
* Edit the ``/etc/nova/nova.conf`` file and add the following
to it::
[cinder]
os_region_name = RegionOne
Finalize installation
---------------------
#. Restart the Compute API service::
# systemctl restart uwsgi@nova-api.service
#. Start the Block Storage services and configure them to start when
the system boots::
# systemctl enable cinder-api cinder-scheduler
# systemctl start cinder-api cinder-scheduler
Install and configure a storage node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This section describes how to install and configure storage nodes
for the Block Storage service. For simplicity, this configuration
references one storage node with an empty local block storage device.
The instructions use ``/dev/sdb``, but you can substitute a different
value for your particular node.
The service provisions logical volumes on this device using the
LVM driver and provides them to instances via iSCSI transport.
You can follow these instructions with minor modifications to
horizontally scale your environment with additional storage nodes.
Prerequisites
-------------
#. Install the Openstack Block Storage bundle::
# swupd bundle-add openstack-block-storage
#. Create the LVM physical volume: ``/dev/sdb1`` If your system uses a
different device name, adjust these steps accordingly::
# pvcreate /dev/sdb1
Physical volume "/dev/sdb1" successfully created
#. Create the LVM volume group ``cinder-volumes``::
# vgcreate cinder-volumes /dev/sdb1
Volume group "cinder-volumes" successfully created
The Block Storage service creates logical volumes in this volume
group.
#. Only instances can access Block Storage volumes. However, the
underlying operating system manages the devices associated with the
volumes. By default, the LVM volume scanning tool scans the ``/dev``
directory for block storage devices that contain volumes. If projects
use LVM on their volumes, the scanning tool detects these volumes and
attempts to cache them which can cause a variety of problems with
both the underlying operating system and project volumes. You must
reconfigure LVM to scan only the devices that contain the
``cinder-volume`` volume group. Edit the ``/etc/lvm/lvm.conf`` file
and complete the following action:
* In the ``devices`` section, add a filter that accepts the
``/dev/sdb`` device and rejects all other devices::
devices {
...
filter = [ "a/sdb/", "r/.*/"]
Install and configure components
--------------------------------
#. Edit the ``/etc/cinder/cinder.conf`` file and complete the following
actions:
* In the ``[database]`` section, configure database access. Replace
``CINDER_DBPASS`` with the password you chose for the Block Storage
database::
[database]
...
connection = mysql://cinder:CINDER_DBPASS@controller/cinder
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections,
configure ``RabbitMQ`` message queue access. Replace ``RABBIT_PASS``
with the password you chose for the openstack account in
``RabbitMQ``::
[DEFAULT]
...
rpc_backend = rabbit
[oslo_messaging_rabbit]
...
rabbit_host = controller
rabbit_userid = openstack
rabbit_password = RABBIT_PASS
* In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections,
configure Identity service access. Replace ``CINDER_PASS`` with the
password you chose for the cinder user in the Identity service::
[DEFAULT]
...
auth_strategy = keystone
[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = cinder
password = CINDER_PASS
* In the ``[DEFAULT]`` section, configure the ``my_ip`` option.
Replace ``MANAGEMENT_INTERFACE_IP_ADDRESS`` with the IP address
of the management network interface on your storage node,
typically 10.0.0.41 for the first node in the example
architecture::
[DEFAULT]
...
my_ip = MANAGEMENT_INTERFACE_IP_ADDRESS
* In the ``[lvm]`` section, configure the LVM back end with the LVM
driver, ``cinder-volumes`` volume group, iSCSI protocol, and
appropriate iSCSI service::
[lvm]
...
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_group = cinder-volumes
iscsi_protocol = iscsi
iscsi_helper = tgtadm
* In the ``[DEFAULT]`` section, enable the LVM back end::
[DEFAULT]
...
enabled_backends = lvm
* In the ``[DEFAULT]`` section, configure the location of the Image
service::
[DEFAULT]
...
glance_host = controller
#. Ensure files have proper ownership by running the following command::
# systemctl restart update-triggers.target
Finalize installation
---------------------
#. Start the Block Storage volume service including its dependencies
and configure them to start when the system boots::
# systemctl enable iscsid tgtd cinder-volume
# systemctl start iscsid tgtd cinder-volume
Configuring a compute node to use Block Storage
-----------------------------------------------
#. Perform the following steps to enable a compute node to work with
block storage::
# systemctl enable iscsid
# systemctl start iscsi-gen-initiatorname iscsid
Verify operation
~~~~~~~~~~~~~~~~
Verify operation of the Block Storage service.
#. Source the ``admin`` credentials to gain access to
admin-only CLI commands::
$ source admin-openrc.sh
#. List service components to verify successful launch of each process::
$ cinder service-list
+------------------+------------+------+---------+-------+----------------------------+-----------------+
| Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
+------------------+------------+------+---------+-------+----------------------------+-----------------+
| cinder-scheduler | controller | nova | enabled | up | 2014-10-18T01:30:54.000000 | None |
| cinder-volume | block1@lvm | nova | enabled | up | 2014-10-18T01:30:57.000000 | None |
+------------------+------------+------+---------+-------+----------------------------+-----------------+
Next topic: :ref:`openstack_dashboard`.
source/openstack_bundle_and_service_summary.rst
+1 -1
View File
@@ -63,4 +63,4 @@ uses a two-node architecture.
using overlay segmentation methods. Additionally, this option provides
the foundation for advanced services such as LBaaS and FWaaS.
Next topic: :ref:`openstack_sys_req_and_pw_summary`.
Next topic: :ref:``.
source/openstack_compute.rst
-527
View File
@@ -1,527 +0,0 @@
.. _openstack_compute:
Compute
##################
Use OpenStack Compute to host and manage cloud computing systems.
OpenStack Compute interacts with OpenStack Identity for authentication,
OpenStack Image Service for disk and server images, and OpenStack
Dashboard for the user and administrative interface. Image access is
limited by projects, and by users; quotas are limited per project (the
number of instances, for example). OpenStack Compute can scale
horizontally on standard hardware and download images to launch
instances.
Install and configure controller node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This section describes how to install and configure the
Compute service, code-named nova, on the controller node.
Prerequisites
-------------
Before you install and configure the Compute service, you must
create a database, service credentials, and API endpoints.
#. To create the database, complete these steps:
* Use the database access client to connect to the database server
as the root user::
$ mysql -u root -p
* Create the ``nova`` database::
CREATE DATABASE nova;
* Grant proper access to the nova database. Replace ``NOVA_DBPASS``
with a suitable password::
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' \
IDENTIFIED BY 'NOVA_DBPASS';
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' \
IDENTIFIED BY 'NOVA_DBPASS';
* Exit the database access client.
#. Source the admin credentials to gain access to admin-only CLI
commands::
$ source admin-openrc.sh
#. To create the service credentials, complete these steps:
* Create the ``nova`` user::
$ openstack user create --domain default --password-prompt nova
User Password:
Repeat User Password:
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | default |
| enabled | True |
| id | 8c46e4760902464b889293a74a0c90a8 |
| name | nova |
+-----------+----------------------------------+
* Add the ``admin`` role to the ``nova`` user::
$ openstack role add --project service --user nova admin
* Create the ``nova`` service entity::
$ openstack service create --name nova \
--description "OpenStack Compute" compute
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | OpenStack Compute |
| enabled | True |
| id | 060d59eac51b4594815603d75a00aba2 |
| name | nova |
| type | compute |
+-------------+----------------------------------+
#. Create the Compute service API endpoints::
$ openstack endpoint create --region RegionOne \
compute public http://controller:8774/v2/%\(tenant_id\)s
+--------------+-----------------------------------------+
| Field | Value |
+--------------+-----------------------------------------+
| enabled | True |
| id | 3c1caa473bfe4390a11e7177894bcc7b |
| interface | public |
| region | RegionOne |
| region_id | RegionOne |
| service_id | e702f6f497ed42e6a8ae3ba2e5871c78 |
| service_name | nova |
| service_type | compute |
| url | http://controller:8774/v2/%(tenant_id)s |
+--------------+-----------------------------------------+
$ openstack endpoint create --region RegionOne \
compute internal http://controller:8774/v2/%\(tenant_id\)s
+--------------+-----------------------------------------+
| Field | Value |
+--------------+-----------------------------------------+
| enabled | True |
| id | e3c918de680746a586eac1f2d9bc10ab |
| interface | internal |
| region | RegionOne |
| region_id | RegionOne |
| service_id | e702f6f497ed42e6a8ae3ba2e5871c78 |
| service_name | nova |
| service_type | compute |
| url | http://controller:8774/v2/%(tenant_id)s |
+--------------+-----------------------------------------+
$ openstack endpoint create --region RegionOne \
compute admin http://controller:8774/v2/%\(tenant_id\)s
+--------------+-----------------------------------------+
| Field | Value |
+--------------+-----------------------------------------+
| enabled | True |
| id | 38f7af91666a47cfb97b4dc790b94424 |
| interface | admin |
| region | RegionOne |
| region_id | RegionOne |
| service_id | e702f6f497ed42e6a8ae3ba2e5871c78 |
| service_name | nova |
| service_type | compute |
| url | http://controller:8774/v2/%(tenant_id)s |
+--------------+-----------------------------------------+
Installing and configuring the Compute controller components
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To install and configure the Compute controller components:
#. Install OpenStack Compute Controller bundle::
# swupd bundle-add openstack-compute-controller
#. Custom configurations will be located at ``/etc/nova``.
* Create ``/etc/nova directory``::
# mkdir /etc/nova
* Create empty nova configuration file ``/etc/nova/nova.conf``::
# touch /etc/nova/nova.conf
#. Edit the ``/etc/nova/nova.conf`` file and complete the following
actions:
* In the ``[database]`` section, configure database access. Replace
``NOVA_DBPASS`` with the password you chose for the Compute database::
[database]
...
connection=mysql://nova:NOVA_DBPASS@controller/nova
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections,
configure ``RabbitMQ`` message queue access. Replace ``RABBIT_PASS``
with the password you chose for the guest account in RabbitMQ::
[DEFAULT]
...
rpc_backend = rabbit
[oslo_messaging_rabbit]
...
rabbit_host = controller
rabbit_userid = openstack
rabbit_password = RABBIT_PASS
* In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections,
configure Identity service access. Replace ``NOVA_PASS`` with the
password you chose for the nova user in the Identity service::
[DEFAULT]
...
auth_strategy = keystone
[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = nova
password = NOVA_PASS
* In the ``[DEFAULT]`` section, configure the ``my_ip`` option to
use the management interface IP address of the controller node::
[DEFAULT]
...
my_ip = 10.0.0.11
* In the ``[DEFAULT]`` section, enable support for the Networking service::
[DEFAULT]
...
network_api_class = nova.network.neutronv2.api.API
security_group_api = neutron
linuxnet_interface_driver = nova.network.linux_net.NeutronLinuxBridgeInterfaceDriver
firewall_driver = nova.virt.firewall.NoopFirewallDriver
* In the ``[vnc]`` section, configure the VNC proxy to use the
management interface IP address of the controller node::
[vnc]
...
vncserver_listen = 10.0.0.11
vncserver_proxyclient_address = 10.0.0.11
* In the ``[glance]`` section, configure the location of the
Image Service::
[glance]
...
host = controller
#. Ensure files have proper ownership by running the following command::
# systemctl restart update-triggers.target
#. Populate the Compute database::
su -s /bin/sh -c "nova-manage db sync" nova
Finalizing Compute installation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Complete the following steps to finalize Compute installation:
#. Create the ``/etc/nginx`` directory if doesn't exists and setup nova-api
and nova-metadata to start with the Nginx http server::
# mkdir -p /etc/nginx
# ln -s /usr/share/nginx/conf.d/nova-api.template /etc/nginx/nova-api.conf
#. Restart the Nginx server to reload new configurations::
# systemctl restart nginx
#. Start the Compute Service services and configure them to start
when the system boots::
# systemctl enable uwsgi@nova-api.socket \
uwsgi@nova-metadata.socket nova-cert.service \
nova-consoleauth.service nova-scheduler.service \
nova-conductor.service nova-novncproxy.service
# systemctl start uwsgi@nova-api.socket \
uwsgi@nova-metadata.socket nova-cert.service \
nova-consoleauth.service nova-scheduler.service \
nova-conductor.service nova-novncproxy.service
Install and configure a compute note
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This section describes how to install and configure the Compute service
on a compute node. This configuration uses the QEMU hypervisor with the
KVM extension on compute nodes that support hardware acceleration for
virtual machines.
Install and configure components
--------------------------------
#. Install OpenStack Compute bundle::
# clr_bundle_add openstack-compute
#. Custom configurations will be located at ``/etc/nova``.
* Create ``/etc/nova`` directory::
# mkdir /etc/nova
* Create empty nova configuration file ``/etc/nova/nova.conf``::
# touch /etc/nova/nova.conf
#. Edit the ``/etc/nova/nova.conf`` file and complete the following
actions:
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections,
configure RabbitMQ message broker access. Replace ``RABBIT_PASS``
with the password you chose for the ``openstack`` account in ``RabbitMQ``::
[DEFAULT]
...
rpc_backend = rabbit
[oslo_messaging_rabbit]
...
rabbit_host = controller
rabbit_userid = openstack
rabbit_password = RABBIT_PASS
* In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections,
configure Identity service access. Replace ``NOVA_PASS`` with the
password you chose for the nova user in the Identity service::
[DEFAULT]
...
auth_strategy = keystone
[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = nova
password = NOVA_PASS
* In the ``[DEFAULT]`` section, configure the ``my_ip`` option.
Replace ``MANAGEMENT_INTERFACE_IP_ADDRESS`` with the IP address of
the management network interface on your compute node, typically
``10.0.0.31`` for the first node in the example architecture::
[DEFAULT]
...
my_ip = MANAGEMENT_INTERFACE_IP_ADDRESS
* In the ``[DEFAULT]`` section, enable support for the Networking service::
[DEFAULT]
...
network_api_class = nova.network.neutronv2.api.API
security_group_api = neutron
linuxnet_interface_driver = nova.network.linux_net.NeutronLinuxBridgeInterfaceDriver
firewall_driver = nova.virt.firewall.NoopFirewallDriver
* In the ``[vnc]`` section, enable and configure remote console access::
[vnc]
...
enabled = True
vncserver_listen = 0.0.0.0
vncserver_proxyclient_address = MANAGEMENT_INTERFACE_IP_ADDRESS
novncproxy_base_url = http://controller:6080/vnc_auto.html
The server component listens on all IP addresses and the proxy
component only listens on the management interface IP address of
the compute node. The base URL indicates the location where you
can use a web browser to access remote consoles of instances on
this compute node.
* In the ``[glance]`` section, configure the location of the
Image Service::
[glance]
...
host = controller
Finalize compute node installation
----------------------------------
#. Determine whether your compute node supports hardware acceleration
for virtual machines::
$ egrep -c '(vmx|svm)' /proc/cpuinfo
If this command returns a value of ``one or greater``, your compute
node supports hardware acceleration which typically requires no
additional configuration.
If this command returns a value of ``zero`` , your compute node does
not support hardware acceleration and you must configure ``libvirt``
to use QEMU instead of KVM.
* Edit the ``[libvirt]`` section in the ``/etc/nova/nova.conf`` file
as follows::
[libvirt]
...
virt_type = qemu
#. Ensure files have proper ownership by running the following command::
# systemctl restart update-triggers.target
#. Start the Compute service including its dependencies and configure
them to start automatically when the system boots::
# systemctl enable libvirtd.service \
nova-compute.service
# systemctl start libvirtd.service \
nova-compute.service
Verify operation
~~~~~~~~~~~~~~~~
Verify operation of the Compute service.
*Note:* Perform these commands on the controller node.
#. Source the ``admin`` credentials to gain access to
admin-only CLI commands::
$ source admin-openrc.sh
#. List service components to verify successful launch and
registration of each process::
$ nova service-list
+----+------------------+------------+----------+---------+-------+--------------+-----------------+
| Id | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
+----+------------------+------------+----------+---------+-------+--------------+-----------------+
| 1 | nova-conductor | controller | internal | enabled | up | 2014-09-16.. | - |
| 2 | nova-consoleauth | controller | internal | enabled | up | 2014-09-16.. | - |
| 3 | nova-scheduler | controller | internal | enabled | up | 2014-09-16.. | - |
| 4 | nova-cert | controller | internal | enabled | up | 2014-09-16.. | - |
| 5 | nova-compute | compute1 | nova | enabled | up | 2014-09-16.. | - |
+----+------------------+------------+----------+---------+-------+--------------+-----------------+
#. List API endpoints in the Identity service to verify connectivity
with the Identity service::
$ nova endpoints
+-----------+------------------------------------------------------------+
| nova | Value |
+-----------+------------------------------------------------------------+
| id | 1fb997666b79463fb68db4ccfe4e6a71 |
| interface | public |
| region | RegionOne |
| region_id | RegionOne |
| url | http://controller:8774/v2/ae7a98326b9c455588edd2656d723b9d |
+-----------+------------------------------------------------------------+
+-----------+------------------------------------------------------------+
| nova | Value |
+-----------+------------------------------------------------------------+
| id | bac365db1ff34f08a31d4ae98b056924 |
| interface | admin |
| region | RegionOne |
| region_id | RegionOne |
| url | http://controller:8774/v2/ae7a98326b9c455588edd2656d723b9d |
+-----------+------------------------------------------------------------+
+-----------+------------------------------------------------------------+
| nova | Value |
+-----------+------------------------------------------------------------+
| id | e37186d38b8e4b81a54de34e73b43f34 |
| interface | internal |
| region | RegionOne |
| region_id | RegionOne |
| url | http://controller:8774/v2/ae7a98326b9c455588edd2656d723b9d |
+-----------+------------------------------------------------------------+
+-----------+----------------------------------+
| glance | Value |
+-----------+----------------------------------+
| id | 41ad39f6c6444b7d8fd8318c18ae0043 |
| interface | admin |
| region | RegionOne |
| region_id | RegionOne |
| url | http://controller:9292 |
+-----------+----------------------------------+
+-----------+----------------------------------+
| glance | Value |
+-----------+----------------------------------+
| id | 50ecc4ce62724e319f4fae3861e50f7d |
| interface | internal |
| region | RegionOne |
| region_id | RegionOne |
| url | http://controller:9292 |
+-----------+----------------------------------+
+-----------+----------------------------------+
| glance | Value |
+-----------+----------------------------------+
| id | 7d3df077a20b4461a372269f603b7516 |
| interface | public |
| region | RegionOne |
| region_id | RegionOne |
| url | http://controller:9292 |
+-----------+----------------------------------+
+-----------+----------------------------------+
| keystone | Value |
+-----------+----------------------------------+
| id | 88150c2fdc9d406c9b25113701248192 |
| interface | internal |
| region | RegionOne |
| region_id | RegionOne |
| url | http://controller:5000/v2.0 |
+-----------+----------------------------------+
+-----------+----------------------------------+
| keystone | Value |
+-----------+----------------------------------+
| id | cecab58c0f024d95b36a4ffa3e8d81e1 |
| interface | public |
| region | RegionOne |
| region_id | RegionOne |
| url | http://controller:5000/v2.0 |
+-----------+----------------------------------+
+-----------+----------------------------------+
| keystone | Value |
+-----------+----------------------------------+
| id | fc90391ae7cd4216aca070042654e424 |
| interface | admin |
| region | RegionOne |
| region_id | RegionOne |
| url | http://controller:35357/v2.0 |
+-----------+----------------------------------+
*Note:* Ignore any warnings in this output.
#. List images in the Image service catalog to verify connectivity
with the Image service::
$ nova image-list
+--------------------------------------+--------+--------+--------+
| ID | Name | Status | Server |
+--------------------------------------+--------+--------+--------+
| 38047887-61a7-41ea-9b49-27987d5e8bb9 | cirros | ACTIVE | |
+--------------------------------------+--------+--------+--------+
Next topic: :ref:`openstack_block_storage`.
source/openstack_dashboard.rst
-33
View File
@@ -1,33 +0,0 @@
.. _openstack_dashboard:
Dashboard
####################
The OpenStack* Dashboard, also known as Horizon, is a web-based interface
for cloud administrators and users to manage various OpenStack resources
and services.
The Dashboard enables web-based interactions with the
OpenStack Compute cloud controller through the OpenStack APIs.
Installation and configuration
------------------------------
The dashboard relies on functional core services including
Identity, Image service, Compute, and either Networking (neutron)
or legacy networking (nova-network). Environments with
stand-alone services such as Object Storage cannot use the
dashboard.
To get started with OpenStack Dashboard services:
#. Install the OpenStack Dashboard bundle::
# swupd bundle-add openstack-dashboard
#. Enable and start the dashboard socket and the Nginx server::
# systemctl enable nginx uwsgi@horizon.socket
# systemctl restart nginx uwsgi@horizon.socket
Next topic: :ref:`openstack_networking`.
source/openstack_identity-openrc.rst
-75
View File
@@ -1,75 +0,0 @@
.. _openstack_identity-openrc:
Create OpenStack* client environment scripts
############################################
The previous section used a combination of environment variables and
command options to interact with the Identity service via the
``openstack`` client. To increase efficiency of client operations,
OpenStack supports simple client environment scripts also known as
OpenRC files. These scripts typically contain common options for
all clients but also support unique options. For more information, see the
`OpenStack User Guide <http://docs.openstack.org/user-guide/common/
cli_set_environment_variables_using_openstack_rc.html>`__.
Creating the scripts
--------------------
Create client environment scripts for the ``admin`` and ``demo``
projects and users. Future portions of this guide reference these
scripts to load appropriate credentials for client operations.
#. Create the ``admin-openrc.sh`` file and add the following content::
export OS_PROJECT_DOMAIN_ID=default
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_NAME=admin
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=ADMIN_PASS
export OS_AUTH_URL=http://controller:35357/v3
export OS_IDENTITY_API_VERSION=3
Replace ``ADMIN_PASS`` with the password you chose
for the ``admin`` user in the Identity service.
#. Create the ``demo-openrc.sh`` file and add the following content::
export OS_PROJECT_DOMAIN_ID=default
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_NAME=demo
export OS_TENANT_NAME=demo
export OS_USERNAME=demo
export OS_PASSWORD=DEMO_PASS
export OS_AUTH_URL=http://controller:5000/v3
export OS_IDENTITY_API_VERSION=3
Replace ``DEMO_PASS`` with the password you chose
for the ``demo`` user in the Identity service.
Using the scripts
-----------------
To run clients as a specific project and user, you can simply load
the associated client environment script prior to running them.
For example:
#. Load the ``admin-openrc.sh`` file to populate
environment variables with the location of the Identity service
and the ``admin`` project and user credentials::
$ source admin-openrc.sh
#. Request an authentication token::
$ openstack token issue
+------------+----------------------------------+
| Field | Value |
+------------+----------------------------------+
| expires | 2015-03-25T01:45:49.950092Z |
| id | cd4110152ac24bdeaa82e1443c910c36 |
| project_id | cf12a15c5ea84b019aec3dc45580896b |
| user_id | 4d411f2291f34941b30eef9bd797505a |
+------------+----------------------------------+
Next topic: :ref:`openstack_image`.
source/openstack_identity.rst
-416
View File
@@ -1,416 +0,0 @@
.. _openstack_identity:
Identity Service
###################
The OpenStack Identity service provides a single point of integration for
managing authentication, authorization, and service catalog services.
Additionally, it provides information about users but that are not included in
OpenStack (such as LDAP services) can be integrated into a pre-existing
infrastructure.
When installing OpenStack Identity service, you must register each
service in your OpenStack installation. Identity service can then track
which OpenStack services are installed and where they are located on
the network.
Install and configure
~~~~~~~~~~~~~~~~~~~~~
This section describes how to install and configure the OpenStack
Identity service, code-named keystone, on the controller node. For
performance, this configuration deploys the Nginx* HTTP server to handle
requests.
Prerequisites
-------------
Before you configure the OpenStack Identity service, you must create a
database and an administration token.
#. To create the database, complete the following actions:
* Use the database access client to connect to the database server as the
``root`` user.::
$ mysql -u root -p
* Create the ``keystone`` database.::
CREATE DATABASE keystone;
* Grant proper access to the ``keystone`` databaseReplace ``KEYSTONE_DBPASS``
with a suitable password.::
GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' \
IDENTIFIED BY 'KEYSTONE_DBPASS';
GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' \
IDENTIFIED BY 'KEYSTONE_DBPASS';
* Exit the database access client.
#. Generate a random value to use as the administration token during
initial configuration::
$ openssl rand -hex 10
Install and configure components
--------------------------------
#. Run the following command to install the packages.::
# swupd bundle-add openstack-identity
#. Custom configurations will be located at ``/etc/keystone/``.
* Create the ``/etc/keystone`` directory.::
# mkdir /etc/keystone
* Create keystone configuration file ``/etc/keystone/keystone.conf``.::
# touch /etc/keystone/keystone.conf
#. Edit the ``/etc/keystone/keystone.conf`` file and complete the following
actions:
* In the ``[DEFAULT]`` section, define the value of the initial
administration token. Replace ``ADMIN_TOKEN`` with the random value that
you generated in a previous step.::
[DEFAULT]
...
admin_token = ADMIN_TOKEN
* In the ``[database]`` section, configure database access. Replace
``KEYSTONE_DBPASS`` with the password you chose for the database.::
[database]
...
connection = mysql://keystone:KEYSTONE_DBPASS@controller/keystone
#. Ensure files have proper ownership by running the following command::
# systemctl restart update-triggers.target
#. Populate the Identity service database::
# su -s /bin/sh -c "keystone-manage db_sync" keystone
Finalize the installation
-------------------------
#. Keystone is deployed as a uwsgi module. To start the Identity
service, you should enable and start the nginx service.::
# systemctl enable nginx uwsgi@keystone-admin.socket \
uwsgi@keystone-public.socket
# systemctl start nginx uwsgi@keystone-admin.socket \
uwsgi@keystone-public.socket
Create the service entity and API endpoints
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Identity service provides a catalog of services and their locations.
Each service that you add to your OpenStack environment requires a
service entity and several API endpoints in the catalog.
Prerequisites
-------------
You must pass the value of the authentication token to the `openstack`
command with the ``--os-token`` parameter or set the OS_TOKEN
environment variable. Similarly, you must also pass the value of the
Identity service URL to the `openstack` command with the ``--os-url``
parameter or set the OS_URL environment variable. This guide uses
environment variables to reduce command length.
#. Configure the authentication token::
$ export OS_TOKEN=ADMIN_TOKEN
Replace ``ADMIN_TOKEN`` with the authentication token that you
generated before. For example::
$ export OS_TOKEN=294a4c8a8a475f9b9836
#. Configure the endpoint URL::
$ export OS_URL=http://controller:35357/v3
#. Configure the Identity API version::
$ export OS_IDENTITY_API_VERSION=3
#. Install the OpenStack Python clients bundle::
# swupd bundle-add openstack-python-clients
Create the service entity and API endpoints
-------------------------------------------
#. The Identity service manages a catalog of services in your OpenStack
environment. Services use this catalog to determine the other services
available in your environment.
Create the service entity for the Identity service::
$ openstack service create \
--name keystone --description "OpenStack Identity" identity
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | OpenStack Identity |
| enabled | True |
| id | 4ddaae90388b4ebc9d252ec2252d8d10 |
| name | keystone |
| type | identity |
+-------------+----------------------------------+
#. The Identity service manages a catalog of API endpoints associated with
the services in your OpenStack environment. Services use this catalog to
determine how to communicate with other services in your environment.
OpenStack uses three API endpoint variants for each service: admin,
internal, and public. The admin API endpoint allows modifying users and
tenants by default, while the public and internal APIs do not allow these
operations. In a production environment, the variants might reside on
separate networks that service different types of users for security
reasons. For instance, the public API network might be visible from the
Internet so customers can manage their clouds. The admin API network
might be restricted to operators within the organization that manages
cloud infrastructure. The internal API network might be restricted to
the hosts that contain OpenStack services. Also, OpenStack supports
multiple regions for scalability. For simplicity, this guide uses the
management network for all endpoint variations and the default
``RegionOne`` region.
Create the Identity service API endpoints::
$ openstack endpoint create --region RegionOne \
identity public http://controller:5000/v3
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | 30fff543e7dc4b7d9a0fb13791b78bf4 |
| interface | public |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 8c8c0927262a45ad9066cfe70d46892c |
| service_name | keystone |
| service_type | identity |
| url | http://controller:5000/v3 |
+--------------+----------------------------------+
$ openstack endpoint create --region RegionOne \
identity internal http://controller:5000/v3
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | 57cfa543e7dc4b712c0ab137911bc4fe |
| interface | internal |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 6f8de927262ac12f6066cfe70d99ac51 |
| service_name | keystone |
| service_type | identity |
| url | http://controller:5000/v3 |
+--------------+----------------------------------+
$ openstack endpoint create --region RegionOne \
identity admin http://controller:35357/v3
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | 78c3dfa3e7dc44c98ab1b1379122ecb1 |
| interface | admin |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 34ab3d27262ac449cba6cfe704dbc11f |
| service_name | keystone |
| service_type | identity |
| url | http://controller:35357/v3 |
+--------------+----------------------------------+
Creating projects, users and roles
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Complete the following steps to create projects, users and roles:
#. Create an administrative project, user, and role for administrative
operations in your environment:
* Create the ``admin`` project::
$ openstack project create --domain default \
--description "Admin Project" admin
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | Admin Project |
| domain_id | default |
| enabled | True |
| id | 343d245e850143a096806dfaefa9afdc |
| is_domain | False |
| name | admin |
| parent_id | None |
+-------------+----------------------------------+
* Create the ``admin`` user::
$ openstack user create --domain default \
--password-prompt admin
User Password:
Repeat User Password:
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | default |
| email | admin@example.com |
| enabled | True |
| id | ac3377633149401296f6c0d92d79dc16 |
| name | admin |
+-----------+----------------------------------+
* Create the ``admin`` role::
$ openstack role create admin
+-------+----------------------------------+
| Field | Value |
+-------+----------------------------------+
| id | cd2cb9a39e874ea69e5d4b896eb16128 |
| name | admin |
+-------+----------------------------------+
* Add the ``admin`` role to the ``admin`` project and user::
$ openstack role add --project admin --user admin admin
#. This guide uses a service project that contains a unique user for each
service that you add to your environment. Create the ``service``
project::
$ openstack project create --domain default \
--description "Service Project" service
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | Service Project |
| domain_id | default |
| enabled | True |
| id | 894cdfa366d34e9d835d3de01e752262 |
| is_domain | False |
| name | service |
| parent_id | None |
+-------------+----------------------------------+
#. Regular (non-admin) tasks should use an unprivileged project and user.
As an example, this guide creates the ``demo`` project and user.
* Create the ``demo`` project::
$ openstack project create --domain default \
--description "Demo Project" demo
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | Demo Project |
| domain_id | default |
| enabled | True |
| id | ed0b60bf607743088218b0a533d5943f |
| is_domain | False |
| name | demo |
| parent_id | None |
+-------------+----------------------------------+
* Create the ``demo`` user::
$ openstack user create --domain default \
--password-prompt demo
User Password:
Repeat User Password:
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | default |
| email | demo@example.com |
| enabled | True |
| id | 58126687cbcc4888bfa9ab73a2256f27 |
| name | demo |
+-----------+----------------------------------+
* Create the ``user`` role::
$ openstack role create user
+-------+----------------------------------+
| Field | Value |
+-------+----------------------------------+
| id | 997ce8d05fc143ac97d83fdfb5998552 |
| name | user |
+-------+----------------------------------+
* Add the ``user`` role to the ``demo`` project and user::
$ openstack role add --project demo --user demo user
Verify operation
~~~~~~~~~~~~~~~~
Verify operation of the Identity service before installing other
services.
#. For security reasons, remove admin_token from
``/etc/keystone/keystone.conf``:
Edit the ``[DEFAULT]`` section and remove ``admin_token``.
#. Restart the keystone-admin service to reload the changes::
# systemctl restart uwsgi@keystone-admin.service
#. Unset the temporary ``OS_TOKEN`` and ``OS_URL`` environment variables::
$ unset OS_TOKEN OS_URL
#. As the ``admin`` user, request an authentication token::
$ openstack --os-auth-url http://controller:35357/v3 \
--os-project-domain-id default --os-user-domain-id default \
--os-project-name admin --os-username admin --os-auth-type password \
token issue
Password:
+------------+----------------------------------+
| Field | Value |
+------------+----------------------------------+
| expires | 2015-03-24T18:55:01Z |
| id | ff5ed908984c4a4190f584d826d75fed |
| project_id | cf12a15c5ea84b019aec3dc45580896b |
| user_id | 4d411f2291f34941b30eef9bd797505a |
+------------+----------------------------------+
#. As the ``demo`` user, request an authentication token::
$ openstack --os-auth-url http://controller:5000/v3 \
--os-project-domain-id default --os-user-domain-id default \
--os-project-name demo --os-username demo --os-auth-type password \
token issue
Password:
+------------+----------------------------------+
| Field | Value |
+------------+----------------------------------+
| expires | 2014-10-10T12:51:33Z |
| id | 1b87ceae9e08411ba4a16e4dada04802 |
| project_id | 4aa51bb942be4dd0ac0555d7591f80a6 |
| user_id | 7004dfa0dda84d63aef81cf7f100af01 |
+------------+----------------------------------+
Next topic: :ref:`openstack_identity-openrc`.
source/openstack_image.rst
-277
View File
@@ -1,277 +0,0 @@
.. _openstack_image:
Image Service
################
The OpenStack Image service (glance) enables users to discover, register, and
retrieve virtual machine images.
Install and configure the Image Service
---------------------------------------
This section describes how to install and configure the Image service,
code-named glance, on the controller node. For simplicity, this configuration
stores images on the local file system. By default, this directory is
``/var/lib/glance/images/``.
Prerequisites
~~~~~~~~~~~~~
Before you install and configure the Image service, you must create a database,
service credentials, and API endpoints.
#. To create the database, complete these steps:
* Use the database access client to connect to the database
server as the ``root`` user.::
$ mysql -u root -p
* Create the ``glance`` database::
CREATE DATABASE glance;
* Grant proper access to the ``glance`` database. Replace ``GLANCE_DBPASS``
with a suitable password.::
GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' \
IDENTIFIED BY 'GLANCE_DBPASS';
GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' \
IDENTIFIED BY 'GLANCE_DBPASS';
* Exit the database access client.
#. Source the ``admin`` credentials to gain access to admin-only CLI commands.::
$ source admin-openrc.sh
#. To create the service credentials, complete these steps:
* Create the ``glance`` user::
$ openstack user create --domain default --password-prompt glance
User Password:
Repeat User Password:
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | default |
| enabled | True |
| id | e38230eeff474607805b596c91fa15d9 |
| name | glance |
+-----------+----------------------------------+
* Add the ``admin`` role to the ``glance`` user and ``service`` project.::
$ openstack role add --project service --user glance admin
* Create the ``glance`` service entity.::
$ openstack service create --name glance \
--description "OpenStack Image service" image
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | OpenStack Image service |
| enabled | True |
| id | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
| name | glance |
| type | image |
+-------------+----------------------------------+
#. Create the Image service API endpoints.::
$ openstack endpoint create --region RegionOne \
image public http://controller:9292
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | 340be3625e9b4239a6415d034e98aace |
| interface | public |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
| service_name | glance |
| service_type | image |
| url | http://controller:9292 |
+--------------+----------------------------------+
$ openstack endpoint create --region RegionOne \
image internal http://controller:9292
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | a6e4b153c2ae4c919eccfdbb7dceb5d2 |
| interface | internal |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
| service_name | glance |
| service_type | image |
| url | http://controller:9292 |
+--------------+----------------------------------+
$ openstack endpoint create --region RegionOne \
image admin http://controller:9292
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | 0c37ed58103f4300a84ff125a539032d |
| interface | admin |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
| service_name | glance |
| service_type | image |
| url | http://controller:9292 |
+--------------+----------------------------------+
Install and configure components
--------------------------------
#. Install OpenStack Image bundle.::
# swupd bundle-add openstack-image
#. Configurations will be located at ``/etc/glance``.
* Create ``/etc/glance`` directory.::
# mkdir /etc/glance
* Create ``/etc/glance/glance-api.conf`` and
``/etc/glance/glance-registry.conf`` configuration files.::
# touch /etc/glance/glance-{api,registry}.conf
#. Edit the ``/etc/glance/glance-api.conf`` file and complete the following
actions:
* In the ``[database]`` section, configure database access. Replace
``GLANCE_DBPASS`` with the password you chose for the Image service
database.::
[database]
...
connection = mysql://glance:GLANCE_DBPASS@controller/glance
* In the ``[keystone_authtoken]`` section, configure Identity service access.
Replace ``GLANCE_PASS`` with the password you chose for the ``glance`` user
in the Identity service.::
[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = glance
password = GLANCE_PASS
#. Edit the ``/etc/glance/glance-registry.conf`` file and complete the following
actions:
* In the ``[database]`` section, configure database access. Replace
``GLANCE_DBPASS`` with the password you chose for the Image service
database.::
[database]
...
connection = mysql://glance:GLANCE_DBPASS@controller/glance
* In the ``[keystone_authtoken]`` section, configure Identity service
access. Replace ``GLANCE_PASS`` with the password you chose for the
``glance`` user in the Identity service.::
[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = glance
password = GLANCE_PASS
#. Ensure files have proper ownership by running the following command::
# systemctl restart update-triggers.target
#. Populate the Image Service database::
# su -s /bin/sh -c "glance-manage db_sync" glance
Finalize installation
---------------------
#. Start the Image Service services and configure them to start when the
system boots::
# systemctl enable glance-api.service glance-registry.service
# systemctl start glance-api.service glance-registry.service
Verify operation
~~~~~~~~~~~~~~~~
Verify operation of the Image service using
`CirrOS <http://launchpad.net/cirros>`__, a small
Linux image that helps you test your OpenStack deployment.
#. In each client environment script, configure the Image service
client to use API version 2.0::
$ echo "export OS_IMAGE_API_VERSION=2" \
| tee -a admin-openrc.sh demo-openrc.sh
#. Source the ``admin`` credentials to gain access to admin-only CLI commands::
$ source admin-openrc.sh
#. Download the source image::
$ curl -Ok http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
#. Upload the image to the Image service using the `QCOW2` disk format, `bare`
container format, and public visibility so all projects can access it::
$ openstack image create cirros --file cirros-0.3.4-x86_64-disk.img \
--disk-format qcow2 --container-format bare --public
+------------------+------------------------------------------------------+
| Field | Value |
+------------------+------------------------------------------------------+
| checksum | ee1eca47dc88f4879d8a229cc70a07c6 |
| container_format | bare |
| created_at | 2015-10-26T23:40:03Z |
| disk_format | qcow2 |
| file | /v2/images/fcf6fa55-56e9-4402-8137-3e9315c84905/file |
| id | fcf6fa55-56e9-4402-8137-3e9315c84905 |
| min_disk | 0 |
| min_ram | 0 |
| name | cirros |
| owner | 2e3093872ebf4143a122e2cc01a50d13 |
| protected | False |
| schema | /v2/schemas/image |
| size | 13287936 |
| status | active |
| tags | |
| updated_at | 2015-10-26T23:40:03Z |
| virtual_size | None |
| visibility | public |
+------------------+------------------------------------------------------+
#. Confirm upload of the image and validate attributes::
$ openstack image list
+--------------------------------------+--------+
| ID | Name |
+--------------------------------------+--------+
| 38047887-61a7-41ea-9b49-27987d5e8bb9 | cirros |
+--------------------------------------+--------+
Next topic: :ref:`openstack_compute`.
source/openstack_installing_bundles.rst
-26
View File
@@ -1,26 +0,0 @@
.. _openstack_installing_bundles:
Installing OpenStack* MVP bundles
############################################################
Note: This article walks through an OpenStack MVP installation by using
bundles available for Clear Linux* OS for Intel® Architecture. The sample
configuration files that are included would likely require modification
for your environment.
To install, continue with the following topics:
* `Database <openstack_supporting-database.html>`_
* `Message queue <openstack_supporting-messaging.html>`_
* `OpenStack Identity <openstack_identity.html>`_
* `Create OpenStack client environment scripts <openstack_identity-openrc.html>`_
* `OpenStack Image <openstack_image.html>`_
* `OpenStack Compute <openstack_compute.html>`_
* `OpenStack Block Storage <openstack_block_storage.html>`_
* `OpenStack Dashboard <openstack_dashboard.html>`_
* `OpenStack Networking <openstack_networking.html>`_
* `OpenStack Orchestration <openstack_orchestration.html>`_
* `OpenStack Telemetry <openstack_telemetry.html>`_
* `OpenStack Object Storage <openstack_object_storage.html>`_
Next topic: :ref:`openstack_supporting-database`.
source/openstack_networking.rst
-672
View File
@@ -1,672 +0,0 @@
.. _openstack_networking:
Networking
############################################################
OpenStack* Networking allows you to create and attach interface devices
managed by other OpenStack services to networks. Plug-ins can be
implemented to accommodate different networking equipment and software,
providing flexibility to OpenStack architecture and deployment.
Installing and configuring the controller node
----------------------------------------------
Prerequisites
~~~~~~~~~~~~~
Before configuring the OpenStack Networking (neutron) service, create a
database, service credentials, and an API endpoint.
#. Create the database:
* Use the database access client to connect to the database server
as the ``root`` user::
$ mysql -u root -p
* Create the ``neutron`` database::
CREATE DATABASE neutron;
* Grant proper access to the ``neutron`` database. Replace
*'NEUTRON_DBPASS'* with a suitable password::
GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' \
IDENTIFIED BY 'NEUTRON_DBPASS';
GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'%' \
IDENTIFIED BY 'NEUTRON_DBPASS';
* Exit the database access client.
#. Source the ``admin`` credentials to gain access to admin-only CLI commands::
$ source admin-openrc.sh
#. To create the service credentials, complete these steps:
* Create the ``neutron`` user::
$ openstack user create --domain default --password-prompt neutron
User Password:
Repeat User Password:
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | default |
| enabled | True |
| id | e51ef98012974e5287d857bc709f89d0 |
| name | neutron |
+-----------+----------------------------------+
* Add the ``admin`` role to the ``neutron`` user::
$ openstack role add --project service --user neutron admin
Note: This command provides no output.
* Create the ``neutron`` service entity::
$ openstack service create --name neutron \
--description "OpenStack Networking" network
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | OpenStack Networking |
| enabled | True |
| id | a56bcd5695b943afba528192acceff01 |
| name | neutron |
| type | network |
+-------------+----------------------------------+
#. Create the Networking service API endpoints:
* ::
$ openstack endpoint create --region RegionOne \
network public http://controller:9696
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | 61a8b881c8654026be84c12b943e4ee3 |
| interface | public |
| region | RegionOne |
| region_id | RegionOne |
| service_id | a56bcd5695b943afba528192acceff01 |
| service_name | neutron |
| service_type | network |
| url | http://controller:9696 |
+--------------+----------------------------------+
* ::
$ openstack endpoint create --region RegionOne \
network internal http://controller:9696
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | 83bf338752984e1cb5305b9a6a4b4e67 |
| interface | internal |
| region | RegionOne |
| region_id | RegionOne |
| service_id | a56bcd5695b943afba528192acceff01 |
| service_name | neutron |
| service_type | network |
| url | http://controller:9696 |
+--------------+----------------------------------+
* ::
$ openstack endpoint create --region RegionOne \
network admin http://controller:9696
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | 19cfff5a2e9a43298182f8785ea90414 |
| interface | admin |
| region | RegionOne |
| region_id | RegionOne |
| service_id | a56bcd5695b943afba528192acceff01 |
| service_name | neutron |
| service_type | network |
| url | http://controller:9696 |
+--------------+----------------------------------+
Installing the Networking components
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Complete the following step to install the Networking components:
#. Install OpenStack networking bundle::
# swupd bundle-add openstack-network
Configuring the Networking server component
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Complete the following steps to configure the Networking server component:
#. Custom configurations will be located at ``/etc/neutron/``.
* Create the ``/etc/neutron`` directory::
# mkdir /etc/neutron
* Create empty neutron configuration file ``/etc/neutron/neutron.conf``::
# touch /etc/neutron/neutron.conf
#. Edit the ``/etc/neutron/neutron.conf`` file:
* In the ``[database]`` section, configure database access. Replace
*NEUTRON_DBPASS* with the password you chose for the database.::
[database]
...
connection = mysql://neutron:NEUTRON_DBPASS@controller/neutron
* In the ``[DEFAULT]`` section, enable the Modular Layer 2 (ML2) plug-in,
router service, and overlapping IP addresses::
[DEFAULT]
...
core_plugin = ml2
service_plugins = router
allow_overlapping_ips = True
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections, configure
RabbitMQ message queue access. Replace *RABBIT_PASS* with the password you
chose for the ``openstack`` account in RabbitMQ::
[DEFAULT]
...
rpc_backend = rabbit
[oslo_messaging_rabbit]
...
rabbit_host = controller
rabbit_userid = openstack
rabbit_password = RABBIT_PASS
* In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections, configure
Identity service access. Replace *NEUTRON_PASS* with the password you
chose for the ``neutron`` user in the Identity service::
[DEFAULT]
...
auth_strategy = keystone
[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = neutron
password = NEUTRON_PASS
* In the ``[DEFAULT]`` and ``[nova]`` sections, configure Networking to
notify Compute of network topology changes. Replace *NOVA_PASS* with the
password you chose for the ``nova`` user in the Identity service::
[DEFAULT]
...
notify_nova_on_port_status_changes = True
notify_nova_on_port_data_changes = True
nova_url = http://controller:8774/v2
[nova]
...
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
region_name = RegionOne
project_name = service
username = nova
password = NOVA_PASS
Configuring the Modular Layer 2 (ML2) plug-in
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ML2 plug-in uses the Linux bridge mechanism to build layer-2 (bridging and
switching) virtual networking infrastructure for instances.
#. Custom configuration will be located at ``/etc/neutron/plugins/ml2``.
* Create the ``/etc/neutron/plugins/ml2`` directory::
# mkdir -p /etc/neutron/plugins/ml2
* Create empty ML2 configuration file
``/etc/neutron/plugins/ml2/ml2_conf.ini``::
# touch /etc/neutron/plugins/ml2/ml2_conf.ini
#. Edit the ``/etc/neutron/plugins/ml2/ml2_conf.ini`` file and complete the
following actions:
* In the ``[ml2]`` section, enable flat, VLAN and VXLAN networks::
[ml2]
...
type_drivers = flat,vlan,vxlan
* In the ``[ml2]`` section, enable VXLAN project (private) networks::
[ml2]
...
tenant_network_types = vxlan
* In the ``[ml2]`` section, enable the Linux bridge and layer-2 population
mechanisms::
[ml2]
...
mechanism_drivers = linuxbridge,l2population
* In the ``[ml2]`` section, enable the port security extension driver::
[ml2]
...
extension_drivers = port_security
* In the ``[ml2_type_flat]`` section, configure the public flat provider
network::
[ml2_type_flat]
...
flat_networks = public
* In the [ml2_type_vxlan] section, configure the VXLAN network identifier
range for private networks::
[ml2_type_vxlan]
...
vni_ranges = 1:1000
* In the [securitygroup] section, enable ipset to increase efficiency of
security group rules::
[securitygroup]
...
enable_ipset = True
Configure the Linux bridge agent
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Linux bridge agent builds layer-2 (bridging and switching) virtual
networking infrastructure for instances including VXLAN tunnels for private
networks and handles security groups.
#. Custom configuration for Linux bridge agent will be stored in
``/etc/neutron/plugins/ml2/linuxbridge_agent.ini``::
# touch /etc/neutron/plugins/ml2/linuxbridge_agent.ini
#. Edit the ``/etc/neutron/plugins/ml2/linuxbridge_agent.ini`` file and
complete the following actions:
* In the ``[linux_bridge]`` section, map the public virtual network to the
public physical network interface. Replace *PUBLIC_INTERFACE_NAME* with
the name of the underlying physical public network interface::
[linux_bridge]
physical_interface_mappings = public:PUBLIC_INTERFACE_NAME
* In the ``[vxlan]`` section, enable VXLAN overlay networks, configure the
IP address of the physical network interface that handles overlay networks,
and enable layer-2 population. Replace *OVERLAY_INTERFACE_IP_ADDRESS*
with the IP address of the underlying physical network interface that
handles overlay networks::
[vxlan]
enable_vxlan = True
local_ip = OVERLAY_INTERFACE_IP_ADDRESS
l2_population = True
* In the ``[agent]`` section, enable ARP spoofing protection::
[agent]
...
prevent_arp_spoofing = True
* In the ``[securitygroup]`` section, enable security groups and configure
the Linux bridge iptables firewall driver::
[securitygroup]
...
enable_security_group = True
firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver
Configure the layer-3 agent
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Layer-3 (L3) agent provides routing and NAT services for virtual networks.
#. Custom configuration for the Layer-3 agent will be stored in
``/etc/neutron/l3_agent.ini``::
# touch /etc/neutron/l3_agent.ini
#. Edit the ``/etc/neutron/l3_agent.ini`` file and complete the following
actions:
* In the ``[DEFAULT]`` section, configure the Linux bridge interface driver
and external network bridge::
[DEFAULT]
...
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver
external_network_bridge =
Note: The ``external_network_bridge`` option intentionally lacks a value to
enable multiple external networks on a single agent.
Configure the DHCP agent
~~~~~~~~~~~~~~~~~~~~~~~~
The DHCP agent provides DHCP services for virtual networks.
#. Custom configuration for Linux bridge agent will be stored in
``/etc/neutron/dhcp_agent.ini``::
# touch /etc/neutron/dhcp_agent.ini
#. Edit the /etc/neutron/dhcp_agent.ini file and complete the following actions:
* In the ``[DEFAULT]`` section, configure the Linux bridge interface driver,
Dnsmasq DHCP driver, and enable isolated metadata so instances on public
networks can access metadata over the network::
[DEFAULT]
...
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver
dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq
enable_isolated_metadata = True
Configure the metadata agent
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The metadata agent provides configuration information such as credentials to
instances.
#. Custom configuration for the metadata agent will be stored in
``/etc/neutron/metadata_agent.ini``::
# touch /etc/neutron/metadata_agent.ini
#. Edit the ``/etc/neutron/metadata_agent.ini`` file and complete the
following actions:
* In the ``[DEFAULT]`` section, configure access parameters. Replace
*NEUTRON_PASS* with the password you chose for the ``neutron`` user
in the Identity service::
[DEFAULT]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_region = RegionOne
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = neutron
password = NEUTRON_PASS
* In the ``[DEFAULT]`` section, configure the metadata host::
[DEFAULT]
...
nova_metadata_ip = controller
* In the ``[DEFAULT]`` section, configure the metadata proxy shared secret
Replace *METADATA_SECRET* with a suitable secret for the metadata proxy::
[DEFAULT]
...
metadata_proxy_shared_secret = METADATA_SECRET
Configuring Compute to use Networking
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. Edit the ``/etc/nova/nova.conf`` file on the controller node as follows:
* In the ``[neutron]`` section, configure access parameters, enable the
metadata proxy, and configure the secret.
Replace *NEUTRON_PASS* with the password you chose for the ``neutron``
user in the Identity service.
Replace *METADATA_SECRET* with the secret you chose for the metadata
proxy::
[neutron]
...
url = http://controller:9696
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
region_name = RegionOne
project_name = service
username = neutron
password = NEUTRON_PASS
service_metadata_proxy = True
metadata_proxy_shared_secret = METADATA_SECRET
Finalizing installation
~~~~~~~~~~~~~~~~~~~~~~~~
#. The Networking service initialization scripts expect a symbolic link
``/etc/neutron/plugin.ini`` pointing to the ML2 plug-in configuration
file, ``/etc/neutron/plugins/ml2/ml2_conf.ini``. If this symbolic
link does not exist, create it using the following command::
# ln -s /etc/neutron/plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini
#. Ensure files have proper ownership by running the following command::
# systemctl restart update-triggers.target
#. Populate the database::
# su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \
--config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron
#. Restart the Compute services::
# systemctl restart uwsgi@nova-api.service nova-scheduler.service nova-conductor.service
#. Start the Networking service and configure it to start when the
system boots::
# systemctl enable neutron-server.service \
neutron-linuxbridge-agent.service \
neutron-dhcp-agent.service \
neutron-metadata-agent.service \
neutron-l3-agent.service
# systemctl start neutron-server.service \
neutron-linuxbridge-agent.service \
neutron-dhcp-agent.service \
neutron-metadata-agent.service \
neutron-l3-agent.service
Install and configure compute node
----------------------------------
Install the components
~~~~~~~~~~~~~~~~~~~~~~
* Install OpenStack networking bundle::
# swupd bundle-add openstack-network
Configure the common component
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. Edit the ``/etc/neutron/neutron.conf`` file and complete the following
actions:
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections, configure
RabbitMQ message queue access. Replace *RABBIT_PASS* with the password you
chose for the openstack account in RabbitMQ.::
[DEFAULT]
...
rpc_backend = rabbit
[oslo_messaging_rabbit]
...
rabbit_host = controller
rabbit_userid = openstack
rabbit_password = RABBIT_PASS
* In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections, configure
Identity service access. Replace *NEUTRON_PASS* with the password you chose
for the ``neutron`` user in the Identity service::
[DEFAULT]
...
auth_strategy = keystone
[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = neutron
password = NEUTRON_PASS
Configure the Linux bridge agent
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. Edit the ``/etc/neutron/plugins/ml2/linuxbridge_agent.ini`` file and complete
the following actions:
* In the ``[linux_bridge]`` section, map the public virtual network to the
public physical network interface::
[linux_bridge]
physical_interface_mappings = public:PUBLIC_INTERFACE_NAME
* In the ``[vxlan]`` section, enable VXLAN overlay networks, configure the
IP address of the physical network interface that handles overlay
networks, and enable layer-2 population::
[vxlan]
enable_vxlan = True
local_ip = OVERLAY_INTERFACE_IP_ADDRESS
l2_population = True
* In the ``[agent]`` section, enable ARP spoofing protection::
[agent]
...
prevent_arp_spoofing = True
* In the ``[securitygroup]`` section, enable security groups and configure
the Linux bridge iptables firewall driver::
[securitygroup]
...
enable_security_group = True
firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver
Configure Compute to use Networking
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. Edit the ``/etc/nova/nova.conf`` file and complete the following actions:
* In the ``[neutron]`` section, configure access parameters. Replace
*NEUTRON_PASS* with the password you chose for the ``neutron`` user in
the Identity service.::
[neutron]
...
url = http://controller:9696
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
region_name = RegionOne
project_name = service
username = neutron
password = NEUTRON_PASS
Finalize installation
~~~~~~~~~~~~~~~~~~~~~
#. Restart the Compute service::
# systemctl restart nova-compute.service
#. Restart the Linux bridge agent::
# systemctl enable neutron-linuxbridge-agent.service
# systemctl restart neutron-linuxbridge-agent.service
Verify Operation
----------------
#. Source the ``admin`` credentials to gain access to admin-only CLI commands::
$ source admin-openrc.sh
#. List loaded extensions to verify successful launch of the neutron-server
process::
$ neutron ext-list
+-----------------------+-----------------------------------------------+
| alias | name |
+-----------------------+-----------------------------------------------+
| dns-integration | DNS Integration |
| address-scope | Address scope |
| ext-gw-mode | Neutron L3 Configurable external gateway mode |
| binding | Port Binding |
| agent | agent |
| subnet_allocation | Subnet Allocation |
| l3_agent_scheduler | L3 Agent Scheduler |
| external-net | Neutron external network |
| flavors | Neutron Service Flavors |
| net-mtu | Network MTU |
| quotas | Quota management support |
| l3-ha | HA Router extension |
| provider | Provider Network |
| multi-provider | Multi Provider Network |
| extraroute | Neutron Extra Route |
| router | Neutron L3 Router |
| extra_dhcp_opt | Neutron Extra DHCP opts |
| security-group | security-group |
| dhcp_agent_scheduler | DHCP Agent Scheduler |
| rbac-policies | RBAC Policies |
| port-security | Port Security |
| allowed-address-pairs | Allowed Address Pairs |
| dvr | Distributed Virtual Router |
+-----------------------+-----------------------------------------------+
#. List agents to verify successful launch of the neutron agents::
$ neutron agent-list
+--------------------------------------+--------------------+------------+-------+----------------+---------------------------+
| id | agent_type | host | alive | admin_state_up | binary |
+--------------------------------------+--------------------+------------+-------+----------------+---------------------------+
| 08905043-5010-4b87-bba5-aedb1956e27a | Linux bridge agent | compute1 | :-) | True | neutron-linuxbridge-agent |
| 27eee952-a748-467b-bf71-941e89846a92 | Linux bridge agent | controller | :-) | True | neutron-linuxbridge-agent |
| 830344ff-dc36-4956-84f4-067af667a0dc | L3 agent | controller | :-) | True | neutron-l3-agent |
| dd3644c9-1a3a-435a-9282-eb306b4b0391 | DHCP agent | controller | :-) | True | neutron-dhcp-agent |
| f49a4b81-afd6-4b3d-b923-66c8f0517099 | Metadata agent | controller | :-) | True | neutron-metadata-agent |
+--------------------------------------+--------------------+------------+-------+----------------+---------------------------+
Next topic: :ref:`openstack_orchestration`.
source/openstack_object_storage.rst
-772
View File
@@ -1,772 +0,0 @@
.. _openstack_object_storage:
OpenStack* Object Storage
#########################
The OpenStack Object Storage services (swift) work together to provide
object storage and retrieval through a REST API. Your environment must
at least include the Identity service (keystone) prior to deploying Object Storage.
OpenStack Object Storage
------------------------
The OpenStack Object Storage is a multi-tenant object storage system.
It is highly scalable and can manage large amounts of unstructured data
at low cost through a RESTful HTTP API.
It includes the following components:
**Proxy servers (swift-proxy-server)**
Accepts OpenStack Object Storage API and raw HTTP requests to upload files, modify metadata,
and create containers. It also serves file or container listings to web browsers. To improve performance,
the proxy server can use an optional cache that is usually deployed with memcache.
**Account servers (swift-account-server)**
Manages accounts defined with Object Storage.
**Container servers (swift-container-server)**
Manages the mapping of containers or folders, within Object Storage.
**Object servers (swift-object-server)**
Manages actual objects, such as files, on the storage nodes.
**Various periodic processes**
Performs housekeeping tasks on the large data store. The replication
services ensure consistency and availability through the cluster.
Other periodic processes include auditors, updaters, and reapers.
**WSGI middleware**
Handles authentication and is usually OpenStack Identity.
**swift client**
Enables users to submit commands to the REST API through a
command-line client authorized as either a admin user, reseller user, or swift user.
**swift-init**
Script that initializes the building of the ring file, takes daemon
names as parameter and offers commands. Documented in
http://docs.openstack.org/developer/swift/admin_guide.html#managing-services.
**swift-recon**
A cli tool used to retrieve various metrics and telemetry information
about a cluster that has been collected by the swift-recon middleware.
**swift-ring-builder**
Storage ring build and rebalance utility. Documented in
http://docs.openstack.org/developer/swift/admin_guide.html#managing-the-rings.
Install and configure the controller node
-----------------------------------------
This section describes how to install and configure the proxy service
that handles requests for the account, container, and object services
operating on the storage nodes. For simplicity, this guide installs and
configures the proxy service on the controller node. However, you can
run the proxy service on any node with network connectivity to the
storage nodes. Additionally, you can install and configure the proxy
service on multiple nodes to increase performance and redundancy.
To configure prerequisites
~~~~~~~~~~~~~~~~~~~~~~~~~~
The proxy service relies on an authentication and authorization
mechanism such as the Identity service. However, unlike other services,
it also offers an internal mechanism that allows it to operate without
any other OpenStack* services. However, for simplicity, this guide
references the Identity service. Before you configure the Object Storage
service, you must create service credentials and an API endpoint.
#. Source the ``admin`` credentials to gain access to admin-only CLI
commands::
$ source admin-openrc.sh
#. To create the Identity service credentials, complete these steps:
* Create the ``swift`` user::
$ openstack user create --domain default --password-prompt swift
User Password:
Repeat User Password:
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | default |
| enabled | True |
| id | d535e5cbd2b74ac7bfb97db9cced3ed6 |
| name | swift |
+-----------+----------------------------------+
* Add the admin role to the ``swift`` user::
$ openstack role add --project service --user swift admin
* Create the ``swift`` service entity::
$ openstack service create --name swift \
--description "OpenStack Object Storage" object-store
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | OpenStack Object Storage |
| enabled | True |
| id | 75ef509da2c340499d454ae96a2c5c34 |
| name | swift |
| type | object-store |
+-------------+----------------------------------+
#. Create the Object Storage service API endpoint::
$ openstack endpoint create --region RegionOne \
object-store public http://controller:8080/v1/AUTH_%\(tenant_id\)s
+--------------+----------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------+
| enabled | True |
| id | 12bfd36f26694c97813f665707114e0d |
| interface | public |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 75ef509da2c340499d454ae96a2c5c34 |
| service_name | swift |
| service_type | object-store |
| url | http://controller:8080/v1/AUTH_%(tenant_id)s |
+--------------+----------------------------------------------+
$ openstack endpoint create --region RegionOne \
object-store internal http://controller:8080/v1/AUTH_%\(tenant_id\)s
+--------------+----------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------+
| enabled | True |
| id | 7a36bee6733a4b5590d74d3080ee6789 |
| interface | internal |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 75ef509da2c340499d454ae96a2c5c34 |
| service_name | swift |
| service_type | object-store |
| url | http://controller:8080/v1/AUTH_%(tenant_id)s |
+--------------+----------------------------------------------+
$ openstack endpoint create --region RegionOne \
object-store admin http://controller:8080/v1
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | ebb72cd6851d4defabc0b9d71cdca69b |
| interface | admin |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 75ef509da2c340499d454ae96a2c5c34 |
| service_name | swift |
| service_type | object-store |
| url | http://controller:8080/v1 |
+--------------+----------------------------------+
To install and configure the controller node components
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. Install OpenStack Object Storage bundle::
# swupd bundle-add openstack-object-storage
# swupd verify --fix
#. Create the directory ``/etc/swift`` if does not exist::
# mkdir /etc/swift
#. Copy the sample proxy-server config file to the configuration
directory::
# cp /usr/share/defaults/swift/proxy-server.conf /etc/swift
#. Edit the ``/etc/swift/proxy-server.conf`` file and complete the
following actions:
* In the ``[pipeline:main]`` section, enable the appropriate
modules::
[pipeline:main]
pipeline = catch_errors gatekeeper healthcheck proxy-logging cache container_sync bulk ratelimit authtoken keystoneauth container-quotas account-quotas slo dlo versioned_writes proxy-logging proxy-server
* In the ``[app:proxy-server]`` section, enable automatic account
creation::
[app:proxy-server]
...
account_autocreate = true
* In the ``[filter:keystoneauth]`` section, configure the operator
roles::
[filter:keystoneauth]
use = egg:swift#keystoneauth
...
operator_roles = admin,user
* In the ``[filter:authtoken]`` section, configure Identity service
access. Replace *SWIFT_PASS* with the password you chose for the
``swift`` user in the Identity service::
[filter:authtoken]
paste.filter_factory = keystonemiddleware.auth_token:filter_factory
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = swift
password = SWIFT_PASS
delay_auth_decision = true
* In the ``[filter:cache]`` section, configure the ``memcached``
location::
[filter:cache]
...
memcache_servers = 127.0.0.1:11211
Install and configure the storage nodes
---------------------------------------
This section describes how to install and configure storage nodes that
operate the account, container, and object services. For simplicity,
this configuration references two storage nodes, each containing two
empty local block storage devices. Each of the devices, ``/dev/sdb`` and
``/dev/sdc``, must contain a suitable partition table with one partition
occupying the entire device.
Although the Object Storage service
supports any file system with extended attributes (xattr), testing and
benchmarking indicate the best performance and reliability on XFS.
To configure prerequisites
~~~~~~~~~~~~~~~~~~~~~~~~~~
You must configure each storage node before you install and configure
the Object Storage service on it. Similar to the controller node, each
storage node contains one network interface on the management network.
Optionally, each storage node can contain a second network interface on
a separate network for replication.
#. Configure unique items on the first storage node:
* Configure the management interface::
IP address: 10.0.0.51
Network mask: 255.255.255.0 (or /24)
Default gateway: 10.0.0.1
* Set the hostname of the node to ``object1``.
#. Configure unique items on the second storage node:
* Configure the management interface::
IP address: 10.0.0.52
Network mask: 255.255.255.0 (or /24)
Default gateway: 10.0.0.1
* Set the hostname of the node to ``object2``.
#. Configure shared items on both storage nodes:
* Copy the contents of ``/etc/hosts`` file from ``controller`` node to ``storage`` nodes and add the
following ::
# object1
10.0.0.51 object1
# object2
10.0.0.52 object2
#. Install the OpenStack Object Storage bundle::
# swupd bundle-add openstack-object-storage
# swupd verify --fix
#. Format the ``/dev/sdb1`` and ``/dev/sdc1`` partitions as XFS::
# mkfs.xfs /dev/sdb1
# mkfs.xfs /dev/sdc1
#. Create the mount point directory structure::
# mkdir -p /srv/node/sdb1
# mkdir -p /srv/node/sdc1
#. Edit the ``/etc/fstab`` file and add the following to it::
/dev/sdb1 /srv/node/sdb1 xfs noatime,nodiratime,nobarrier,logbufs=8 0 2
/dev/sdc1 /srv/node/sdc1 xfs noatime,nodiratime,nobarrier,logbufs=8 0 2
#. Mount the devices::
# mount /srv/node/sdb1
# mount /srv/node/sdc1
#. Edit the ``/etc/rsyncd.conf`` file and add the following to it::
uid = swift
gid = swift
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
address = MANAGEMENT_INTERFACE_IP_ADDRESS
[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
Replace *MANAGEMENT_INTERFACE_IP_ADDRESS* with the IP address of
the management network on the storage node.
Note: The ``rsync`` service requires no authentication, so consider
running it on a private network.
#. Start the ``rsyncd`` service and configure it to start when the
system boots::
# systemctl enable rsyncd.service
# systemctl start rsyncd.service
Install and configure storage node components
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. Copy the accounting, container, object, container-reconciler, and
object-expirer service configuration files to the configuration
directory::
# cp /usr/share/defaults/swift/account-server.conf /etc/swift
# cp /usr/share/defaults/swift/container-server.conf /etc/swift
# cp /usr/share/defaults/swift/object-server.conf /etc/swift
# cp /usr/share/defaults/swift/container-reconciler.conf /etc/swift
# cp /usr/share/defaults/swift/object-expirer.conf /etc/swift
#. Edit the ``/etc/swift/account-server.conf`` file and complete the
following actions:
* In the ``[DEFAULT]`` section, configure the bind IP address and
mount point directory::
[DEFAULT]
...
bind_ip = MANAGEMENT_INTERFACE_IP_ADDRESS
devices = /srv/node
Replace *MANAGEMENT_INTERFACE_IP_ADDRESS* with the IP
address of the management network on the storage node.
* In the ``[pipeline:main]`` section, enable the appropriate
modules::
[pipeline:main]
pipeline = healthcheck recon account-server
* In the ``[filter:recon]`` section, configure the ``recon`` (metrics)
cache directory::
[filter:recon]
...
recon_cache_path = /var/cache/swift
#. Edit the ``/etc/swift/container-server.conf`` file and complete the
following actions:
* In the ``[DEFAULT]`` section, configure the bind IP address and
mount point directory::
[DEFAULT]
...
bind_ip = MANAGEMENT_INTERFACE_IP_ADDRESS
devices = /srv/node
Replace *MANAGEMENT_INTERFACE_IP_ADDRESS* with the IP
address of the management network on the storage node.
* In the ``[pipeline:main]`` section, enable the appropriate modules::
[pipeline:main]
pipeline = healthcheck recon container-server
* In the ``[filter:recon]`` section, configure the recon (metrics)
cache directory::
[filter:recon]
...
recon_cache_path = /var/cache/swift
#. Edit the ``/etc/swift/object-server.conf`` file and complete the
following actions:
* In the ``[DEFAULT]`` section, configure the bind IP address and
mount point directory::
[DEFAULT]
...
bind_ip = MANAGEMENT_INTERFACE_IP_ADDRESS
devices = /srv/node
Replace *MANAGEMENT_INTERFACE_IP_ADDRESS* with the IP
address of the management network on the storage node.
* In the ``[pipeline:main]`` section, enable the appropriate
modules::
[pipeline:main]
pipeline = healthcheck recon object-server
* In the ``[filter:recon]`` section, configure the ``recon`` (metrics)
cache and lock directories::
[filter:recon]
...
recon_cache_path = /var/cache/swift
recon_lock_path = /var/lock
#. Ensure proper ownership of the mount point directory structure::
# systemctl restart update-triggers.target
About creating initial rings
----------------------------
Before starting the Object Storage services, you must create the initial
account, container, and object rings. The ring builder creates
configuration files that each node uses to determine and deploy the
storage architecture. For simplicity, this guide uses one region and
zone with 2^10 (1024) maximum partitions, 3 replicas of each object, and
1 hour minimum time between moving a partition more than once. For
Object Storage, a partition indicates a directory on a storage device
rather than a conventional partition table.
Create Account Ring
-------------------
The account server uses the account ring to maintain lists of
containers.
To create the ring
~~~~~~~~~~~~~~~~~~
#. Create the base ``account.builder`` file::
# swift-ring-builder account.builder create 10 3 1
#. Add each storage node to the ring::
# swift-ring-builder account.builder \
add --region 1 --zone 1 --ip STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS --port 6002 \
--device DEVICE_NAME --weight DEVICE_WEIGHT
Replace *STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS* with the
IP address of the management network on the storage node. Replace
*DEVICE_NAME* with a storage device name on the same storage node.
For example, using the first storage node with the ``/dev/sdb1`` storage
device and weight of 100::
# swift-ring-builder account.builder add \
--region 1 --zone 1 --ip 10.0.0.51 --port 6002 --device sdb --weight 100
Repeat this command for each storage device on each storage node. In
the example architecture, use the command in four variations::
# swift-ring-builder account.builder add \
--region 1 --zone 1 --ip 10.0.0.51 --port 6002 --device sdb --weight 100
Device d0r1z1-10.0.0.51:6002R10.0.0.51:6002/sdb_"" with 100.0 weight got id 0
# swift-ring-builder account.builder add \
--region 1 --zone 2 --ip 10.0.0.51 --port 6002 --device sdc --weight 100
Device d1r1z2-10.0.0.51:6002R10.0.0.51:6002/sdc_"" with 100.0 weight got id 1
# swift-ring-builder account.builder add \
--region 1 --zone 3 --ip 10.0.0.52 --port 6002 --device sdb --weight 100
Device d2r1z3-10.0.0.52:6002R10.0.0.52:6002/sdb_"" with 100.0 weight got id 2
# swift-ring-builder account.builder add \
--region 1 --zone 4 --ip 10.0.0.52 --port 6002 --device sdc --weight 100
Device d3r1z4-10.0.0.52:6002R10.0.0.52:6002/sdc_"" with 100.0 weight got id 3
#. Verify the ring contents::
# swift-ring-builder account.builder
account.builder, build version 4
1024 partitions, 3.000000 replicas, 1 regions, 4 zones, 4 devices, 100.00 balance, 0.00 dispersion
The minimum number of hours before a partition can be reassigned is 1
The overload factor is 0.00% (0.000000)
Devices: id region zone ip address port replication ip replication port name weight partitions balance meta
0 1 1 10.0.0.51 6002 10.0.0.51 6002 sdb 100.00 0 -100.00
1 1 2 10.0.0.51 6002 10.0.0.51 6002 sdc 100.00 0 -100.00
2 1 3 10.0.0.52 6002 10.0.0.52 6002 sdb 100.00 0 -100.00
3 1 4 10.0.0.52 6002 10.0.0.52 6002 sdc 100.00 0 -100.00
#. Rebalance the ring::
# swift-ring-builder account.builder rebalance
Reassigned 1024 (100.00%) partitions. Balance is now 0.00. Dispersion is now 0.00
Create Container Ring
---------------------
The container server uses the container ring to maintain lists of
objects. However, it does not track object locations.
To create the ring
~~~~~~~~~~~~~~~~~~
#. Create the base ``container.builder`` file::
# swift-ring-builder container.builder create 10 3 1
#. Add each storage node to the ring::
# swift-ring-builder container.builder \
add --region 1 --zone 1 --ip STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS --port 6001 \
--device DEVICE_NAME --weight DEVICE_WEIGHT
Replace *STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS* with the
IP address of the management network on the storage node. Replace
*DEVICE_NAME* with a storage device name on the same storage node.
For example, using the first storage node with the ``/dev/sdb1`` storage
device and weight of 100::
# swift-ring-builder container.builder add \
--region 1 --zone 1 --ip 10.0.0.51 --port 6001 --device sdb --weight 100
Repeat this command for each storage device on each storage node. In
the example architecture, use the command in four variations::
# swift-ring-builder container.builder add \
--region 1 --zone 1 --ip 10.0.0.51 --port 6001 --device sdb --weight 100
Device d0r1z1-10.0.0.51:6001R10.0.0.51:6001/sdb_"" with 100.0 weight got id 0
# swift-ring-builder container.builder add \
--region 1 --zone 2 --ip 10.0.0.51 --port 6001 --device sdc --weight 100
Device d1r1z2-10.0.0.51:6001R10.0.0.51:6001/sdc_"" with 100.0 weight got id 1
# swift-ring-builder container.builder add \
--region 1 --zone 3 --ip 10.0.0.52 --port 6001 --device sdb --weight 100
Device d2r1z3-10.0.0.52:6001R10.0.0.52:6001/sdb_"" with 100.0 weight got id 2
# swift-ring-builder container.builder add \
--region 1 --zone 4 --ip 10.0.0.52 --port 6001 --device sdc --weight 100
Device d3r1z4-10.0.0.52:6001R10.0.0.52:6001/sdc_"" with 100.0 weight got id 3
#. Verify the ring contents::
# swift-ring-builder container.builder
container.builder, build version 4
1024 partitions, 3.000000 replicas, 1 regions, 4 zones, 4 devices, 100.00 balance, 0.00 dispersion
The minimum number of hours before a partition can be reassigned is 1
The overload factor is 0.00% (0.000000)
Devices: id region zone ip address port replication ip replication port name weight partitions balance meta
0 1 1 10.0.0.51 6001 10.0.0.51 6001 sdb 100.00 0 -100.00
1 1 2 10.0.0.51 6001 10.0.0.51 6001 sdc 100.00 0 -100.00
2 1 3 10.0.0.52 6001 10.0.0.52 6001 sdb 100.00 0 -100.00
3 1 4 10.0.0.52 6001 10.0.0.52 6001 sdc 100.00 0 -100.00
#. Rebalance the ring::
# swift-ring-builder container.builder rebalance
Reassigned 1024 (100.00%) partitions. Balance is now 0.00. Dispersion is now 0.00
Create Object Ring
------------------
The object server uses the object ring to maintain lists of object
locations on local devices.
To create the ring
~~~~~~~~~~~~~~~~~~
#. Create the base ``object.builder`` file::
# swift-ring-builder object.builder create 10 3 1
#. Add each storage node to the ring::
# swift-ring-builder object.builder \
add --region 1 --zone 1 --ip STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS --port 6000 \
--device DEVICE_NAME --weight DEVICE_WEIGHT
Replace *STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS* with the
IP address of the management network on the storage node. Replace
*DEVICE_NAME* with a storage device name on the same storage node.
For example, using the first storage node with the ``/dev/sdb1`` storage
device and weight of 100::
# swift-ring-builder object.builder add \
--region 1 --zone 1 --ip 10.0.0.51 --port 6000 --device sdb --weight 100
Repeat this command for each storage device on each storage node. In
the example architecture, use the command in four variations::
# swift-ring-builder object.builder add \
--region 1 --zone 1 --ip 10.0.0.51 --port 6000 --device sdb --weight 100
Device d0r1z1-10.0.0.51:6000R10.0.0.51:6000/sdb_"" with 100.0 weight got id 0
# swift-ring-builder object.builder add \
--region 1 --zone 2 --ip 10.0.0.51 --port 6000 --device sdc --weight 100
Device d1r1z2-10.0.0.51:6000R10.0.0.51:6000/sdc_"" with 100.0 weight got id 1
# swift-ring-builder object.builder add \
--region 1 --zone 3 --ip 10.0.0.52 --port 6000 --device sdb --weight 100
Device d2r1z3-10.0.0.52:6000R10.0.0.52:6000/sdb_"" with 100.0 weight got id 2
# swift-ring-builder object.builder add \
--region 1 --zone 4 --ip 10.0.0.52 --port 6000 --device sdc --weight 100
Device d3r1z4-10.0.0.52:6000R10.0.0.52:6000/sdc_"" with 100.0 weight got id 3
#. Verify the ring contents::
# swift-ring-builder object.builder
object.builder, build version 4
1024 partitions, 3.000000 replicas, 1 regions, 4 zones, 4 devices, 100.00 balance, 0.00 dispersion
The minimum number of hours before a partition can be reassigned is 1
The overload factor is 0.00% (0.000000)
Devices: id region zone ip address port replication ip replication port name weight partitions balance meta
0 1 1 10.0.0.51 6000 10.0.0.51 6000 sdb 100.00 0 -100.00
1 1 2 10.0.0.51 6000 10.0.0.51 6000 sdc 100.00 0 -100.00
2 1 3 10.0.0.52 6000 10.0.0.52 6000 sdb 100.00 0 -100.00
3 1 4 10.0.0.52 6000 10.0.0.52 6000 sdc 100.00 0 -100.00
#. Rebalance the ring::
# swift-ring-builder object.builder rebalance
Reassigned 1024 (100.00%) partitions. Balance is now 0.00. Dispersion is now 0.00
Distribute ring configuration files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Copy the ``account.ring.gz``, ``container.ring.gz``, and ``object.ring.gz`` files to
the ``/etc/swift`` directory on each storage node and any additional nodes
running the proxy service::
# cp account.ring.gz container.ring.gz object.ring.gz /etc/swift/
Finalize installation
---------------------
Configure hashes and default storage policy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. Copy the swift service configuration file to the configuration directory::
# cp /usr/share/defaults/swift/swift.conf /etc/swift
#. Edit the ``/etc/swift/swift.conf`` file and complete the following
actions:
* In the ``[swift-hash]`` section, configure the hash path prefix and
suffix for your environment. Replace *HASH_PATH_PREFIX* and
*HASH_PATH_SUFFIX* with unique values.::
[swift-hash]
...
swift_hash_path_suffix = HASH_PATH_PREFIX
swift_hash_path_prefix = HASH_PATH_SUFFIX
* In the ``[storage-policy:0]`` section, configure the default storage
policy::
[storage-policy:0]
...
name = Policy-0
default = yes
#. Copy the ``swift.conf`` file to the ``/etc/swift`` directory on each storage
node and any additional nodes running the proxy service.
#. On all nodes, ensure proper ownership of the configuration directory::
# systemctl restart update-triggers.target
#. On the controller node and any other nodes running the proxy service,
start the Object Storage proxy service including its dependencies and
configure them to start when the system boots::
# systemctl enable swift-proxy.service memcached.service
# systemctl start swift-proxy.service memcached.service
#. On the storage nodes, start the Object Storage services and configure
them to start when the system boots::
# systemctl enable swift-account.service \
swift-account-auditor.service \
swift-account-reaper.service \
swift-account-replicator.service \
swift-container.service \
swift-container-auditor.service \
swift-container-replicator.service \
swift-container-updater.service \
swift-object.service \
swift-object-auditor.service \
swift-object-replicator.service \
swift-object-updater.service
# systemctl start swift-account.service \
swift-account-auditor.service \
swift-account-reaper.service \
swift-account-replicator.service \
swift-container.service \
swift-container-auditor.service \
swift-container-replicator.service \
swift-container-updater.service \
swift-object.service \
swift-object-auditor.service \
swift-object-replicator.service \
swift-object-updater.service
Verify operation
----------------
Verify operation of the Object Storage service.
#. In each client environment script, configure the Object Storage service client to use the Identity API version 3::
$ echo "export OS_AUTH_VERSION=3" \
| tee -a admin-openrc.sh demo-openrc.sh
#. Source the demo credentials::
$ source demo-openrc.sh
#. Show the service status::
$ swift stat
Account: AUTH_ed0b60bf607743088218b0a533d5943f
Containers: 0
Objects: 0
Bytes: 0
Containers in policy "policy-0": 0
Objects in policy "policy-0": 0
Bytes in policy "policy-0": 0
X-Account-Project-Domain-Id: default
X-Timestamp: 1444143887.71539
X-Trans-Id: tx1396aeaf17254e94beb34-0056143bde
Content-Type: text/plain; charset=utf-8
Accept-Ranges: bytes
#. Upload a test file::
$ swift upload container1 FILE
FILE
Replace *FILE* with the name of a local file to upload to the ``container1`` container.
#. List containers::
$ swift list
container1
#. Download a test file::
$ swift download container1 FILE
FILE [auth 0.295s, headers 0.339s, total 0.339s, 0.005 MB/s]
Replace *FILE* with the name of the file uploaded to the ``container1`` container.
source/openstack_orchestration.rst
-393
View File
@@ -1,393 +0,0 @@
.. _openstack_orchestration:
Orchestration
############################################################
The OpenStack* Orchestration service provides a template-based orchestration for
describing a cloud application by running OpenStack API calls to generate
running cloud applications. The software integrates other core components of
OpenStack into a one-file template system.
The templates allow you to create most OpenStack resource types, such as
instances, floating IPs, volumes, security groups and users. It also provides
advanced functionality, such as instance high availability, instance
auto-scaling, and nested stacks. This enables OpenStack core projects to
receive a larger user base.
Installing and configuring controller node
------------------------------------------
This section describes how to install and configure the Orchestration
service, codenamed heat, on the controller node.
Configuring prerequisites
~~~~~~~~~~~~~~~~~~~~~~~~~
Before you install and configure Orchestration, you must create a
database, service credentials, and API endpoints.
#. To create the database, complete these steps:
* Use the database access client to connect to the database server as
the ``root`` user::
$ mysql -u root -p
* Create the ``heat`` database::
CREATE DATABASE heat;
* Grant proper access to the ``heat`` database. Replace *HEAT_DBPASS*  
with a suitable password::
GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'localhost' \
IDENTIFIED BY 'HEAT_DBPASS';
GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'%' \
IDENTIFIED BY 'HEAT_DBPASS';
* Exit the database access client.
#. Source the ``admin`` credentials to gain access to admin-only CLI
commands::
$ source admin-openrc.sh
#. To create the service credentials, complete these steps:
* Create the ``heat`` user::
$ openstack user create --domain default --password-prompt heat
User Password:
Repeat User Password:
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | default |
| enabled | True |
| id | ca2e175b851943349be29a328cc5e360 |
| name | heat |
+-----------+----------------------------------+
* Add the ``admin`` role to the ``heat`` user::
$ openstack role add --project service --user heat admin
* Create the ``heat`` and ``heat-cfn`` service entities::
$ openstack service create --name heat \
--description "Orchestration" orchestration
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | Orchestration |
| enabled | True |
| id | 727841c6f5df4773baa4e8a5ae7d72eb |
| name | heat |
| type | orchestration |
+-------------+----------------------------------+
$ openstack service create --name heat-cfn \
--description "Orchestration" cloudformation
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | Orchestration |
| enabled | True |
| id | c42cede91a4e47c3b10c8aedc8d890c6 |
| name | heat-cfn |
| type | cloudformation |
+-------------+----------------------------------+
#. Create the Orchestration service API endpoints::
$ openstack endpoint create --region RegionOne \
orchestration public http://controller:8004/v1/%\(tenant_id\)s
+--------------+-----------------------------------------+
| Field | Value |
+--------------+-----------------------------------------+
| enabled | True |
| id | 3f4dab34624e4be7b000265f25049609 |
| interface | public |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 727841c6f5df4773baa4e8a5ae7d72eb |
| service_name | heat |
| service_type | orchestration |
| url | http://controller:8004/v1/%(tenant_id)s |
+--------------+-----------------------------------------+
$ openstack endpoint create --region RegionOne \
orchestration internal http://controller:8004/v1/%\(tenant_id\)s
+--------------+-----------------------------------------+
| Field | Value |
+--------------+-----------------------------------------+
| enabled | True |
| id | 9489f78e958e45cc85570fec7e836d98 |
| interface | internal |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 727841c6f5df4773baa4e8a5ae7d72eb |
| service_name | heat |
| service_type | orchestration |
| url | http://controller:8004/v1/%(tenant_id)s |
+--------------+-----------------------------------------+
$ openstack endpoint create --region RegionOne \
orchestration admin http://controller:8004/v1/%\(tenant_id\)s
+--------------+-----------------------------------------+
| Field | Value |
+--------------+-----------------------------------------+
| enabled | True |
| id | 76091559514b40c6b7b38dde790efe99 |
| interface | admin |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 727841c6f5df4773baa4e8a5ae7d72eb |
| service_name | heat |
| service_type | orchestration |
| url | http://controller:8004/v1/%(tenant_id)s |
+--------------+-----------------------------------------+
$ openstack endpoint create --region RegionOne \
cloudformation public http://controller:8000/v1
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | b3ea082e019c4024842bf0a80555052c |
| interface | public |
| region | RegionOne |
| region_id | RegionOne |
| service_id | c42cede91a4e47c3b10c8aedc8d890c6 |
| service_name | heat-cfn |
| service_type | cloudformation |
| url | http://controller:8000/v1 |
+--------------+----------------------------------+
$ openstack endpoint create --region RegionOne \
cloudformation internal http://controller:8000/v1
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | 169df4368cdc435b8b115a9cb084044e |
| interface | internal |
| region | RegionOne |
| region_id | RegionOne |
| service_id | c42cede91a4e47c3b10c8aedc8d890c6 |
| service_name | heat-cfn |
| service_type | cloudformation |
| url | http://controller:8000/v1 |
+--------------+----------------------------------+
$ openstack endpoint create --region RegionOne \
cloudformation admin http://controller:8000/v1
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | 3d3edcd61eb343c1bbd629aa041ff88b |
| interface | internal |
| region | RegionOne |
| region_id | RegionOne |
| service_id | c42cede91a4e47c3b10c8aedc8d890c6 |
| service_name | heat-cfn |
| service_type | cloudformation |
| url | http://controller:8000/v1 |
+--------------+----------------------------------+
#. Orchestration requires additional information in the Identity service to
manage stacks. To add this information, complete these steps:
* Create the ``heat`` domain that contains projects and users for stacks::
$ openstack domain create --description "Stack projects and users" heat
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | Stack projects and users |
| enabled | True |
| id | 0f4d1bd326f2454dacc72157ba328a47 |
| name | heat |
+-------------+----------------------------------+
* Create the ``heat_domain_admin`` user to manage projects and users in the
``heat`` domain::
$ openstack user create --domain heat --password-prompt heat_domain_admin
User Password:
Repeat User Password:
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | 0f4d1bd326f2454dacc72157ba328a47 |
| enabled | True |
| id | b7bd1abfbcf64478b47a0f13cd4d970a |
| name | heat_domain_admin |
+-----------+----------------------------------+
* Add the ``admin`` role to the ``heat_domain_admin`` in the ``heat`` domain
to enable administrative stack management privileges by the
``heat_domain_admin`` user::
$ openstack role add --domain heat --user heat_domain_admin admin
* Create the ``heat_stack_owner`` role::
$ openstack role create heat_stack_owner
+-------+----------------------------------+
| Field | Value |
+-------+----------------------------------+
| id | 15e34f0c4fed4e68b3246275883c8630 |
| name | heat_stack_owner |
+-------+----------------------------------+
* Create the ``heat_stack_user`` role::
$ openstack role create heat_stack_user
+-------+----------------------------------+
| Field | Value |
+-------+----------------------------------+
| id | 88849d41a55d4d1d91e4f11bffd8fc5c |
| name | heat_stack_user |
+-------+----------------------------------+
Installing and configuring components
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To install and configure the Orchestration components:
#. Install OpenStack Orchestration bundle::
# swupd bundle-add openstack-orchestration
#. Custom configuration will be located at ``/etc/heat/heat.conf file``.
* Create the ``/etc/heat`` directory::
# mkdir /etc/heat
* Create empty heat configuration file ``/etc/heat/heat.conf``::
# touch /etc/heat/heat.conf
#. Edit the ``/etc/heat/heat.conf`` file and complete the following
actions:
* In the ``[database]`` section, configure database access.
Replace *HEAT_DBPASS*  with the password you chose for the
Orchestration database::
[database]
...
connection = mysql://heat:HEAT_DBPASS@controller/heat
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections, configure
RabbitMQ message queue access. Replace ``RABBIT_PASS``  with the password
you chose for the ``openstack`` account in RabbitMQ::
[DEFAULT]
...
rpc_backend = rabbit
[oslo_messaging_rabbit]
...
rabbit_host = controller
rabbit_userid = openstack
rabbit_password = RABBIT_PASS
* In the ``[keystone_authtoken]``, ``[trustee]``, ``[clients_keystone]``,
and ``[ec2authtoken]`` sections, configure Identity service access. Replace
``HEAT_PASS`` with the password you chose for the heat user in the Identity
service.::
[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = heat
password = HEAT_PASS
[trustee]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = heat
password = HEAT_PASS
[clients_keystone]
...
auth_uri = http://controller:5000
[ec2authtoken]
...
auth_uri = http://controller:5000
* In the ``[DEFAULT]`` section, configure the metadata and wait
condition URLs::
[DEFAULT]
...
heat_metadata_server_url = http://controller:8000
heat_waitcondition_server_url = http://controller:8000/v1/waitcondition
* In the ``[DEFAULT]`` section, configure the stack domain and administrative
credentials. Replace ``HEAT_DOMAIN_PASS`` with the password you chose for
the ``heat_domain_admin`` user in the Identity service.::
[DEFAULT]
...
stack_domain_admin = heat_domain_admin
stack_domain_admin_password = HEAT_DOMAIN_PASS
stack_user_domain_name = heat
#. Ensure files have proper ownership by running the following command::
# systemctl restart update-triggers.target
#. Populate the Orchestration database::
# su -s /bin/sh -c "heat-manage db_sync" heat
Finalize installation
~~~~~~~~~~~~~~~~~~~~~~~~
Complete this step to finalize the installation:
* Start the Orchestration services and configure them to start when the
system boots::
# systemctl enable heat-api.service heat-api-cfn.service heat-engine.service
# systemctl start heat-api.service heat-api-cfn.service heat-engine.service
Verify operation
----------------
#. Source the ``admin`` tenant credentials::
$ source admin-openrc.sh
#. List service components to verify successful launch and registration of each
process::
$ heat service-list
+------------+-------------+--------------------------------------+------------+--------+----------------------------+--------+
| hostname | binary | engine_id | host | topic | updated_at | status |
+------------+-------------+--------------------------------------+------------+--------+----------------------------+--------+
| controller | heat-engine | 3e85d1ab-a543-41aa-aa97-378c381fb958 | controller | engine | 2015-10-13T14:16:06.000000 | up |
| controller | heat-engine | 45dbdcf6-5660-4d5f-973a-c4fc819da678 | controller | engine | 2015-10-13T14:16:06.000000 | up |
| controller | heat-engine | 51162b63-ecb8-4c6c-98c6-993af899c4f7 | controller | engine | 2015-10-13T14:16:06.000000 | up |
| controller | heat-engine | 8d7edc6d-77a6-460d-bd2a-984d76954646 | controller | engine | 2015-10-13T14:16:06.000000 | up |
+------------+-------------+--------------------------------------+------------+--------+----------------------------+--------+
Next topic: :ref:`openstack_telemetry`.
source/openstack_supporting-database.rst
-52
View File
@@ -1,52 +0,0 @@
.. _openstack_supporting-database:
Database
########
Most OpenStack* services use an SQL database to store information. The
database typically runs on the controller node. The procedures in this
guide use MariaDB.
Install and configure the database server
-----------------------------------------
#. Install MariaDB bundle::
# swupd bundle-add database-mariadb
#. Create the ``/etc/mariadb/`` folder and the ``/etc/mariadb/openstack.cnf``
file::
# mkdir /etc/mariadb
# touch /etc/mariadb/openstack.cnf
#. Add the ``[mysqld]`` section, set the bind-address key to the
management IP address of the controller node to enable access by
other nodes via the management network and enable useful options for
UTF-8 character set::
[mysqld]
bind-address = 10.0.0.11
default-storage-engine = innodb
innodb_file_per_table
collation-server = utf8_general_ci
init-connect = 'SET NAMES utf8'
character-set-server = utf8
Finalizing database installation
--------------------------------
Complete the following steps to finalize database installation:
#. Start the database service and configure it to start when the system
boots::
# systemctl enable mariadb.service
# systemctl start mariadb.service
#. Secure the database service including choosing a suitable password
for the root account::
# mysql_secure_installation
Next topic: :ref:`openstack_supporting-messaging`.
source/openstack_supporting-messaging.rst
-47
View File
@@ -1,47 +0,0 @@
.. _openstack_supporting-messaging:
Message queue
#############
OpenStack* uses a `message queue` to coordinate operations and
status information among services. The message queue service typically
runs on the controller node. OpenStack supports several message queue
services. This guide implements the RabbitMQ message queue service.
Install the message queue service
---------------------------------
#. Install the message queue bundle.::
# swupd bundle-add message-broker-rabbitmq
Configuring the message broker service
--------------------------------------
Complete the following steps to configure the message broker service:
#. Message broker service needs to be able to resolve to itself. Add the
following line to ``/etc/hosts``.::
127.0.0.1 controller
#. Start the message broker service and configure it to start when the
system boots.::
# systemctl enable rabbitmq-server.service
# systemctl start rabbitmq-server.service
#. Add the OpenStack user. Replace ``RABBIT_PASS`` with a suitable password.::
# rabbitmqctl add_user openstack RABBIT_PASS
Creating user openstack ...
...done.
#. Permit configuration, write, and read access for the OpenStack user.::
# rabbitmqctl set_permissions openstack ".*" ".*" ".*"
Setting permissions for user "openstack" in vhost "/" ...
...done.
Next topic: :ref:`openstack_identity`.
source/openstack_sys_req_and_pw_summary.rst
-68
View File
@@ -1,68 +0,0 @@
.. _openstack_sys_req_and_pw_summary:
System requirements and password summary
########################################
System requirements
-------------------
For best performance, we recommend that your environment meets or
exceeds the following hardware requirements:
- Controller Node: 1 processor, 2 GB memory, and 5 GB storage.
- Compute Node: 1 processor, 2 GB memory, and 10 GB storage.
For OpenStack* services, this guide uses \ ``SERVICE_PASS``\ to reference
service account passwords and ``SERVICE_DBPASS`` to reference database
passwords.
Prerequisites
-------------
All nodes require Internet access to install OpenStack bundles and
perform maintenance tasks such as periodic updates.
OpenStack and supporting services require administrative privileges
during installation and operation.
You must also configure networking so that each node can resolve the
other nodes by name in addition to IP address. For example, the
``controller`` name must resolve to ``10.0.0.11``, the IP address of the
management interface on the controller node.
To configure name resolution:
#. Set the hostname of the node to ``controller``::
# hostnamectl set-hostname controller
#. Edit the ``/etc/hosts`` file to contain the following::
# controller 10.0.0.11 controller
# compute1 10.0.0.31 compute1
Password summary
----------------
The following table provides a list of services that require passwords,
as well as their associated references in the guide:
.. csv-table:: Password Services
:header: "Password name", "Description"
:widths: 100, 100
"Database password (no variable used)", "Root password for the database."
"RABBIT_PASS", "Password of user ``guest`` of RabbitMQ."
"KEYSTONE_DBPASS", "Database password of Identity service."
"DEMO_PASS", "Password of user ``demo``."
"ADMIN_PASS", "Password of user ``admin``."
"GLANCE_DBPASS", "Database password for Image Service."
"GLANCE_PASS", "Password of Image Service user ``glance``."
"NOVA_DBPASS", "Database password for Compute service."
"NOVA_PASS", "Password of Compute service user ``nova``."
"DASH_DBPASS", "Database password for the dashboard."
"CINDER_DBPASS", "Database password for the Block Storage service."
"CINDER_PASS", "Password of Block Storage service user ``cinder``."
Next topic: :ref:`openstack_installing_bundles`.
source/openstack_telemetry.rst
-260
View File
@@ -1,260 +0,0 @@
.. _openstack_telemetry:
Telemetry
############################################################
Overview
---------
The OpenStack* Telemetry service performs the following functions:
- Efficiently polls metering data related to OpenStack services
- Collects event and metering data by monitoring notifications sent
from services
- Publishes collected data to various targets, including data stores
and message queues
- Creates alarms when collected data breaks defined rules
Installing and configuring
---------------------------
This section describes how to install and configure the Telemetry
service, code-named ceilometer, on the controller node. The Telemetry
service collects measurements from most OpenStack services and optionally
triggers alarms.
Prerequisites
~~~~~~~~~~~~~~~
Before installing and configuring the ``telemetry`` service, install
MongoDB* and create a MongoDB database, service credentials, and API
endpoint.
#. Install the MongoDB bundle::
# swupd bundle-add database-mongodb
#. Create the ``/etc/mongodb/`` folder and the
``/etc/mongodb/openstack.cnf`` file.::
# mkdir /etc/mongodb
# touch /etc/mongodb/openstack.cnf
#. Configure the ``bind_ip`` key to use the management interface IP
address of the controller node by editing the ``/etc/mongodb/openstack.cnf`` file::
bind_ip = 10.0.0.11
#. Start the database service and configure it to start when the system
boots with the following commands::
# systemctl enable mongodb.service
# systemctl start mongodb.service
#. Create the ``ceilometer`` database. Replace *CEILOMETER_DBPASS*
with a suitable password::
# mongo --host controller --eval '
db = db.getSiblingDB("ceilometer");
db.createUser({user: "ceilometer",
pwd: "CEILOMETER_DBPASS",
roles: [ "readWrite", "dbAdmin" ]})'
MongoDB shell version: 3.1.7
connecting to: controller:27017/test
Successfully added user: { "user" : "ceilometer", "roles" : [ "readWrite", "dbAdmin" ] }
#. Source the ``admin`` credentials to gain access to admin-only CLI
commands::
$ source admin-openrc.sh
#. To create the service credentials, complete these steps:
* Create the ``ceilometer`` user::
$ openstack user create --domain default --password-prompt ceilometer
User Password:
Repeat User Password:
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | default |
| enabled | True |
| id | c859c96f57bd4989a8ea1a0b1d8ff7cd |
| name | ceilometer |
+-----------+----------------------------------+
* Add the ``admin`` role to the ``ceilometer`` user::
$ openstack role add --project service --user ceilometer admin
* Create the ``ceilometer`` service entity::
$ openstack service create --name ceilometer \
--description "Telemetry" metering
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | Telemetry |
| enabled | True |
| id | 3405453b14da441ebb258edfeba96d83 |
| name | ceilometer |
| type | metering |
+-------------+----------------------------------+
#. Create the Telemetry service API endpoints::
$ openstack endpoint create --region RegionOne \
metering public http://controller:8777
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | 340be3625e9b4239a6415d034e98aace |
| interface | public |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
| service_name | celiometer |
| service_type | metering |
| url | http://controller:8777 |
+--------------+----------------------------------+
$ openstack endpoint create --region RegionOne \
metering internal http://controller:8777
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | 340be3625e9b4239a6415d034e98aace |
| interface | internal |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
| service_name | celiometer |
| service_type | metering |
| url | http://controller:8777 |
+--------------+----------------------------------+
$ openstack endpoint create --region RegionOne \
metering admin http://controller:8777
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| enabled | True |
| id | 340be3625e9b4239a6415d034e98aace |
| interface | admin |
| region | RegionOne |
| region_id | RegionOne |
| service_id | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
| service_name | celiometer |
| service_type | metering |
| url | http://controller:8777 |
+--------------+----------------------------------+
Install and configure components
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. Install the OpenStack Telemetry Controller bundle::
# swupd bundle-add openstack-telemetry
#. Custom configurations will be located at ``/etc/ceilometer``.
* Create ``/etc/ceilometer`` directory::
# mkdir /etc/ceilometer
* Create the empty ceilometer configuration file::
# touch /etc/ceilometer/ceilometer.conf
#. Edit the ``/etc/ceilometer/ceilometer.conf`` file and
complete the following actions:
* In the ``[database]`` section, configure database access. Replace
*CEILOMETER_DBPASS* with the password you chose for the
Telemetry module database. You must escape special characters such
as ':', '/', '+', and '@' in the connection string in accordance
with RFC2396::
[database]
...
connection = mongodb://ceilometer:CEILOMETER_DBPASS@controller:27017/ceilometer
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections,
configure RabbitMQ message queue access. Replace *RABBIT_PASS*
with the password you chose for the ``openstack`` account in
RabbitMQ::
[DEFAULT]
...
rpc_backend = rabbit
[oslo_messaging_rabbit]
...
rabbit_host = controller
rabbit_userid = openstack
rabbit_password = RABBIT_PASS
* In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections,
configure Identity service access. Replace *CEILOMETER_PASS*
with the password you chose for the ``celiometer`` user in the
Identity service::
[DEFAULT]
...
auth_strategy = keystone
[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = ceilometer
password = CEILOMETER_PASS
* In the ``[service_credentials]`` section, configure service
credentials. Replace *CEILOMETER_PASS* with the password you
chose for the ``ceilometer`` user in the Identity service::
[service_credentials]
...
os_auth_url = http://controller:5000/v2.0
os_username = ceilometer
os_tenant_name = service
os_password = CEILOMETER_PASS
os_endpoint_type = internalURL
os_region_name = RegionOne
* Ensure files have proper ownership by running the following command::
# systemctl restart update-triggers.target
Finalizing installation
~~~~~~~~~~~~~~~~~~~~~~~~
#. Start the Telemetry services and configure them to start when the system boots::
# systemctl enable ceilometer-agent-central.service \
ceilometer-agent-notification.service \
ceilometer-api.service \
ceilometer-collector.service \
ceilometer-alarm-evaluator.service \
ceilometer-alarm-notifier.service
# systemctl start ceilometer-agent-central.service \
ceilometer-agent-notification.service \
ceilometer-api.service \
ceilometer-collector.service \
ceilometer-alarm-evaluator.service \
ceilometer-alarm-notifier.service
Next topic: :ref:`openstack_object_storage`.