Merge "Procedure to set the OpenStack domain (pick)"
This commit is contained in:
commit
990c45721c
@ -2,73 +2,13 @@
|
||||
Access StarlingX OpenStack
|
||||
==========================
|
||||
|
||||
Use local/remote CLIs, GUIs and/or REST APIs to access and manage StarlingX
|
||||
Use local/remote CLIs, GUIs and/or REST APIs to access and manage |prod|
|
||||
OpenStack and hosted virtualized applications.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:depth: 1
|
||||
|
||||
------------------------------
|
||||
Configure helm endpoint domain
|
||||
------------------------------
|
||||
|
||||
Containerized OpenStack services in StarlingX are deployed behind an ingress
|
||||
controller (nginx) that listens on either port 80 (HTTP) or port 443 (HTTPS).
|
||||
The ingress controller routes packets to the specific OpenStack service, such as
|
||||
the Cinder service, or the Neutron service, by parsing the FQDN in the packet.
|
||||
For example, `neutron.openstack.svc.cluster.local` is for the Neutron service,
|
||||
`cinder‐api.openstack.svc.cluster.local` is for the Cinder service.
|
||||
|
||||
This routing requires that access to OpenStack REST APIs must be via a FQDN
|
||||
or by using a remote OpenStack CLI that uses the REST APIs. You cannot access
|
||||
OpenStack REST APIs using an IP address.
|
||||
|
||||
FQDNs (such as `cinder‐api.openstack.svc.cluster.local`) must be in a DNS server
|
||||
that is publicly accessible.
|
||||
|
||||
.. note::
|
||||
|
||||
There is a way to wild‐card a set of FQDNs to the same IP address in a DNS
|
||||
server configuration so that you don’t need to update the DNS server every
|
||||
time an OpenStack service is added. Check your particular DNS server for
|
||||
details on how to wild-card a set of FQDNs.
|
||||
|
||||
In a “real” deployment, that is, not a lab scenario, you can not use the default
|
||||
`openstack.svc.cluster.local` domain name externally. You must set a unique
|
||||
domain name for your StarlingX system. StarlingX provides the
|
||||
:command:`system service‐parameter-add` command to configure and set the
|
||||
OpenStack domain name:
|
||||
|
||||
::
|
||||
|
||||
system service-parameter-add openstack helm endpoint_domain=<domain_name>
|
||||
|
||||
`<domain_name>` should be a fully qualified domain name that you own, such that
|
||||
you can configure the DNS Server that owns `<domain_name>` with the OpenStack
|
||||
service names underneath the domain.
|
||||
|
||||
For example:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
system service-parameter-add openstack helm endpoint_domain=my-starlingx-domain.my-company.com
|
||||
system application-apply |prefix|-openstack
|
||||
|
||||
This command updates the helm charts of all OpenStack services and restarts them.
|
||||
For example it would change `cinder‐api.openstack.svc.cluster.local` to
|
||||
`cinder‐api.my-starlingx-domain.my-company.com`, and so on for all OpenStack
|
||||
services.
|
||||
|
||||
.. note::
|
||||
|
||||
This command also changes the containerized OpenStack Horizon to listen on
|
||||
`horizon.my-starlingx-domain.my-company.com:80` instead of the initial
|
||||
`<oam‐floating‐ip>:31000`.
|
||||
|
||||
You must configure `{ ‘*.my-starlingx-domain.my-company.com’: --> oam‐floating‐ip‐address }`
|
||||
in the external DNS server that owns `my-company.com`.
|
||||
|
||||
---------
|
||||
Local CLI
|
||||
---------
|
||||
@ -84,7 +24,7 @@ You can use this method on either controller, active or standby.
|
||||
|
||||
**Do not** use ``source /etc/platform/openrc``.
|
||||
|
||||
#. Set the CLI context to the StarlingX OpenStack Cloud Application and set up
|
||||
#. Set the CLI context to the |prod-os| Cloud Application and set up
|
||||
OpenStack admin credentials:
|
||||
|
||||
::
|
||||
@ -111,14 +51,14 @@ You can use this method on either controller, active or standby.
|
||||
|
||||
**Method 2**
|
||||
|
||||
Use this method to access StarlingX Kubernetes commands and StarlingX OpenStack
|
||||
Use this method to access |prod| Kubernetes commands and |prod-os|
|
||||
commands in the same shell. You can only use this method on the active
|
||||
controller.
|
||||
|
||||
#. Log in to the active controller via the console or SSH with a
|
||||
sysadmin/<sysadmin-password>.
|
||||
|
||||
#. Set the CLI context to the StarlingX OpenStack Cloud Application and set up
|
||||
#. Set the CLI context to the |prod-os| Cloud Application and set up
|
||||
OpenStack admin credentials:
|
||||
|
||||
::
|
||||
@ -128,16 +68,16 @@ controller.
|
||||
|
||||
.. note::
|
||||
|
||||
To switch between StarlingX Kubernetes/Platform credentials and StarlingX
|
||||
OpenStack credentials, use ``source /etc/platform/openrc`` or
|
||||
``source ./openrc.os`` respectively.
|
||||
To switch between |prod| Kubernetes/Platform credentials and |prod-os|
|
||||
credentials, use ``source /etc/platform/openrc`` or ``source
|
||||
./openrc.os`` respectively.
|
||||
|
||||
|
||||
**********************
|
||||
OpenStack CLI commands
|
||||
**********************
|
||||
|
||||
Access OpenStack CLI commands for the StarlingX OpenStack cloud application
|
||||
Access OpenStack CLI commands for the |prod-os| cloud application
|
||||
using the :command:`openstack` command. For example:
|
||||
|
||||
::
|
||||
@ -162,14 +102,101 @@ The image below shows a typical successful run.
|
||||
:alt: starlingx-access-openstack-flavorlist
|
||||
:scale: 50%
|
||||
|
||||
*Figure 1: StarlingX OpenStack Flavorlist*
|
||||
*Figure 1: |prod-os| Flavorlist*
|
||||
|
||||
|
||||
.. figure:: /deploy_install_guides/r6_release/figures/starlingx-access-openstack-command.png
|
||||
:alt: starlingx-access-openstack-command
|
||||
:scale: 50%
|
||||
|
||||
*Figure 2: StarlingX OpenStack Commands*
|
||||
*Figure 2: |prod-os| Commands*
|
||||
|
||||
------------------------------
|
||||
Configure Helm endpoint domain
|
||||
------------------------------
|
||||
|
||||
Containerized OpenStack services in |prod| are deployed behind an ingress
|
||||
controller (nginx) that listens on either port 80 (HTTP) or port 443 (HTTPS).
|
||||
The ingress controller routes packets to the specific OpenStack service, such as
|
||||
the Cinder service, or the Neutron service, by parsing the |FQDN| in the packet.
|
||||
For example, ``neutron.openstack.svc.cluster.local`` is for the Neutron service,
|
||||
``cinder‐api.openstack.svc.cluster.local`` is for the Cinder service.
|
||||
|
||||
This routing requires that access to OpenStack REST APIs must be via a |FQDN|
|
||||
or by using a remote OpenStack CLI that uses the REST APIs. You cannot access
|
||||
OpenStack REST APIs using an IP address.
|
||||
|
||||
FQDNs (such as ``cinder‐api.openstack.svc.cluster.local``) must be in a DNS
|
||||
server that is publicly accessible.
|
||||
|
||||
.. note::
|
||||
|
||||
There is a way to wild‐card a set of FQDNs to the same IP address in a DNS
|
||||
server configuration so that you don’t need to update the DNS server every
|
||||
time an OpenStack service is added. Check your particular DNS server for
|
||||
details on how to wild-card a set of FQDNs.
|
||||
|
||||
In a “real” deployment, that is, not a lab scenario, you cannot use the default
|
||||
``openstack.svc.cluster.local`` domain name externally. You must set a unique
|
||||
domain name for your |prod| system. |prod| provides the
|
||||
:command:`system service‐parameter-add` command to configure and set the
|
||||
OpenStack domain name:
|
||||
|
||||
::
|
||||
|
||||
system service-parameter-add openstack helm endpoint_domain=<domain_name>
|
||||
|
||||
``<domain_name>`` should be a fully qualified domain name that you own, such that
|
||||
you can configure the DNS Server that owns ``<domain_name>`` with the OpenStack
|
||||
service names underneath the domain.
|
||||
|
||||
For example:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
system service-parameter-add openstack helm endpoint_domain=my-starlingx-domain.my-company.com
|
||||
system application-apply |prefix|-openstack
|
||||
|
||||
This command updates the Helm charts of all OpenStack services and restarts them.
|
||||
For example it would change ``cinder‐api.openstack.svc.cluster.local`` to
|
||||
``cinder‐api.my-starlingx-domain.my-company.com``, and so on for all OpenStack
|
||||
services.
|
||||
|
||||
.. note::
|
||||
|
||||
This command also changes the containerized OpenStack Horizon to listen on
|
||||
``horizon.my-starlingx-domain.my-company.com:80`` instead of the initial
|
||||
``<oam‐floating‐ip>:31000``.
|
||||
|
||||
You must configure { ``*.my-starlingx-domain.my-company.com: --> oam‐floating‐ip‐address }``
|
||||
in the external DNS server that owns ``my-company.com``.
|
||||
|
||||
---------------------------
|
||||
Configure HTTPS Certificate
|
||||
---------------------------
|
||||
|
||||
This certificate must be valid for the domain configured for |prod-os|.
|
||||
|
||||
|
||||
#. Enable HTTPS for |prod|, see :ref:`Enable HTTPS Access for StarlingX REST
|
||||
and Web Server Endpoints
|
||||
<enable-https-access-for-starlingx-rest-and-web-server-endpoints>`.
|
||||
|
||||
.. note::
|
||||
|
||||
IF AND ONLY IF |prod-os| application is currently APPLIED when you do
|
||||
this, a |prod-os| application (re-)apply is internally triggered and
|
||||
fails because you have not setup the |prod-os| certificate yet.
|
||||
|
||||
#. Set the |prod-os| domain and configure your external DNS server, see
|
||||
:ref:`Update the Domain Name <update-the-domain-name>`.
|
||||
|
||||
#. Configure the |prod-os| certificate and configure |prod-os| services to use
|
||||
it, see :ref:`Install REST API and Horizon Certificate
|
||||
<install-rest-api-and-horizon-certificate>`.
|
||||
|
||||
#. Open port 443 in |prod| firewall, see :ref:`Modify Firewall Options
|
||||
<security-firewall-options>`.
|
||||
|
||||
----------
|
||||
Remote CLI
|
||||
@ -181,7 +208,7 @@ Documentation coming soon.
|
||||
GUI
|
||||
---
|
||||
|
||||
Access the StarlingX containerized OpenStack Horizon GUI in your browser at the
|
||||
Access the |prod| containerized OpenStack Horizon GUI in your browser at the
|
||||
following address:
|
||||
|
||||
::
|
||||
|
Loading…
x
Reference in New Issue
Block a user