Skip to content
Snippets Groups Projects
Commit 742960aa authored by Michal (inc0) Jastrzebski's avatar Michal (inc0) Jastrzebski Committed by chenxing
Browse files

Quickstart rewrite 


Nearly full rewrite of our QSG to make it more 2017.

Co-Authored-By: default avatarchenxing <chason.chan@foxmail.com>
Partially-Implements: blueprint ka-queens-doc-restructure
Change-Id: Ie558e1121438a502611c7c0e6c0e5ac0f6574827
parent 4d8816a0
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
doc/source/user/quickstart.rst
+ 230
− 442
View file @ 742960aa
......@@ -5,10 +5,16 @@ Quick Start
===========
This guide provides step by step instructions to deploy OpenStack using Kolla
and Kolla-Ansible on bare metal servers or virtual machines.
on bare metal servers or virtual machines.
Recommended reading
~~~~~~~~~~~~~~~~~~~
It's beneficial to learn basics of both `Ansible <https://docs.ansible.com>`__
and `Docker <https://docs.docker.com>`__ before running Kolla-Ansible.
Host machine requirements
=========================
~~~~~~~~~~~~~~~~~~~~~~~~~
The host machine must satisfy the following minimum requirements:
......@@ -20,96 +26,41 @@ The host machine must satisfy the following minimum requirements:
Root access to the deployment host machine is required.
Recommended environment
=======================
This guide recommends using a bare metal server or a virtual machine. Follow
the instructions in this document to get started with deploying OpenStack on
bare metal or a virtual machine with Kolla.
If developing Kolla on a system that provides VirtualBox or Libvirt in addition
to Vagrant, use the Vagrant virtual environment documented in
`Development Environment with Vagrant <https://docs.openstack.org/kolla-ansible/latest/contributor/vagrant-dev-env.html>`_.
Prerequisites
=============
Verify the state of network interfaces. If using a VM spawned on
OpenStack as the host machine, the state of the second interface will be DOWN
on booting the VM.
::
ip addr show
Bring up the second network interface if it is down.
::
ip link set ens4 up
Verify if the second interface has an IP address.
::
ip addr show
Install dependencies
====================
Kolla builds images which are used by Kolla-Ansible to deploy OpenStack. The
deployment is tested on CentOS, Oracle Linux and Ubuntu as both container OS
platforms and bare metal deployment targets.
.. note:: Install is *very* sensitive about version of components. Please
review carefully because default Operating System repos are likely out of
date.
Dependencies for the stable/ocata branch are:
===================== =========== =========== =========================
Component Min Version Max Version Comment
===================== =========== =========== =========================
Ansible 2.0.0 none On deployment host
Docker 1.10.0 none On target nodes
Docker Python 1.8.1 none On target nodes
Python Jinja2 2.8.0 none On deployment host
===================== =========== =========== =========================
Dependencies since pike (including master branch) are:
===================== =========== =========== =========================
Component Min Version Max Version Comment
===================== =========== =========== =========================
Ansible 2.2.0 none On deployment host
Docker 1.10.0 none On target nodes
Docker Python 2.0.0 none On target nodes
Python Jinja2 2.8.0 none On deployment host
===================== =========== =========== =========================
~~~~~~~~~~~~~~~~~~~~
Make sure the ``pip`` package manager is installed and upgraded to the latest
before proceeding:
before proceeding.
For CentOS, run:
::
#CentOS
yum install epel-release
yum install python-pip
pip install -U pip
#Ubuntu
For Ubuntu, run:
::
apt-get update
apt-get install python-pip
pip install -U pip
Install dependencies needed to build the code with ``pip`` package manager.
To build the code with ``pip`` package manager, install the following
dependencies:
For CentOS, run:
::
#CentOS
yum install python-devel libffi-devel gcc openssl-devel libselinux-python
#Ubuntu
For Ubuntu, run:
::
apt-get install python-dev libffi-dev gcc libssl-dev python-selinux
Kolla deploys OpenStack using `Ansible <http://www.ansible.com>`__. Install
......@@ -137,7 +88,9 @@ installed using:
pip install -U ansible
.. note:: It is recommended to use virtualenv to install non-system packages.
.. note::
It is recommended to use virtualenv to install non-system packages.
If DEB based systems include a version of Ansible that meets Kolla's version
requirements it can be installed by:
......@@ -146,200 +99,59 @@ requirements it can be installed by:
apt-get install ansible
.. WARNING::
Kolla uses `Python Build Reasonableness (PBR) <https://docs.openstack.org/pbr/latest/>`_
in its implementation. ``PBR`` provides version information to Kolla about
the package in use. This information is later used when building images to
specify the Docker tag used in the image built. When installing the Kolla
package via pip, ``PBR`` will always use the ``PBR`` version information.
When obtaining a copy of the software via git, ``PBR`` will use the git
version information, but **ONLY** if Kolla has not been pip installed via
the pip package manager. This is why there is an operator workflow and a
developer workflow.
The following dependencies can be installed by bootstraping the host machine
as described in the `Automatic host bootstrap`_ section. For manual
installation, follow the instructions below:
Since Docker is required to build images as well as be present on all deployed
targets, the Kolla community recommends installing the official Docker, Inc.
packaged version of Docker for maximum stability and compatibility with the
following command:
It's beneficial to add the following options to ansible
configuration file ``/etc/ansible/ansible.cfg``:
::
curl -sSL https://get.docker.io | bash
[defaults]
host_key_checking=False
pipelining=True
forks=100
This command will install the most recent stable version of Docker, but please
note that Kolla releases are not in sync with Docker in any way, so some things
could stop working with new version. The latest release of Kolla is tested to
work with docker-engine>=1.10.0,!=1.13.0. To check your Docker version run this
command:
::
docker --version
When running with systemd, setup docker-engine with the appropriate information
in the Docker daemon to launch with. This means setting up the following
information in the ``docker.service`` file. If you do not set the MountFlags
option correctly then ``kolla-ansible`` will fail to deploy the
``neutron-dhcp-agent`` container and throws APIError/HTTPError. After adding
the drop-in unit file as follows, reload and restart the Docker service:
::
# Create the drop-in unit directory for docker.service
mkdir -p /etc/systemd/system/docker.service.d
# Create the drop-in unit file
tee /etc/systemd/system/docker.service.d/kolla.conf <<-'EOF'
[Service]
MountFlags=shared
EOF
Restart Docker by executing the following commands:
::
# Run these commands to reload the daemon
systemctl daemon-reload
systemctl restart docker
On the target hosts you also need to install the latest version of the Docker
python libraries with pip:
::
pip install -U docker
OpenStack, RabbitMQ, and Ceph require all hosts to have matching times to
ensure proper message delivery. In the case of Ceph, it will complain if the
hosts differ by more than 0.05 seconds. Some OpenStack services have timers as
low as 2 seconds by default. For these reasons it is highly recommended to
setup an NTP service of some kind. While ``ntpd`` will achieve more accurate
time for the deployment if the NTP servers are running in the local deployment
environment, `chrony <http://chrony.tuxfamily.org>`_ is more accurate when
syncing the time across a WAN connection. When running Ceph it is recommended
to setup ``ntpd`` to sync time locally due to the tight time constraints.
To install, start, and enable ntp on CentOS execute the following:
::
# CentOS 7
yum install ntp
systemctl enable ntpd.service
systemctl start ntpd.service
To install and start on Debian based systems execute the following:
::
apt-get install ntp
Libvirt is started by default on many operating systems. Please disable
``libvirt`` on any machines that will be deployment targets. Only one copy of
libvirt may be running at a time.
::
# CentOS 7
systemctl stop libvirtd.service
systemctl disable libvirtd.service
# Ubuntu
service libvirt-bin stop
update-rc.d libvirt-bin disable
On Ubuntu, apparmor will sometimes prevent libvirt from working.
::
Install Kolla
~~~~~~~~~~~~~
/usr/sbin/libvirtd: error while loading shared libraries:
libvirt-admin.so.0: cannot open shared object file: Permission denied
Install Kolla for deployment or evaluation
------------------------------------------
If you are seeing the libvirt container fail with the error above, disable the
libvirt profile.
Install kolla-ansible and its dependencies using ``pip``.
::
sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd
.. note::
On Ubuntu 16.04, please uninstall lxd and lxc packages. (An issue exists
with cgroup mounts, mounts exponentially increasing when restarting
container).
Additional steps for upstart and other non-systemd distros
==========================================================
For other non-systemd distros, run the following.
::
pip install kolla-ansible
mount --make-shared /run
mount --make-shared /var/lib/nova/mnt
Copy ``globals.yml`` and ``passwords.yml`` to ``/etc/kolla`` directory.
If /var/lib/nova/mnt is not present, do the workaround below.
For CentOS, run:
::
mkdir -p /var/lib/nova/mnt /var/lib/nova/mnt1
mount --bind /var/lib/nova/mnt1 /var/lib/nova/mnt
mount --make-shared /var/lib/nova/mnt
cp -r /usr/share/kolla-ansible/etc_examples/kolla /etc/kolla/
For mounting /run and /var/lib/nova/mnt as shared upon startup, edit
/etc/rc.local to add the following.
For Ubuntu, run:
::
mount --make-shared /run
mount --make-shared /var/lib/nova/mnt
.. note::
If CentOS/Fedora/OracleLinux container images are built on an Ubuntu host,
the back-end storage driver must not be AUFS (see the known issues in
`Building Container Images`_).
Install Kolla for deployment or evaluation
==========================================
Install kolla-ansible and its dependencies using pip.
::
cp -r /usr/local/share/kolla-ansible/etc_examples/kolla /etc/kolla/
pip install kolla-ansible
Copy the ``all-in-one`` and ``multinode`` inventory files to
the current directory.
Copy the configuration files globals.yml and passwords.yml to /etc directory.
For CentOS, run:
::
#CentOS
cp -r /usr/share/kolla-ansible/etc_examples/kolla /etc/kolla/
#Ubuntu
cp -r /usr/local/share/kolla-ansible/etc_examples/kolla /etc/kolla/
cp /usr/share/kolla-ansible/ansible/inventory/* .
The inventory files (all-in-one and multinode) are located in
/usr/local/share/kolla-ansible/ansible/inventory. Copy the configuration files
to the current directory.
For Ubuntu, run:
::
#CentOS
cp /usr/share/kolla-ansible/ansible/inventory/* .
#Ubuntu
cp /usr/local/share/kolla-ansible/ansible/inventory/* .
Install Kolla for development
=============================
-----------------------------
Clone the Kolla and Kolla-Ansible repositories from git.
......@@ -348,331 +160,307 @@ Clone the Kolla and Kolla-Ansible repositories from git.
git clone https://github.com/openstack/kolla
git clone https://github.com/openstack/kolla-ansible
Kolla-ansible holds configuration files (globals.yml and passwords.yml) in
etc/kolla. Copy the configuration files to /etc directory.
Kolla-ansible holds the configuration files (``globals.yml`` and
``passwords.yml``) in ``etc/kolla``. Copy the configuration
files to ``/etc/kolla`` directory.
::
cp -r kolla-ansible/etc/kolla /etc/kolla/
Kolla-ansible holds the inventory files (all-in-one and multinode) in
ansible/inventory. Copy the configuration files to the current directory.
Kolla-ansible holds the inventory files (``all-in-one`` and ``multinode``)
in ``ansible/inventory``. Copy the inventory files to the current
directory.
::
cp kolla-ansible/ansible/inventory/* .
Local Registry
==============
A local registry is recommended but not required for an ``all-in-one``
installation when developing for master. Since no master images are available
on docker hub, the docker cache may be used for all-in-one deployments. When
deploying multinode, a registry is strongly recommended to serve as a single
source of images. Reference the
`Multinode Deployment of Kolla <https://docs.openstack.org/project-deploy-guide/kolla-ansible/pike/multinode.html>`_
for more information on using a local Docker registry.
Otherwise, the `Docker Hub Image Registry`_ contains all
images from each of Kolla’s major releases. The latest release tag is 5.0.0 for
Pike.
Prepare initial configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Automatic host bootstrap
========================
Inventory
---------
Edit the ``/etc/kolla/globals.yml`` file to configure interfaces.
::
Next step is to prepare our inventory file. Inventory is an ansible file where
we specify node roles and access credentials.
network_interface: "ens3"
neutron_external_interface: "ens4"
Kolla-Ansible comes with ``all-in-one`` and ``multinode`` example inventory
files. Difference between them is that the former is ready for deploying
single node OpenStack on localhost. If you need to use separate host or more
than one node, edit ``multinode`` inventory:
Generate passwords. This will populate all empty fields in the
``/etc/kolla/passwords.yml`` file using randomly generated values to secure the
deployment. Optionally, the passwords may be populated in the file by hand.
Edit the first section of ``multinode`` with connection details of your environment,
for example:
::
kolla-genpwd
[control]
10.0.0.[10:12] ansible_user=ubuntu ansible_password=foobar ansible_become=true
# Ansible supports syntax like [10:12] - that means 10, 11 and 12.
# Become clausule means "use sudo".
To quickly prepare hosts, playbook bootstrap-servers can be used. This is an
Ansible playbook which works on Ubuntu 16.04 and CentOS 7 hosts to
install and prepare the cluster for OpenStack installation.
[network:children]
control
# when you specify group_name:children, it will use contents of group specified.
::
[compute]
10.0.0.[13:14] ansible_user=ubuntu ansible_password=foobar ansible_become=true
kolla-ansible -i <<inventory file>> bootstrap-servers
[monitoring]
10.0.0.10
# This group is for monitoring node.
# Fill it with one of the controllers' IP address or some others.
Build container images
======================
[storage:children]
compute
When running with systemd, edit the file
``/etc/systemd/system/docker.service.d/kolla.conf``
to include the MTU size to be used for Docker containers.
[deployment]
localhost ansible_connection=local become=true
# use localhost and sudo
::
To learn more about inventory files, check
`Ansible documentation <http://docs.ansible.com/ansible/latest/intro_inventory.html>`_.
[Service]
MountFlags=shared
ExecStart=
ExecStart=/usr/bin/docker daemon \
-H fd:// \
--mtu 1400
To confirm that our inventory is correct, run:
.. note::
::
Depend of your Docker version and distro, ExecStart command may be
different which may cause Docker start failures. If your docker version
is >= 1.13.0, the ``docker daemon`` is moved to ``dockerd``, and should
be used instead. The default ExecStart command for your system can be
obtained from ``/usr/lib/systemd/system/docker.service``.
ansible -m ping all
.. note::
The MTU size should be less than or equal to the MTU size allowed on the
network interfaces of the host machine. If the MTU size allowed on the
network interfaces of the host machine is 1500 then this step can be
skipped. This step is relevant for building containers. Actual openstack
services won't be affected.
Ubuntu might not come with python pre-installed. That will cause
errors in ping module. To quickly install python with ansible you
can run ``ansible -m raw -a "apt-get -y install python-dev all"``
.. note::
Kolla passwords
---------------
Verify that the MountFlags parameter is configured as shared. If you do not
set the MountFlags option correctly then kolla-ansible will fail to deploy the
neutron-dhcp-agent container and throws APIError/HTTPError.
Passwords used in our deployment are stored in ``/etc/kolla/passwords.yml``
file. All passwords are blank in this file and have to be filled either
manually or by running random password generator:
Restart Docker and ensure that Docker is running.
For deployment or evaluation, run:
::
systemctl daemon-reload
systemctl restart docker
kolla-genpwd
The Kolla community builds and pushes tested images for each tagged release of
Kolla. Pull required images with appropriate tags in target nodes.
For development, run:
::
kolla-ansible pull -i /path/to/all-in-one
cd kolla-ansible/tools
./generate_passwords.py
View the images.
Kolla globals.yml
-----------------
::
``globals.yml`` is the main configuration file for Kolla-Ansible.
There are a few options that are required to deploy Kolla-Ansible:
docker images
* Image options
Developers running from master are required to build container images as the
Docker Hub does not contain built images for the master branch. Reference the
`Building Container Images`_ for more advanced build configuration.
User has to specify images that are going to be used for our deployment.
In this guide `DockerHub <https://hub.docker.com/u/kolla/>`__ provided
pre-built images are going to be used. To learn more about building
mechanism, please refer `image building documentation
<https://docs.openstack.org/kolla/latest/admin/image-building.html>`_.
To build images using default parameters run:
Kolla provides choice of several Linux distributions in containers:
::
- Centos
- Ubuntu
- Oraclelinux
- Debian
- RHEL
kolla-build
For newcomers, we recommend to use CentOS 7 or Ubuntu 16.04.
By default kolla-build will build all containers using CentOS as the base image
and binary installation as base installation method. To change this behavior,
please use the following parameters with kolla-build:
::
::
kolla_base_distro: "centos"
--base [ubuntu|centos|oraclelinux]
--type [binary|source]
Next "type" of installation needs to be configured.
Choices are:
.. note::
binary
using repositories like apt or yum
``--base`` and ``--type`` can be added to the above kolla-build command if
different distributions or types are desired.
source
using raw source archives, git repositories or local source directory
It is also possible to build individual container images. As an example, if the
glance images failed to build, all glance related images can be rebuilt as
follows:
.. note::
::
This only affects OpenStack services. Infrastructure services like Ceph are
always "binary".
kolla-build glance
.. note::
In order to see all available parameters, run:
Source builds are proven to be slightly more reliable than binary.
::
::
kolla-build -h
kolla_install_type: "source"
View the images.
To use DockerHub images, the default image tag has to be overriden. Images are
tagged with release names. For example to use stable Pike images set
::
::
docker images
openstack_release: "pike"
.. WARNING::
It's important to use same version of images as kolla-ansible. That
means if pip was used to install kolla-ansible, that means it's latest stable
version so ``openstack release`` should be set to pike. If git was used with
master branch, DockerHub also provides daily builds of master branch (which is
tagged as ``master``):
Mixing of OpenStack releases with Kolla releases (example, updating
kolla-build.conf to build Mitaka Keystone to be deployed with Newton Kolla) is
not recommended and will likely cause issues.
::
Deploy Kolla
============
openstack_release: "master"
Kolla-Ansible is used to deploy containers by using images built by Kolla.
There are two methods of deployment: *all-in-one* and *multinode*. The
*all-in-one* deployment is similar to `devstack
<https://docs.openstack.org/devstack/latest/>`__ deploy which installs all
OpenStack services on a single host. In the *multinode* deployment, OpenStack
services can be run on specific hosts. This documentation describes deploying
an *all-in-one* setup. To setup *multinode* see the
`Multinode Deployment of Kolla <https://docs.openstack.org/project-deploy-guide/kolla-ansible/pike/multinode.html>`_.
* Networking
.. note::
Kolla-Ansible requires a few networking options to be set.
We need to set network interfaces used by OpenStack.
For *multinode* deployment of kolla, check if all the hostnames are
resolvable. RabbitMQ can't work with IP addresses, so we need to make
sure that all RabbitMQ cluster hosts can resolve each other's hostnames.
First interface to set is "network_interface". This is the default interface
for multiple management-type networks.
Each method is represented as an Ansible inventory file. More information on
the Ansible inventory file can be found in the Ansible `inventory introduction
<https://docs.ansible.com/intro_inventory.html>`_.
::
All variables for the environment can be specified in the files:
``/etc/kolla/globals.yml`` and ``/etc/kolla/passwords.yml``.
network_interface: "eth0"
Generate passwords for ``/etc/kolla/passwords.yml`` using the provided
``kolla-genpwd`` tool. The tool will populate all empty fields in the
``/etc/kolla/passwords.yml`` file using randomly generated values to secure the
deployment. Optionally, the passwords may be populate in the file by hand.
Second interface required is dedicated for Neutron external (or public) networks,
can be vlan or flat, depends on how the networks are created. This interface
should be active without IP address. If not, instances won't be able to access
to the external networks.
::
::
kolla-genpwd
neutron_external_interface: "eth1"
Start by editing ``/etc/kolla/globals.yml``. Check and edit, if needed, these
parameters: ``kolla_base_distro``, ``kolla_install_type``. The default for
``kolla_base_distro`` is ``centos`` and for ``kolla_install_type`` is
``binary``. If you want to use ubuntu with source type, then you should make
sure globals.yml has the following entries:
To learn more about network configuration, refer `Network overview
<https://docs.openstack.org/kolla-ansible/latest/admin/production-architecture-guide.html#network-configuration>`_.
::
Next we need to provide floating IP for management traffic. This IP will be
managed by keepalived to provide high availability, and should be set to be
*not used* address in management network that is connected to our
``network_interface``.
kolla_base_distro: "ubuntu"
kolla_install_type: "source"
::
Please specify an unused IP address in the network to act as a VIP for
``kolla_internal_vip_address``. The VIP will be used with keepalived and added
to the ``api_interface`` as specified in the ``globals.yml``
kolla_internal_vip_address: "10.1.0.250"
::
* Enable additional services
kolla_internal_vip_address: “192.168.137.79”
By default Kolla-Ansible provides a bare compute kit, however it does provide
support for a vast selection of additional services. To enable them, set
``enable_*`` to "yes". For example, to enable Block Storage service:
.. note::
::
The kolla_internal_vip_address must be unique and should belong to the same
network to which the first network interface belongs to.
enable_cinder: "yes"
.. note::
Kolla now supports many OpenStack services, there is
`a list of available services
<https://github.com/openstack/kolla-ansible/blob/master/README.rst#openstack-services>`_.
For more information about service configuration, Please refer to the
`Services Reference Guide
<https://docs.openstack.org/kolla-ansible/latest/reference/index.html>`_.
The kolla_base_distro and kolla_install_type should be same as base and
install_type used in kolla-build command line.
Deployment
~~~~~~~~~~
The ``network_interface`` variable is the interface to which Kolla binds API
services. For example, when starting Mariadb, it will bind to the IP on the
interface list in the ``network_interface`` variable.
After configuration is set, we can proceed to the deployment phase. First we
need to setup basic host-level dependencies, like docker.
::
Kolla-Ansible provides a playbook that will install all required services in
the correct versions.
network_interface: "ens3"
* For deployment or evaluation, run:
The ``neutron_external_interface`` variable is the interface that will be used
for the external bridge in Neutron. Without this bridge the deployment instance
traffic will be unable to access the rest of the Internet.
#. Bootstrap servers with kolla deploy dependencies:
::
::
neutron_external_interface: "ens4"
kolla-ansible -i ./multinode bootstrap-servers
In case of deployment using the **nested** environment (eg. Using Virtualbox
VM’s, KVM VM’s), verify if your compute node supports hardware acceleration for
virtual machines by executing the following command in the *compute node*.
#. Do pre-deployment checks for hosts:
::
::
egrep -c '(vmx|svm)' /proc/cpuinfo
kolla-ansible -i ./multinode prechecks
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. Create a file /etc/kolla/config/nova/nova-compute.conf and add
the content shown below.
#. Finally proceed to actual OpenStack deployment:
::
::
mkdir -p /etc/kolla/config/nova
cat << EOF > /etc/kolla/config/nova/nova-compute.conf
[libvirt]
virt_type = qemu
cpu_mode = none
EOF
kolla-ansible -i ./multinode deploy
For *all-in-one* deployments, the following commands can be run. These will
setup all of the containers on the localhost. These commands will be
wrapped in the kolla-script in the future.
* For development, run:
.. note:: Even for all-in-one installs it is possible to use the Docker
registry for deployment, although not strictly required.
#. Bootstrap servers with kolla deploy dependencies:
First, validate that the deployment targets are in a state where Kolla may
deploy to them. Provide the correct path to inventory file in the following
commands.
::
::
cd kolla-ansible/tools
./kolla-ansible -i ./multinode bootstrap-servers
kolla-ansible prechecks -i /path/to/all-in-one
#. Do pre-deployment checks for hosts:
Deploy OpenStack.
::
::
./kolla-ansible -i ./multinode prechecks
kolla-ansible deploy -i /path/to/all-in-one
#. Finally proceed to actual OpenStack deployment:
List the running containers.
::
::
./kolla-ansible -i ./multinode deploy
docker ps -a
When this playbook finishes, OpenStack should be up, running and functional!
If error occurs during execution, refer to
`troubleshooting guide <https://docs.openstack.org/kolla-ansible/latest/user/troubleshooting.html>`_.
Generate the ``admin-openrc.sh`` file. The file will be created in
``/etc/kolla/`` directory.
Using OpenStack
~~~~~~~~~~~~~~~
OpenStack requires an openrc file where credentials for admin user etc are set.
To generate this file run
::
kolla-ansible post-deploy
. /etc/kolla/admin-openrc.sh
Install the python-openstackclient as per followed installation.
Install basic OpenStack CLI clients:
::
pip install python-openstackclient
pip install python-openstackclient python-glanceclient python-neutronclient
To test your deployment, run the following commands to initialize the network
with a glance image and neutron networks.
Depending on how you installed Kolla-Ansible, there is script that will create
example networks, images, and so on.
For pip install and CentOS host:
::
. /etc/kolla/admin-openrc.sh
. /usr/share/kolla-ansible/init-runonce
#centOS
/usr/share/kolla-ansible/init-runonce
For pip install and Ubuntu host:
#ubuntu
/usr/local/share/kolla-ansible/init-runonce
::
.. note::
. /usr/local/share/kolla-ansible/init-runonce
Different hardware results in variance with deployment times.
For git pulled source:
::
After successful deployment of OpenStack, the Horizon dashboard will be
available by entering IP address or hostname from ``kolla_external_fqdn``, or
``kolla_internal_fqdn``. If these variables were not set during deploy they
default to ``kolla_internal_vip_address``.
. kolla-ansible/tools/init-runonce
.. _Docker Hub Image Registry: https://hub.docker.com/u/kolla/
.. _launchpad bug: https://bugs.launchpad.net/kolla/+filebug
.. _Building Container Images: https://docs.openstack.org/kolla/latest/admin/image-building.html
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment