openstack-helm/doc/source/install/setup_openstack_client.rst
Vladimir Kozhukalov 1a885ddd1f Update deployment documentation
Recently we updated our test jobs so that all of them
use the `deploy-env` Ansible role which utilizes the
Kubeadm to deploy the test Kubernetes cluster.

The role works for both multi-node and single-node
environments. Although the deployment of Kubernetes itself
is out of scope of Openstack-Helm, we recommen using this
role to deploy test and development Kubernetes clusters.
So at the moment there is no need to provide
different sets of tools single-node and multi-node test envs.
Now this is a matter of the Ansible inventory file.

Also the deployment procedure of OpenStack on top of Kubernetes
using Helm is the same for multi-node and single-node clusters
because it only relies on the Kubernetes API.

We will be improving the `deploy-env` role even futher and
we will be cleaning up the deployment scripts and the documentation
so to provide a clear experience for the Openstack-Helm users.

Change-Id: I70236c4a2b870b52d2b01f65b1ef9b9518646964
2023-10-23 19:10:30 -05:00

36 lines
1.7 KiB
ReStructuredText

Setup OpenStack client
======================
The OpenStack client software is a crucial tool for interacting
with OpenStack services. In certain OpenStack-Helm deployment
scripts, the OpenStack client software is utilized to conduct
essential checks during deployment. Therefore, installing the
OpenStack client on the developer's machine is a vital step.
The script `setup-client.sh`_ can be used to setup the OpenStack
client.
.. code-block:: bash
cd ~/osh/openstack-helm
./tools/deployment/common/setup-client.sh
At this point you have to keep in mind that the above script configures
OpenStack client so it uses internal Kubernetes FQDNs like
`keystone.openstack.svc.cluster.local`. In order to be able to resolve these
internal names you have to configure the Kubernetes authoritative DNS server
(CoreDNS) to work as a recursive resolver and then add its IP (`10.96.0.10` by default)
to `/etc/resolv.conf`. This is only going to work when you try to access
to OpenStack services from one of Kubernetes nodes because IPs from the
Kubernetes service network are routed only between Kubernetes nodes.
If you wish to access OpenStack services from outside the Kubernetes cluster,
you need to expose the OpenStack Ingress controller using an IP address accessible
from outside the Kubernetes cluster, typically achieved through solutions like
`MetalLB`_ or similar tools. In this scenario, you should also ensure that you
have set up proper FQDN resolution to map to the external IP address and
create the necessary Ingress objects for the associated FQDN.
.. _setup-client.sh: https://opendev.org/openstack/openstack-helm/src/branch/master/tools/deployment/common/setup-client.sh
.. _MetalLB: https://metallb.universe.tf