diff --git a/doc/source/_includes/docker-proxy-config.rest b/doc/source/_includes/docker-proxy-config.rest index 132a3e0cd..2609a24bc 100644 --- a/doc/source/_includes/docker-proxy-config.rest +++ b/doc/source/_includes/docker-proxy-config.rest @@ -16,7 +16,7 @@ Set proxy at bootstrap To set the Docker proxy at bootstrap time, refer to :doc:`Ansible Bootstrap Configurations -<../deploy_install_guides/r3_release/ansible_bootstrap_configs>`. +<../deploy_install_guides/r6_release/ansible_bootstrap_configs>`. .. r3_end diff --git a/doc/source/configuration/cert_config.rst b/doc/source/configuration/cert_config.rst index 59f8859e0..a3a532981 100644 --- a/doc/source/configuration/cert_config.rst +++ b/doc/source/configuration/cert_config.rst @@ -56,9 +56,9 @@ self-signed certificate is automatically installed. In order to connect, remote clients must be configured to accept the self-signed certificate without verifying it. This is called *insecure mode*. -For secure-mode connections, a CA-signed certificate, or an ICA (intermediate -CA) signed certificate is required. Using a CA or ICA signed certificate is -strongly recommended. +For secure-mode connections, a CA-signed certificate, or an ICA (intermediate +CA) signed certificate is required. Using a CA or ICA signed certificate is +strongly recommended. * To install (or update) the certificate used by StarlingX REST API applications and the StarlingX Horizon GUI: @@ -66,12 +66,12 @@ strongly recommended. ~(keystone_admin)]$ system certificate-install -m ssl - where ```` == a PEM file containing both the private key - and the signed public certificate. In the case of an ICA signed certificate, - the PEM file also contains the intermediate CA certificates. The certificates - in the file should be ordered such that each of the certificates is signed - by the succeeding one, with the public certificate as the very first in the - list. + where ```` == a PEM file containing both the private key + and the signed public certificate. In the case of an ICA signed certificate, + the PEM file also contains the intermediate CA certificates. The certificates + in the file should be ordered such that each of the certificates is signed + by the succeeding one, with the public certificate as the very first in the + list. You can update the certificate used by StarlingX platform at any time after installation. @@ -108,7 +108,7 @@ Certificate Authority. Currently the Kubernetes root CA certificate and key can only be updated at Ansible bootstrap time. For details, see -:ref:`Kubernetes root CA certificate and key `. +:ref:`Kubernetes root CA certificate and key `. --------------------- Local Docker registry @@ -116,8 +116,8 @@ Local Docker registry HTTPS is always enabled for the local Docker registry. Similarly, a self-signed certificate is used by default, however, we recommend that you update the -certificate with a certificate signed by a Certificate Authority or an -intermediate Certificate Authority after installation. +certificate with a certificate signed by a Certificate Authority or an +intermediate Certificate Authority after installation. * To install (or update) the certificate used by the local Docker registry: :: @@ -125,10 +125,10 @@ intermediate Certificate Authority after installation. ~(keystone_admin)]$ system certificate-install -m docker_registry where ```` == a PEM file containing both the private key and - the signed public certificate. In the case of an ICA signed certificate, the - PEM file also contains the intermediate CA certificates. The certificates in - the file should be ordered such that each of the certificates is signed by - the succeeding one, with the public certificate as the very first in the list. + the signed public certificate. In the case of an ICA signed certificate, the + PEM file also contains the intermediate CA certificates. The certificates in + the file should be ordered such that each of the certificates is signed by + the succeeding one, with the public certificate as the very first in the list. Note that the CA-signed certificate for the registry must have at least the following :abbr:`SANs (Subject Alternative Names)`: diff --git a/doc/source/deploy/deployment-and-configuration-options-standard-configuration-with-controller-storage.rst b/doc/source/deploy/deployment-and-configuration-options-standard-configuration-with-controller-storage.rst index aca7abf22..72c74a028 100644 --- a/doc/source/deploy/deployment-and-configuration-options-standard-configuration-with-controller-storage.rst +++ b/doc/source/deploy/deployment-and-configuration-options-standard-configuration-with-controller-storage.rst @@ -10,7 +10,7 @@ Standard Configuration with Controller Storage back-end for Kubernetes |PVCs| deployed on the controller nodes instead of using dedicated storage nodes. -.. image:: /deploy_install_guides/r5_release/figures/starlingx-deployment-options-controller-storage.png +.. image:: /deploy_install_guides/r6_release/figures/starlingx-deployment-options-controller-storage.png :width: 800 See :ref:`Common Components ` for a description of common diff --git a/doc/source/deploy/deployment-config-options-all-in-one-duplex-configuration.rst b/doc/source/deploy/deployment-config-options-all-in-one-duplex-configuration.rst index ee19d2e4b..3f6b68b90 100644 --- a/doc/source/deploy/deployment-config-options-all-in-one-duplex-configuration.rst +++ b/doc/source/deploy/deployment-config-options-all-in-one-duplex-configuration.rst @@ -14,7 +14,7 @@ redundant pair of hosts. :local: :depth: 1 -.. image:: /deploy_install_guides/r5_release/figures/starlingx-deployment-options-duplex.png +.. image:: /deploy_install_guides/r6_release/figures/starlingx-deployment-options-duplex.png :width: 800 See :ref:`Common Components ` for a description of common @@ -97,7 +97,7 @@ Up to fifty worker/compute nodes can be added to the All-in-one Duplex deployment, allowing a capacity growth path if starting with an AIO-Duplex deployment. -.. image:: /deploy_install_guides/r5_release/figures/starlingx-deployment-options-duplex-extended.png +.. image:: /deploy_install_guides/r6_release/figures/starlingx-deployment-options-duplex-extended.png :width: 800 The extended capacity is limited up to fifty worker/compute nodes as the diff --git a/doc/source/deploy/deployment-config-optionsall-in-one-simplex-configuration.rst b/doc/source/deploy/deployment-config-optionsall-in-one-simplex-configuration.rst index 30de4b817..693f841a6 100644 --- a/doc/source/deploy/deployment-config-optionsall-in-one-simplex-configuration.rst +++ b/doc/source/deploy/deployment-config-optionsall-in-one-simplex-configuration.rst @@ -10,7 +10,7 @@ The AIO Simplex deployment configuration provides a scaled-down |prod| that combines controller, storage, and worker functionality on a single non-redundant host. -.. image:: /deploy_install_guides/r5_release/figures/starlingx-deployment-options-simplex.png +.. image:: /deploy_install_guides/r6_release/figures/starlingx-deployment-options-simplex.png :width: 800 .. note:: diff --git a/doc/source/deploy/standard-configuration-with-dedicated-storage.rst b/doc/source/deploy/standard-configuration-with-dedicated-storage.rst index b4983fffe..8bd290b54 100644 --- a/doc/source/deploy/standard-configuration-with-dedicated-storage.rst +++ b/doc/source/deploy/standard-configuration-with-dedicated-storage.rst @@ -9,7 +9,7 @@ Standard Configuration with Dedicated Storage Deployment of |prod| with dedicated storage nodes provides the highest capacity \(single region\), performance, and scalability. -.. image:: /deploy_install_guides/r5_release/figures/starlingx-deployment-options-dedicated-storage.png +.. image:: /deploy_install_guides/r6_release/figures/starlingx-deployment-options-dedicated-storage.png :width: 800 See :ref:`Common Components ` for a description of common diff --git a/doc/source/deploy_install_guides/index.rst b/doc/source/deploy_install_guides/index.rst index 53b00e01c..4ef7ea5e7 100755 --- a/doc/source/deploy_install_guides/index.rst +++ b/doc/source/deploy_install_guides/index.rst @@ -6,41 +6,28 @@ Installation and deployment guides for StarlingX are release-specific. Each guide provides instruction on a specific StarlingX configuration (e.g. All-in-one Simplex). -.. _latest_release: - ------------------------- -Supported release (R4.0) ------------------------- - -StarlingX R4.0 is the most recent supported release of StarlingX. - -.. toctree:: - :maxdepth: 1 - - r4_release/index - ------------------------- Upcoming release (latest) ------------------------- -StarlingX R5.0 is under development. +StarlingX R6.0 is under development. .. toctree:: :maxdepth: 1 - r5_release/index + r6_release/index ------------------ -Archived releases ------------------ +------------------------------- +Supported and archived releases +------------------------------- -.. toctree:: - :maxdepth: 1 +StarlingX R5.0 is the most recent supported release of StarlingX. + +To view the R5.0 documentation, use the **Version** selector in the upper right +or go directly to `Installation guides for R5.0 and older releases +`_. - r3_release/index - r2_release/index - r1_release/index .. Add common files to toctree @@ -52,16 +39,18 @@ Archived releases bootable_usb nvme_config +.. Docs note: Starting with R5 (May 2021), team agreed that the latest/working + branch will include the current install guides only. The archived releases + will only be available in a release-specific branch. The instructions below + are modified to reflect this change. .. Making a new release -.. 1. Archive the previous 'supported' release. - Move the toctree link from the Supported release section into the Archived - releases toctree. -.. 2. Make the previous 'upcoming' release the new 'supported'. - Move the toctree link from the Upcoming release section into the Supported - release. Update intro text for the Supported release section to use the +.. 1. Make the previous 'upcoming' release the new 'supported' release. + Copy the folder to the release-specific branch. + Copy the toctree link into the Supported section of install landing page. + Update intro text for the Supported release section to use the latest version. -.. 3. Add new 'upcoming' release, aka 'Latest' on the version button. +.. 2. Add new 'upcoming' release, aka 'Latest' on the version button. If new upcoming release docs aren't ready, remove toctree from Upcoming section and just leave intro text. Update text for the upcoming release version. Once the new upcoming docs are ready, add them in the @@ -70,9 +59,9 @@ Archived releases .. Adding new release docs .. 1. Make sure the most recent release versioned docs are complete for that release. -.. 2. Make a copy of the most recent release folder e.g. 'r4_release.' Rename - the folder for the new release e.g. 'r5_release'. +.. 2. Make a copy of the most recent release folder e.g. 'r6_release.' Rename + the folder for the new release e.g. 'r7_release'. .. 3. Search and replace all references to previous release number with the new - release number. For example replace all 'R4.0' with 'R5.0.' Also search + release number. For example replace all 'R6.0' with 'R7.0.' Also search and replace any links that may have a specific release number in the path. .. 4. Link new version on this page (the index page). diff --git a/doc/source/deploy_install_guides/r1_release/controller_storage.rst b/doc/source/deploy_install_guides/r1_release/controller_storage.rst deleted file mode 100644 index 90ef23456..000000000 --- a/doc/source/deploy_install_guides/r1_release/controller_storage.rst +++ /dev/null @@ -1,1004 +0,0 @@ -======================= -Controller storage R1.0 -======================= - -.. contents:: - :local: - :depth: 1 - -**NOTE:** The instructions to set up a StarlingX Cloud with Controller -Storage with containerized openstack services in this guide -are under development. -For approved instructions, see the -`StarlingX Cloud with Controller Storage wiki page `__. - ----------------------- -Deployment description ----------------------- - -The Controller Storage deployment option provides a 2x node high availability -controller / storage cluster with: - -- A pool of up to seven compute nodes. The pool size limit is due to the capacity of - the storage function. -- A growth path for storage to the full standard solution with an independent - CEPH storage cluster. -- High availability services running across the controller nodes in either - active/active or active/standby mode. -- Storage function running on top of LVM on single second disk, DRBD-synchronized - between the controller nodes. - -.. figure:: figures/starlingx-deployment-options-controller-storage.png - :scale: 50% - :alt: Controller Storage deployment configuration - - *Controller Storage deployment configuration* - -A Controller Storage deployment provides protection against overall controller -node and compute node failure: - -- On overall controller node failure, all controller high availability services - go active on the remaining healthy controller node. -- On overall compute node failure, virtual machines on a failed compute node are - recovered on the remaining healthy compute nodes. - ------------------------------------- -Preparing controller storage servers ------------------------------------- - -********** -Bare metal -********** - -Required servers: - -- Controllers: 2 -- Computes: 2 - 100 - -^^^^^^^^^^^^^^^^^^^^^ -Hardware requirements -^^^^^^^^^^^^^^^^^^^^^ - -The recommended minimum requirements for the physical servers where -Controller Storage is deployed include: - -- Minimum processor: - - - Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) 8 cores/socket - -- Memory: - - - 64 GB controller - - 32 GB compute - -- BIOS: - - - Hyper-Threading technology: Enabled - - Virtualization technology: Enabled - - VT for directed I/O: Enabled - - CPU power and performance policy: Performance - - CPU C state control: Disabled - - Plug & play BMC detection: Disabled - -- Primary disk: - - - 500 GB SSD or NVMe controller - - 120 GB (min. 10K RPM) compute - -- Additional disks: - - - One or more 500 GB disks (min. 10K RPM) compute - -- Network ports\* - - - Management: 10GE controller, compute - - OAM: 10GE controller - - Data: n x 10GE compute - -******************* -Virtual environment -******************* - -Run the libvirt QEMU setup scripts to set up virtualized OAM and -management networks: - -:: - - $ bash setup_network.sh - -Building XML for definition of virtual servers: - -:: - - $ bash setup_configuration.sh -c controllerstorage -i - -The default XML server definitions that are created by the previous script -are as follows: - -- controllerstorage-controller-0 -- controllerstorage-controller-1 -- controllerstorage-compute-0 -- controllerstorage-compute-1 - -^^^^^^^^^^^^^^^^^^^^^^^^^ -Power up a virtual server -^^^^^^^^^^^^^^^^^^^^^^^^^ - -To power up a virtual server, run the following command: - -:: - - $ sudo virsh start - -Here is an example: - -:: - - $ sudo virsh start controllerstorage-controller-0 - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Access virtual server consoles -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The XML for virtual servers in stx-tools repo, deployment/libvirt, -provides both graphical and text consoles. -Follow these steps to access a virtual server console: - -#. Access the graphical console in virt-manager by right-clicking on the - domain (i.e. the server) and selecting "Open". - -#. Access the textual console using the command "virsh console $DOMAIN", - where DOMAIN is the name of the server shown in virsh. - -#. When booting controller-0 for the first time, both the serial and - graphical consoles present the initial configuration menu for the - cluster. You can select the serial or graphical console for controller-0. - However, for the other nodes, you can only use the serial console - regardless of the selected option. - -#. Open the graphic console on all servers before powering them on to - observe the boot device selection and PXI boot progress. Run the "virsh - console $DOMAIN" command promptly after powering up to see the initial boot - sequence that follows the boot device selection. Only a few seconds exist - during which you can see the sequence. - --------------------------------- -Installing the controller-0 host --------------------------------- - -Installing controller-0 involves initializing a host with software and -then applying a bootstrap configuration from the command line. The -configured bootstrapped host becomes controller-0. - -Following is the general procedure: - -#. Be sure the StarlingX ISO is on a USB device and it is plugged into - the USB port of the server that will be controller-0 and then - power on the server. - -#. Configure the controller using the config_controller script. - -************************* -Initializing controller-0 -************************* - -This section describes how to initialize StarlingX in host controller-0. -Except where noted, you must execute all the commands from a console of -the host. - -#. Be sure the StarlingX ISO is on a USB device and it is plugged into - the USB port of the server that will be controller-0. - -#. Power on the server. - -#. Wait for the console to show the StarlingX ISO booting options: - - - **All-in-one Controller Configuration** - - - When the installer is loaded and the installer welcome screen - appears in the controller-0 host, select "All-in-one Controller Configuration" - for the type of installation. - - - **Graphical Console** - - - Select the "Graphical Console" as the console to use during - installation. - - - **Standard Security Boot Profile** - - - Select "Standard Security Boot Profile" as the Security Profile. - -#. Monitor the initialization. When the installation is complete, a reboot is initiated - on the controller-0 host. The GNU GRUB screen briefly displays and then - boots automatically into the StarlingX image. - -#. Log into controller-0 as user wrsroot and use wrsroot as the password. The - first time you log in as wrsroot, you are required to change your - password. Enter the current password (i.e. wrsroot): - - :: - - Changing password for wrsroot. - (current) UNIX Password: - -#. Enter a new password for the wrsroot account: - - :: - - New password: - -#. Enter the new password again to confirm it: - - :: - - Retype new password: - -#. The controller-0 is initialized with StarlingX and is ready for configuration. - -************************ -Configuring controller-0 -************************ - -This section describes how to interactively configure controller-0 -to bootstrap the system with minimal critical data. -Except where noted, you must execute all commands from the console -of the active controller (i.e. controller-0). - -When run interactively, the config_controller script presents a series -of prompts for initial configuration of StarlingX: - -- For the virtual environment, you can accept all the default values - immediately after "system date and time". -- For a physical deployment, answer the bootstrap configuration - questions with answers applicable to your particular physical setup. - -The script configures the first controller in the StarlingX -cluster as controller-0. The prompts are grouped by configuration -area. - -Follow this procedure to interactively configure controller-0: - -#. Start the script with no parameters: - - :: - - controller-0:~$ sudo config_controller - System Configuration - ================ - Enter ! at any prompt to abort... - ... - -#. Accept all the default values immediately after "system date and time": - -:: - - ... - Applying configuration (this will take several minutes): - - 01/08: Creating bootstrap configuration ... DONE - 02/08: Applying bootstrap manifest ... DONE - 03/08: Persisting local configuration ... DONE - 04/08: Populating initial system inventory ... DONE - 05:08: Creating system configuration ... DONE - 06:08: Applying controller manifest ... DONE - 07:08: Finalize controller configuration ... DONE - 08:08: Waiting for service activation ... DONE - - Configuration was applied - - Please complete any out of service commissioning steps with system - commands and unlock controller to proceed. - -#. After config_controller bootstrap configuration, REST API, CLI and - Horizon interfaces are enabled on the controller-0 OAM IP address. The - remaining installation instructions use the CLI. - ------------------------------------- -Provisioning controller-0 and system ------------------------------------- - -On controller-0, acquire Keystone administrative privileges: - -:: - - controller-0:~$ source /etc/nova/openrc - -********************************************* -Configuring provider networks at installation -********************************************* - -You must set up provider networks at installation so that you can attach -data interfaces and unlock the compute nodes. - -Set up one provider network of the vlan type and name it providernet-a: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ neutron providernet-create providernet-a --type=vlan - [wrsroot@controller-0 ~(keystone_admin)]$ neutron providernet-range-create --name providernet-a-range1 --range 100-400 providernet-a - -************************************* -Configuring Cinder on controller disk -************************************* - -Follow these steps: - -#. Review the available disk space and capacity and obtain the uuid of the - physical disk: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-list controller-0 - +--------------------------------------+-----------+---------+---------+-------+------------+--------------+... - | uuid | device_no | device_ | device_ | size_ | available_ | rpm |... - | | de | num | type | gib | gib | |... - +--------------------------------------+-----------+---------+---------+-------+------------+--------------+... - | 004f4c09-2f61-46c5-8def-99b2bdeed83c | /dev/sda | 2048 | HDD | 200.0 | 0.0 | |... - | 89694799-0dd8-4532-8636-c0d8aabfe215 | /dev/sdb | 2064 | HDD | 200.0 | 199.997 | |... - +--------------------------------------+-----------+---------+---------+-------+------------+--------------+... - -#. Create the 'cinder-volumes' local volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-lvg-add controller-0 cinder-volumes - +-----------------+--------------------------------------+ - | Property | Value | - +-----------------+--------------------------------------+ - | lvm_vg_name | cinder-volumes | - | vg_state | adding | - | uuid | ece4c755-241c-4363-958e-85e9e3d12917 | - | ihost_uuid | 150284e2-fb60-4169-ae75-7f444b8ca9bf | - | lvm_vg_access | None | - | lvm_max_lv | 0 | - | lvm_cur_lv | 0 | - | lvm_max_pv | 0 | - | lvm_cur_pv | 0 | - | lvm_vg_size_gib | 0.00 | - | lvm_vg_total_pe | 0 | - | lvm_vg_free_pe | 0 | - | created_at | 2018-08-22T03:59:30.685718+00:00 | - | updated_at | None | - | parameters | {u'lvm_type': u'thin'} | - +-----------------+--------------------------------------+ - -#. Create a disk partition to add to the volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-add controller-0 89694799-0dd8-4532-8636-c0d8aabfe215 199 -t lvm_phys_vol - +-------------+--------------------------------------------------+ - | Property | Value | - +-------------+--------------------------------------------------+ - | device_path | /dev/disk/by-path/pci-0000:00:03.0-ata-2.0-part1 | - | device_node | /dev/sdb1 | - | type_guid | ba5eba11-0000-1111-2222-000000000001 | - | type_name | None | - | start_mib | None | - | end_mib | None | - | size_mib | 203776 | - | uuid | 9ba2d76a-6ae2-4bfa-ad48-57b62d102e80 | - | ihost_uuid | 150284e2-fb60-4169-ae75-7f444b8ca9bf | - | idisk_uuid | 89694799-0dd8-4532-8636-c0d8aabfe215 | - | ipv_uuid | None | - | status | Creating | - | created_at | 2018-08-22T04:03:40.761221+00:00 | - | updated_at | None | - +-------------+--------------------------------------------------+ - -#. Wait for the new partition to be created (i.e. status=Ready): - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-list controller-0 --disk 89694799-0dd8-4532-8636-c0d8aabfe215 - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - | uuid |...| device_nod |...| type_name | size_mib | status | - | |...| e |...| | | | - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - | 9ba2d76a-6ae2-4bfa-ad48-57b62d102e80 |...| /dev/sdb1 |...| LVM Physical Volume | 199.0 | Ready | - | |...| |...| | | | - | |...| |...| | | | - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - -#. Add the partition to the volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-pv-add controller-0 cinder-volumes 9ba2d76a-6ae2-4bfa-ad48-57b62d102e80 - +--------------------------+--------------------------------------------------+ - | Property | Value | - +--------------------------+--------------------------------------------------+ - | uuid | 060dc47e-bc17-40f4-8f09-5326ef0e86a5 | - | pv_state | adding | - | pv_type | partition | - | disk_or_part_uuid | 9ba2d76a-6ae2-4bfa-ad48-57b62d102e80 | - | disk_or_part_device_node | /dev/sdb1 | - | disk_or_part_device_path | /dev/disk/by-path/pci-0000:00:03.0-ata-2.0-part1 | - | lvm_pv_name | /dev/sdb1 | - | lvm_vg_name | cinder-volumes | - | lvm_pv_uuid | None | - | lvm_pv_size_gib | 0.0 | - | lvm_pe_total | 0 | - | lvm_pe_alloced | 0 | - | ihost_uuid | 150284e2-fb60-4169-ae75-7f444b8ca9bf | - | created_at | 2018-08-22T04:06:54.008632+00:00 | - | updated_at | None | - +--------------------------+--------------------------------------------------+ - -#. Enable the LVM backend: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system storage-backend-add lvm -s cinder --confirmed - -#. Wait for the storage backend to leave the "configuring" state. Confirm LVM - backend storage is configured: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system storage-backend-list - +--------------------------------------+------------+---------+------------+------+----------+... - | uuid | name | backend | state | task | services |... - +--------------------------------------+------------+---------+------------+------+----------+... - | 1daf3e5b-4122-459f-9dba-d2e92896e718 | file-store | file | configured | None | glance |... - | a4607355-be7e-4c5c-bf87-c71a0e2ad380 | lvm-store | lvm | configured | None | cinder |... - +--------------------------------------+------------+---------+------------+------+----------+... - -********************** -Unlocking controller-0 -********************** - -You must unlock controller-0 so that you can use it to install the -remaining hosts. On controller-0, acquire Keystone administrative -privileges. Use the system host-unlock command: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-unlock controller-0 - -The host reboots. During the reboot, the command line is -unavailable and any ssh connections are dropped. To monitor the -progress of the reboot, use the controller-0 console. - -**************************************** -Verifying the controller-0 configuration -**************************************** - -Follow these steps: - -#. On controller-0, acquire Keystone administrative privileges: - - :: - - controller-0:~$ source /etc/nova/openrc - -#. Verify StarlingX controller services are running: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system service-list - +-----+-------------------------------+--------------+----------------+ - | id | service_name | hostname | state | - +-----+-------------------------------+--------------+----------------+ - ... - | 1 | oam-ip | controller-0 | enabled-active | - | 2 | management-ip | controller-0 | enabled-active | - ... - +-----+-------------------------------+--------------+----------------+ - -#. Verify that controller-0 is unlocked, enabled, and available: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - +----+--------------+-------------+----------------+-------------+--------------+ - ---------------------------------------- -Installing controller-1 / compute hosts ---------------------------------------- - -After initializing and configuring an active controller, you can add and -configure a backup controller as well as additional compute or storage hosts. -For each host do the following: - -********************* -Initializing the host -********************* - -Power on the Host. The following displays in the host's console: - -:: - - Waiting for this node to be configured. - - Please configure the personality for this node from the - controller node in order to proceed. - -****************************************** -Updating the host hostname and personality -****************************************** - -Follow these steps: - -#. On controller-0, acquire Keystone administrative privileges: - - :: - - controller-0:~$ source /etc/nova/openrc - -#. Wait for controller-0 to discover the new host. - List the host until a new UNKNOWN host appears in the table: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. Use the system host-add command to update the host's personality attribute: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-update 2 personality=controller hostname=controller-1 - - Or for compute-0: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-update 3 personality=compute hostname=compute-0 - - **NOTE:** You can also see the 'system help host-update' for more information. - - Unless it is known that the host's configuration can support the - installation of more than one node, it is recommended that the - installation and configuration of each node be serialized. For example, - if the virtual disks for the entire cluster are hosted on the host's - root disk and that disk happens to be a single rotational type hard disk, - then the host cannot reliably support parallel node installation. - -************* -Monitor hosts -************* - -On controller-0, you can monitor the installation progress by periodically -running the system host-show command for the host. Progress appears -in the install_state field. - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-show | grep install - | install_output | text | - | install_state | booting | - | install_state_info | None | - -Wait while the host is configured and rebooted. Depending on hardware, -a reboot can take up to 20 minutes. When the reboot completes, -the host is reported as locked, disabled, and online. - -********** -List hosts -********** - -You can use the system host-list command to list the hosts -once the nodes have been installed, configured and rebooted, on -controller-0: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | locked | disabled | online | - | 3 | compute-0 | compute | locked | disabled | online | - | 4 | compute-1 | compute | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - -------------------------- -Provisioning controller-1 -------------------------- - -Use the system host-list on controller-0 to list the hosts: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - ... - | 2 | controller-1 | controller | locked | disabled | online | - ... - +----+--------------+-------------+----------------+-------------+--------------+ - -*********************************************** -Provisioning network interfaces on controller-1 -*********************************************** - -Follow these steps: - -#. Use the system host-port-list command to list hardware port names, types, - and PCI addresses that have been discovered: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-port-list controller-1 - -#. Provision the OAM interface for controller-1: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-if-modify -n -c platform --networks oam controller-1 - -************************************ -Provisioning storage on controller-1 -************************************ - -Follow these steps: - -#. Review the available disk space and capacity and obtain the uuid of the - physical disk: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-list controller-1 - +--------------------------------------+-----------+---------+---------+-------+------------+ - | uuid | device_no | device_ | device_ | size_ | available_ | - | | de | num | type | gib | gib | - +--------------------------------------+-----------+---------+---------+-------+------------+ - | f7ce53db-7843-457e-8422-3c8f9970b4f2 | /dev/sda | 2048 | HDD | 200.0 | 0.0 | - | 70b83394-968e-4f0d-8a99-7985cd282a21 | /dev/sdb | 2064 | HDD | 200.0 | 199.997 | - +--------------------------------------+-----------+---------+---------+-------+------------+ - -#. Assign Cinder storage to the physical disk: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-lvg-add controller-1 cinder-volumes - +-----------------+--------------------------------------+ - | Property | Value | - +-----------------+--------------------------------------+ - | lvm_vg_name | cinder-volumes | - | vg_state | adding | - | uuid | 22d8b94a-200a-4fd5-b1f5-7015ddf10d0b | - | ihost_uuid | 06827025-eacb-45e6-bb88-1a649f7404ec | - | lvm_vg_access | None | - | lvm_max_lv | 0 | - | lvm_cur_lv | 0 | - | lvm_max_pv | 0 | - | lvm_cur_pv | 0 | - | lvm_vg_size_gib | 0.00 | - | lvm_vg_total_pe | 0 | - | lvm_vg_free_pe | 0 | - | created_at | 2018-08-22T05:33:44.608913+00:00 | - | updated_at | None | - | parameters | {u'lvm_type': u'thin'} | - +-----------------+--------------------------------------+ - -#. Create a disk partition to add to the volume group based on the uuid of the - physical disk: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-add controller-1 70b83394-968e-4f0d-8a99-7985cd282a21 199 -t lvm_phys_vol - +-------------+--------------------------------------------------+ - | Property | Value | - +-------------+--------------------------------------------------+ - | device_path | /dev/disk/by-path/pci-0000:00:03.0-ata-2.0-part1 | - | device_node | /dev/sdb1 | - | type_guid | ba5eba11-0000-1111-2222-000000000001 | - | type_name | None | - | start_mib | None | - | end_mib | None | - | size_mib | 203776 | - | uuid | 16a1c5cb-620c-47a3-be4b-022eafd122ee | - | ihost_uuid | 06827025-eacb-45e6-bb88-1a649f7404ec | - | idisk_uuid | 70b83394-968e-4f0d-8a99-7985cd282a21 | - | ipv_uuid | None | - | status | Creating (on unlock) | - | created_at | 2018-08-22T05:36:42.123770+00:00 | - | updated_at | None | - +-------------+--------------------------------------------------+ - -#. Wait for the new partition to be created (i.e. status=Ready): - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-list controller-1 --disk 70b83394-968e-4f0d-8a99-7985cd282a21 - +--------------------------------------+...+------------+...+-------+--------+----------------------+ - | uuid |...| device_nod | ... | size_g | status | - | |...| e | ... | ib | | - +--------------------------------------+...+------------+ ... +--------+----------------------+ - | 16a1c5cb-620c-47a3-be4b-022eafd122ee |...| /dev/sdb1 | ... | 199.0 | Creating (on unlock) | - | |...| | ... | | | - | |...| | ... | | | - +--------------------------------------+...+------------+...+--------+----------------------+ - -#. Add the partition to the volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-pv-add controller-1 cinder-volumes 16a1c5cb-620c-47a3-be4b-022eafd122ee - +--------------------------+--------------------------------------------------+ - | Property | Value | - +--------------------------+--------------------------------------------------+ - | uuid | 01d79ed2-717f-428e-b9bc-23894203b35b | - | pv_state | adding | - | pv_type | partition | - | disk_or_part_uuid | 16a1c5cb-620c-47a3-be4b-022eafd122ee | - | disk_or_part_device_node | /dev/sdb1 | - | disk_or_part_device_path | /dev/disk/by-path/pci-0000:00:03.0-ata-2.0-part1 | - | lvm_pv_name | /dev/sdb1 | - | lvm_vg_name | cinder-volumes | - | lvm_pv_uuid | None | - | lvm_pv_size_gib | 0.0 | - | lvm_pe_total | 0 | - | lvm_pe_alloced | 0 | - | ihost_uuid | 06827025-eacb-45e6-bb88-1a649f7404ec | - | created_at | 2018-08-22T05:44:34.715289+00:00 | - | updated_at | None | - +--------------------------+--------------------------------------------------+ - -********************** -Unlocking controller-1 -********************** - -Follow these steps: - -#. Unlock controller-1: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-unlock controller-1 - -#. Wait for controller-1 to reboot. Depending on hardware, it can - take up to 10 minutes for the reboot to complete. - - **NOTE:** Controller-1 remains in a degraded state until - data synchronization is complete. The length of time controller-1 - remains in this state depends on the virtualization host's configuration - (i.e. the number and configuration of physical disks used to host - the nodes' virtual disks. Also, the management network is expected - to have a link capacity of 10000. Link capacity of 1000 is not - supported due to excessive data synchronization time. Use 'fm alarm-list' to - confirm status. - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | unlocked | enabled | available | - ... - ---------------------------- -Provisioning a compute host ---------------------------- - -You must configure the network interfaces and the storage disks on a -host before you can unlock it. For each compute host, do the following: - -On controller-0, acquire Keystone administrative privileges: - -:: - - controller-0:~$ source /etc/nova/openrc - -************************************************* -Provisioning network interfaces on a compute host -************************************************* - -Follow these steps: - -#. In order to identify hardware port names, types, and discovered - pci-addresses on controller-0, list the host ports: - - - **Only in virtual environment**: Ensure that the interface used is - one of those attached to the host bridge with model type "virtio" (i.e. - eth1000 and eth1001). The model type "e1000" emulated devices will - not work for provider networks: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-port-list compute-0 - -#. Use the following command to provision the data interface for compute: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-if-modify -p providernet-a -c data compute-0 eth1000 - -*************************** -VSwitch virtual environment -*************************** - -**Only in virtual environment**. If the compute node has more than four CPUs, -the system auto-configures the vswitch to use two cores. However, some virtual -environments do not properly support multi-queue, which is required in a -multi-CPU environment. Therefore, run the following command to reduce the -vswitch cores to one: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-cpu-modify compute-0 -f vswitch -p0 1 - +--------------------------------------+-------+-----------+-------+--------+... - | uuid | log_c | processor | phy_c | thread |... - | | ore | | ore | |... - +--------------------------------------+-------+-----------+-------+--------+... - | a3b5620c-28b1-4fe0-9e97-82950d8582c2 | 0 | 0 | 0 | 0 |... - | f2e91c2b-bfc5-4f2a-9434-bceb7e5722c3 | 1 | 0 | 1 | 0 |... - | 18a98743-fdc4-4c0c-990f-3c1cb2df8cb3 | 2 | 0 | 2 | 0 |... - | 690d25d2-4f99-4ba1-a9ba-0484eec21cc7 | 3 | 0 | 3 | 0 |... - +--------------------------------------+-------+-----------+-------+--------+... - -************************************** -Provisioning storage on a compute host -************************************** - -Follow these steps: - -#. Review the available disk space and capacity and then obtain the uuid(s) of - the physical disk(s) to be used for nova local: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-list compute-0 - +--------------------------------------+-----------+---------+---------+-------+------------+... - | uuid | device_no | device_ | device_ | size_ | available_ |... - | | de | num | type | gib | gib |... - +--------------------------------------+-----------+---------+---------+-------+------------+... - | 8a9d2c09-d3a7-4781-bd06-f7abf603713a | /dev/sda | 2048 | HDD | 200.0 | 172.164 |... - | 5ad61bd1-795a-4a76-96ce-39433ef55ca5 | /dev/sdb | 2064 | HDD | 200.0 | 199.997 |... - +--------------------------------------+-----------+---------+---------+-------+------------+... - -#. Use the following command to create the 'nova-local' local volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-lvg-add compute-0 nova-local - +-----------------+-------------------------------------------------------------------+ - | Property | Value | - +-----------------+-------------------------------------------------------------------+ - | lvm_vg_name | nova-local | - | vg_state | adding | - | uuid | 18898640-c8b7-4bbd-a323-4bf3e35fee4d | - | ihost_uuid | da1cbe93-cec5-4f64-b211-b277e4860ab3 | - | lvm_vg_access | None | - | lvm_max_lv | 0 | - | lvm_cur_lv | 0 | - | lvm_max_pv | 0 | - | lvm_cur_pv | 0 | - | lvm_vg_size_gib | 0.00 | - | lvm_vg_total_pe | 0 | - | lvm_vg_free_pe | 0 | - | created_at | 2018-08-22T08:00:51.945160+00:00 | - | updated_at | None | - | parameters | {u'concurrent_disk_operations': 2, u'instance_backing': u'image'} | - +-----------------+-------------------------------------------------------------------+ - -#. Use the following command to create a disk partition to add to the volume - group based on the uuid of the physical disk: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-pv-add compute-0 nova-local 5ad61bd1-795a-4a76-96ce-39433ef55ca5 - +--------------------------+--------------------------------------------+ - | Property | Value | - +--------------------------+--------------------------------------------+ - | uuid | 4c81745b-286a-4850-ba10-305e19cee78c | - | pv_state | adding | - | pv_type | disk | - | disk_or_part_uuid | 5ad61bd1-795a-4a76-96ce-39433ef55ca5 | - | disk_or_part_device_node | /dev/sdb | - | disk_or_part_device_path | /dev/disk/by-path/pci-0000:00:03.0-ata-2.0 | - | lvm_pv_name | /dev/sdb | - | lvm_vg_name | nova-local | - | lvm_pv_uuid | None | - | lvm_pv_size_gib | 0.0 | - | lvm_pe_total | 0 | - | lvm_pe_alloced | 0 | - | ihost_uuid | da1cbe93-cec5-4f64-b211-b277e4860ab3 | - | created_at | 2018-08-22T08:07:14.205690+00:00 | - | updated_at | None | - +--------------------------+--------------------------------------------+ - -#. Specify the local storage space as local copy-on-write image volumes in - nova-local: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-lvg-modify -b image -s 10240 compute-0 nova-local - +-----------------+-------------------------------------------------------------------+ - | Property | Value | - +-----------------+-------------------------------------------------------------------+ - | lvm_vg_name | nova-local | - | vg_state | adding | - | uuid | 18898640-c8b7-4bbd-a323-4bf3e35fee4d | - | ihost_uuid | da1cbe93-cec5-4f64-b211-b277e4860ab3 | - | lvm_vg_access | None | - | lvm_max_lv | 0 | - | lvm_cur_lv | 0 | - | lvm_max_pv | 0 | - | lvm_cur_pv | 0 | - | lvm_vg_size_gib | 0.00 | - | lvm_vg_total_pe | 0 | - | lvm_vg_free_pe | 0 | - | created_at | 2018-08-22T08:00:51.945160+00:00 | - | updated_at | None | - | parameters | {u'concurrent_disk_operations': 2, u'instance_backing': u'image'} | - +-----------------+-------------------------------------------------------------------+ - -************************ -Unlocking a compute host -************************ - -On controller-0, use the system host-unlock command to unlock -the compute node: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-unlock compute-0 - -Wait while the compute node reboots. It might take up to 10 minutes -for the reboot to complete depending on the hardware. Once the host -reboots, its availability state becomes "in-test", which is -followed by "unlocked/enabled". - -------------------- -System health check -------------------- - -*********************** -Listing StarlingX nodes -*********************** - -On controller-0, use the system host-list command to view the nodes. -Eventually, all nodes are reported as unlocked, enabled, and available: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | unlocked | enabled | available | - | 3 | compute-0 | compute | unlocked | enabled | available | - | 4 | compute-1 | compute | unlocked | enabled | available | - +----+--------------+-------------+----------------+-------------+--------------+ - -***************** -System alarm-list -***************** - -When all nodes are unlocked, enabled and available: check 'fm alarm-list' for -issues. - -Your StarlingX deployment is now up and running with 2x HA controllers with -Cinder storage, 2x computes, and all OpenStack services up and running. You can -now proceed with standard OpenStack APIs, CLIs and/or Horizon to load Glance -images, configure Nova Flavors, configure Neutron networks, and launch Nova -virtual machines. - ----------------------- -Deployment terminology ----------------------- - -.. include:: deployment_terminology.rst - :start-after: incl-standard-controller-deployment-terminology: - :end-before: incl-standard-controller-deployment-terminology-end: - -.. include:: deployment_terminology.rst - :start-after: incl-common-deployment-terminology: - :end-before: incl-common-deployment-terminology-end: diff --git a/doc/source/deploy_install_guides/r1_release/dedicated_storage.rst b/doc/source/deploy_install_guides/r1_release/dedicated_storage.rst deleted file mode 100644 index 565266a6a..000000000 --- a/doc/source/deploy_install_guides/r1_release/dedicated_storage.rst +++ /dev/null @@ -1,918 +0,0 @@ -====================== -Dedicated storage R1.0 -====================== - -.. contents:: - :local: - :depth: 1 - -**NOTE:** The instructions to setup a StarlingX Cloud with Dedicated -Storage with containerized openstack services in this guide -are under development. -For approved instructions, see the -`StarlingX Cloud with Dedicated Storage wiki page `__. - ----------------------- -Deployment description ----------------------- - -Cloud with Dedicated Storage is the standard StarlingX deployment option with -independent controller, compute, and storage nodes. - -This deployment option provides the maximum capacity for a single region -deployment, with a supported growth path to a multi-region deployment option by -adding a secondary region. - -.. figure:: figures/starlingx-deployment-options-dedicated-storage.png - :scale: 50% - :alt: Dedicated Storage deployment configuration - - *Dedicated Storage deployment configuration* - -Cloud with Dedicated Storage includes: - -- 2x node HA controller cluster with HA services running across the controller - nodes in either active/active or active/standby mode. -- Pool of up to 100 compute nodes for hosting virtual machines and virtual - networks. -- 2-9x node HA Ceph storage cluster for hosting virtual volumes, images, and - object storage that supports a replication factor of 2 or 3. - - Storage nodes are deployed in replication groups of 2 or 3. Replication - of objects is done strictly within the replication group. - - Supports up to 4 groups of 2x storage nodes, or up to 3 groups of 3x storage - nodes. - ------------------------------------ -Preparing dedicated storage servers ------------------------------------ - -********** -Bare metal -********** - -Required Servers: - -- Controllers: 2 -- Storage - - - Replication factor of 2: 2 - 8 - - Replication factor of 3: 3 - 9 - -- Computes: 2 - 100 - -^^^^^^^^^^^^^^^^^^^^^ -Hardware requirements -^^^^^^^^^^^^^^^^^^^^^ - -The recommended minimum requirements for the physical servers where -Dedicated Storage will be deployed, include: - -- Minimum processor: - - - Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) 8 cores/socket - -- Memory: - - - 64 GB controller, storage - - 32 GB compute - -- BIOS: - - - Hyper-Threading technology: Enabled - - Virtualization technology: Enabled - - VT for directed I/O: Enabled - - CPU power and performance policy: Performance - - CPU C state control: Disabled - - Plug & play BMC detection: Disabled - -- Primary disk: - - - 500 GB SSD or NVMe controller - - 120 GB (min. 10K RPM) compute and storage - -- Additional disks: - - - 1 or more 500 GB disks (min. 10K RPM) storage, compute - -- Network ports\* - - - Management: 10GE controller, storage, compute - - OAM: 10GE controller - - Data: n x 10GE compute - -******************* -Virtual environment -******************* - -Run the libvirt qemu setup scripts. Setting up virtualized OAM and -management networks: - -:: - - $ bash setup_network.sh - -Building XML for definition of virtual servers: - -:: - - $ bash setup_configuration.sh -c dedicatedstorage -i - -The default XML server definitions that are created by the previous script -are: - -- dedicatedstorage-controller-0 -- dedicatedstorage-controller-1 -- dedicatedstorage-compute-0 -- dedicatedstorage-compute-1 -- dedicatedstorage-storage-0 -- dedicatedstorage-storage-1 - -^^^^^^^^^^^^^^^^^^^^^^^^^ -Power up a virtual server -^^^^^^^^^^^^^^^^^^^^^^^^^ - -To power up a virtual server, run the following command: - -:: - - $ sudo virsh start - -e.g. - -:: - - $ sudo virsh start dedicatedstorage-controller-0 - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Access virtual server consoles -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The XML for virtual servers in stx-tools repo, deployment/libvirt, -provides both graphical and text consoles. - -Access the graphical console in virt-manager by right-click on the -domain (the server) and selecting "Open". - -Access the textual console with the command "virsh console $DOMAIN", -where DOMAIN is the name of the server shown in virsh. - -When booting the controller-0 for the first time, both the serial and -graphical consoles will present the initial configuration menu for the -cluster. One can select serial or graphical console for controller-0. -For the other nodes however only serial is used, regardless of which -option is selected. - -Open the graphic console on all servers before powering them on to -observe the boot device selection and PXI boot progress. Run "virsh -console $DOMAIN" command promptly after power on to see the initial boot -sequence which follows the boot device selection. One has a few seconds -to do this. - --------------------------------- -Installing the controller-0 host --------------------------------- - -Installing controller-0 involves initializing a host with software and -then applying a bootstrap configuration from the command line. The -configured bootstrapped host becomes controller-0. - -Procedure: - -#. Power on the server that will be controller-0 with the StarlingX ISO - on a USB in a bootable USB slot. -#. Configure the controller using the config_controller script. - -************************* -Initializing controller-0 -************************* - -This section describes how to initialize StarlingX in host controller-0. -Except where noted, all the commands must be executed from a console of -the host. - -Power on the host to be configured as controller-0, with the StarlingX -ISO on a USB in a bootable USB slot. Wait for the console to show the -StarlingX ISO booting options: - -- **Standard Controller Configuration** - - - When the installer is loaded and the installer welcome screen - appears in the controller-0 host, select the type of installation - "Standard Controller Configuration". - -- **Graphical Console** - - - Select the "Graphical Console" as the console to use during - installation. - -- **Standard Security Boot Profile** - - - Select "Standard Security Boot Profile" as the security profile. - -Monitor the initialization. When it is complete, a reboot is initiated -on the controller-0 host, briefly displays a GNU GRUB screen, and then -boots automatically into the StarlingX image. - -Log into controller-0 as user wrsroot, with password wrsroot. The -first time you log in as wrsroot, you are required to change your -password. Enter the current password (wrsroot): - -:: - - Changing password for wrsroot. - (current) UNIX Password: - -Enter a new password for the wrsroot account: - -:: - - New password: - -Enter the new password again to confirm it: - -:: - - Retype new password: - -controller-0 is initialized with StarlingX, and is ready for configuration. - -************************ -Configuring controller-0 -************************ - -This section describes how to perform the controller-0 configuration -interactively just to bootstrap system with minimum critical data. -Except where noted, all the commands must be executed from the console -of the active controller (here assumed to be controller-0). - -When run interactively, the config_controller script presents a series -of prompts for initial configuration of StarlingX: - -- For the virtual environment, you can accept all the default values - immediately after ‘system date and time’. -- For a physical deployment, answer the bootstrap configuration - questions with answers applicable to your particular physical setup. - -The script is used to configure the first controller in the StarlingX -cluster as controller-0. The prompts are grouped by configuration -area. To start the script interactively, use the following command -with no parameters: - -:: - - controller-0:~$ sudo config_controller - System Configuration - ================ - Enter ! at any prompt to abort... - ... - -Accept all the default values immediately after ‘system date and time’: - -:: - - ... - Applying configuration (this will take several minutes): - - 01/08: Creating bootstrap configuration ... DONE - 02/08: Applying bootstrap manifest ... DONE - 03/08: Persisting local configuration ... DONE - 04/08: Populating initial system inventory ... DONE - 05:08: Creating system configuration ... DONE - 06:08: Applying controller manifest ... DONE - 07:08: Finalize controller configuration ... DONE - 08:08: Waiting for service activation ... DONE - - Configuration was applied - - Please complete any out of service commissioning steps with system commands and unlock controller to proceed. - -After config_controller bootstrap configuration, REST API, CLI and -Horizon interfaces are enabled on the controller-0 OAM IP address. The -remaining installation instructions will use the CLI. - ------------------------------------- -Provisioning controller-0 and system ------------------------------------- - -On controller-0, acquire Keystone administrative privileges: - -:: - - controller-0:~$ source /etc/nova/openrc - -********************************************* -Configuring provider networks at installation -********************************************* - -You must set up provider networks at installation so that you can attach -data interfaces and unlock the compute nodes. - -Set up one provider network of the vlan type, named providernet-a: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ neutron providernet-create providernet-a --type=vlan - [wrsroot@controller-0 ~(keystone_admin)]$ neutron providernet-range-create --name providernet-a-range1 --range 100-400 providernet-a - -********************************************* -Adding a Ceph storage backend at installation -********************************************* - -Add Ceph Storage backend: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system storage-backend-add ceph -s cinder,glance,swift,nova - - WARNING : THIS OPERATION IS NOT REVERSIBLE AND CANNOT BE CANCELLED. - - By confirming this operation, Ceph backend will be created. - A minimum of 2 storage nodes are required to complete the configuration. - Please set the 'confirmed' field to execute this operation for the ceph backend. - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system storage-backend-add ceph -s cinder,glance,swift,nova --confirmed - - System configuration has changed. - Please follow the administrator guide to complete configuring the system. - - +--------------------------------------+------------+---------+-------------+--------------------+----------+... - | uuid | name | backend | state | task | services |... - +--------------------------------------+------------+---------+-------------+--------------------+----------+... - | 48ddb10a-206c-42da-bb3f-f7160a356724 | ceph-store | ceph | configuring | applying-manifests | cinder, |... - | | | | | | glance, |... - | | | | | | swift |... - | | | | | | nova |... - | | | | | | |... - | 55f49f86-3e01-4d03-a014-42e1b55ba487 | file-store | file | configured | None | glance |... - +--------------------------------------+------------+---------+-------------+--------------------+----------+... - -Confirm Ceph storage is configured: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system storage-backend-list - +--------------------------------------+------------+---------+------------+-------------------+-----------+... - | uuid | name | backend | state | task | services |... - +--------------------------------------+------------+---------+------------+-------------------+-----------+... - | 48ddb10a-206c-42da-bb3f-f7160a356724 | ceph-store | ceph | configured | provision-storage | cinder, |... - | | | | | | glance, |... - | | | | | | swift |... - | | | | | | nova |... - | | | | | | |... - | 55f49f86-3e01-4d03-a014-42e1b55ba487 | file-store | file | configured | None | glance |... - +--------------------------------------+------------+---------+------------+-------------------+-----------+... - -********************** -Unlocking controller-0 -********************** - -You must unlock controller-0 so that you can use it to install the remaining -hosts. Use the system host-unlock command: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-unlock controller-0 - -The host is rebooted. During the reboot, the command line is unavailable, and -any ssh connections are dropped. To monitor the progress of the reboot, use the -controller-0 console. - -**************************************** -Verifying the controller-0 configuration -**************************************** - -On controller-0, acquire Keystone administrative privileges: - -:: - - controller-0:~$ source /etc/nova/openrc - -Verify that the StarlingX controller services are running: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system service-list - +-----+-------------------------------+--------------+----------------+ - | id | service_name | hostname | state | - +-----+-------------------------------+--------------+----------------+ - ... - | 1 | oam-ip | controller-0 | enabled-active | - | 2 | management-ip | controller-0 | enabled-active | - ... - +-----+-------------------------------+--------------+----------------+ - -Verify that controller-0 is unlocked, enabled, and available: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - +----+--------------+-------------+----------------+-------------+--------------+ - -******************************* -Provisioning filesystem storage -******************************* - -List the controller file systems with status and current sizes: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system controllerfs-list - +--------------------------------------+-----------------+------+--------------------+------------+-------+ - | UUID | FS Name | Size | Logical Volume | Replicated | State | - | | | in | | | | - | | | GiB | | | | - +--------------------------------------+-----------------+------+--------------------+------------+-------+ - | 4e31c4ea-6970-4fc6-80ba-431fdcdae15f | backup | 5 | backup-lv | False | None | - | 6c689cd7-2bef-4755-a2fb-ddd9504692f3 | database | 5 | pgsql-lv | True | None | - | 44c7d520-9dbe-41be-ac6a-5d02e3833fd5 | extension | 1 | extension-lv | True | None | - | 809a5ed3-22c0-4385-9d1e-dd250f634a37 | glance | 8 | cgcs-lv | True | None | - | 9c94ef09-c474-425c-a8ba-264e82d9467e | gnocchi | 5 | gnocchi-lv | False | None | - | 895222b3-3ce5-486a-be79-9fe21b94c075 | img-conversions | 8 | img-conversions-lv | False | None | - | 5811713f-def2-420b-9edf-6680446cd379 | scratch | 8 | scratch-lv | False | None | - +--------------------------------------+-----------------+------+--------------------+------------+-------+ - -Modify filesystem sizes - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system controllerfs-modify backup=42 database=12 img-conversions=12 - -------------------------------------------------------- -Installing controller-1 / storage hosts / compute hosts -------------------------------------------------------- - -After initializing and configuring an active controller, you can add and -configure a backup controller and additional compute or storage hosts. -For each host do the following: - -***************** -Initializing host -***************** - -Power on Host. In host console you will see: - -:: - - Waiting for this node to be configured. - - Please configure the personality for this node from the - controller node in order to proceed. - -********************************** -Updating host name and personality -********************************** - -On controller-0, acquire Keystone administrative privileges: - -:: - - controller-0:~$ source /etc/nova/openrc - -Wait for controller-0 to discover new host, list the host until new -UNKNOWN host shows up in table: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -Use the system host-add to update host personality attribute: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-add -n -p -m - -**REMARK:** use the Mac address for the specific network interface you -are going to be connected. e.g. OAM network interface for controller-1 -node, management network interface for compute and storage nodes. - -Check the **NIC** MAC address from "Virtual Manager GUI" under *"Show -virtual hardware details -*\ **i**\ *" Main Banner --> NIC: --> specific -"Bridge name:" under MAC address text field.* - -*************** -Monitoring host -*************** - -On controller-0, you can monitor the installation progress by running -the system host-show command for the host periodically. Progress is -shown in the install_state field. - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-show | grep install - | install_output | text | - | install_state | booting | - | install_state_info | None | - - -Wait while the host is configured and rebooted. Up to 20 minutes may be -required for a reboot, depending on hardware. When the reboot is -complete, the host is reported as locked, disabled, and online. - -************* -Listing hosts -************* - -Once all nodes have been installed, configured and rebooted, on -controller-0 list the hosts: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | locked | disabled | online | - | 3 | compute-0 | compute | locked | disabled | online | - | 4 | compute-1 | compute | locked | disabled | online | - | 5 | storage-0 | storage | locked | disabled | online | - | 6 | storage-1 | storage | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - -------------------------- -Provisioning controller-1 -------------------------- - -On controller-0, list hosts: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - ... - | 2 | controller-1 | controller | locked | disabled | online | - ... - +----+--------------+-------------+----------------+-------------+--------------+ - -*********************************************** -Provisioning network interfaces on controller-1 -*********************************************** - -In order to list out hardware port names, types, PCI addresses that have -been discovered: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-port-list controller-1 - -Provision the OAM interface for controller-1: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-if-modify -n -c platform --networks oam controller-1 - -********************** -Unlocking controller-1 -********************** - -Unlock controller-1: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-unlock controller-1 - -Wait while the controller-1 is rebooted. Up to 10 minutes may be -required for a reboot, depending on hardware. - -**REMARK:** controller-1 will remain in degraded state until -data-syncing is complete. The duration is dependant on the -virtualization host's configuration - i.e., the number and configuration -of physical disks used to host the nodes' virtual disks. Also, the -management network is expected to have link capacity of 10000 (1000 is -not supported due to excessive data-sync time). Use 'fm alarm-list' to -confirm status. - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | unlocked | enabled | available | - ... - -------------------------- -Provisioning storage host -------------------------- - -************************************** -Provisioning storage on a storage host -************************************** - -Available physical disks in storage-N: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-list storage-0 - +--------------------------------------+-----------+---------+---------+-------+------------+--------------+... - | uuid | device_no | device_ | device_ | size_ | available_ | rpm |... - | | de | num | type | gib | gib | |... - +--------------------------------------+-----------+---------+---------+-------+------------+--------------+... - | a2bbfe1f-cf91-4d39-a2e8-a9785448aa56 | /dev/sda | 2048 | HDD | 292. | 0.0 | Undetermined |... - | | | | | 968 | | |... - | | | | | | | |... - | c7cc08e6-ff18-4229-a79d-a04187de7b8d | /dev/sdb | 2064 | HDD | 100.0 | 99.997 | Undetermined |... - | | | | | | | |... - | | | | | | | |... - | 1ece5d1b-5dcf-4e3c-9d10-ea83a19dd661 | /dev/sdc | 2080 | HDD | 4.0 | 3.997 |... - | | | | | | | |... - | | | | | | | |... - +--------------------------------------+-----------+---------+---------+-------+------------+--------------+... - -Available storage tiers in storage-N: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system storage-tier-list ceph_cluster - +--------------------------------------+---------+--------+--------------------------------------+ - | uuid | name | status | backend_using | - +--------------------------------------+---------+--------+--------------------------------------+ - | 4398d910-75e4-4e99-a57f-fc147fb87bdb | storage | in-use | 5131a848-25ea-4cd8-bbce-0d65c84183df | - +--------------------------------------+---------+--------+--------------------------------------+ - -Create a storage function (i.e. OSD) in storage-N. At least two unlocked and -enabled hosts with monitors are required. Candidates are: controller-0, -controller-1, and storage-0. - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-stor-add storage-0 c7cc08e6-ff18-4229-a79d-a04187de7b8d - +------------------+--------------------------------------------------+ - | Property | Value | - +------------------+--------------------------------------------------+ - | osdid | 0 | - | function | osd | - | journal_location | 34989bad-67fc-49ea-9e9c-38ca4be95fad | - | journal_size_gib | 1024 | - | journal_path | /dev/disk/by-path/pci-0000:00:0d.0-ata-2.0-part2 | - | journal_node | /dev/sdb2 | - | uuid | 34989bad-67fc-49ea-9e9c-38ca4be95fad | - | ihost_uuid | 4a5ed4fc-1d2b-4607-acf9-e50a3759c994 | - | idisk_uuid | c7cc08e6-ff18-4229-a79d-a04187de7b8d | - | tier_uuid | 4398d910-75e4-4e99-a57f-fc147fb87bdb | - | tier_name | storage | - | created_at | 2018-08-16T00:39:44.409448+00:00 | - | updated_at | 2018-08-16T00:40:07.626762+00:00 | - +------------------+--------------------------------------------------+ - -Create remaining available storage function (an OSD) in storage-N -based in the number of available physical disks. - -List the OSDs: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-stor-list storage-0 - +--------------------------------------+----------+-------+--------------+--------------------------------------+ - | uuid | function | osdid | capabilities | idisk_uuid | - +--------------------------------------+----------+-------+--------------+--------------------------------------+ - | 34989bad-67fc-49ea-9e9c-38ca4be95fad | osd | 0 | {} | c7cc08e6-ff18-4229-a79d-a04187de7b8d | - +--------------------------------------+----------+-------+--------------+--------------------------------------+ - -Unlock storage-N: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-unlock storage-0 - -**REMARK:** Before you continue, repeat Provisioning Storage steps on -remaining storage nodes. - ---------------------------- -Provisioning a compute host ---------------------------- - -You must configure the network interfaces and the storage disks on a -host before you can unlock it. For each compute host do the following: - -On controller-0, acquire Keystone administrative privileges: - -:: - - controller-0:~$ source /etc/nova/openrc - -************************************************* -Provisioning network interfaces on a compute host -************************************************* - -On controller-0, in order to list out hardware port names, types, -pci-addresses that have been discovered: - -- **Only in virtual environment**: Ensure that the interface used is - one of those attached to host bridge with model type "virtio" (i.e., - eth1000 and eth1001). The model type "e1000" emulated devices will - not work for provider networks. - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-port-list compute-0 - -Provision the data interface for compute: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-if-modify -p providernet-a -c data compute-0 eth1000 - -*************************** -VSwitch virtual environment -*************************** - -**Only in virtual environment**. If the compute has more than 4 CPUs, -the system will auto-configure the vswitch to use 2 cores. However some -virtual environments do not properly support multi-queue required in a -multi-CPU environment. Therefore run the following command to reduce the -vswitch cores to 1: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-cpu-modify compute-0 -f vswitch -p0 1 - +--------------------------------------+-------+-----------+-------+--------+... - | uuid | log_c | processor | phy_c | thread |... - | | ore | | ore | |... - +--------------------------------------+-------+-----------+-------+--------+... - | a3b5620c-28b1-4fe0-9e97-82950d8582c2 | 0 | 0 | 0 | 0 |... - | f2e91c2b-bfc5-4f2a-9434-bceb7e5722c3 | 1 | 0 | 1 | 0 |... - | 18a98743-fdc4-4c0c-990f-3c1cb2df8cb3 | 2 | 0 | 2 | 0 |... - | 690d25d2-4f99-4ba1-a9ba-0484eec21cc7 | 3 | 0 | 3 | 0 |... - +--------------------------------------+-------+-----------+-------+--------+... - -************************************** -Provisioning storage on a compute host -************************************** - -Review the available disk space and capacity and obtain the uuid(s) of -the physical disk(s) to be used for nova local: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-list compute-0 - +--------------------------------------+-----------+---------+---------+-------+------------+... - | uuid | device_no | device_ | device_ | size_ | available_ |... - | | de | num | type | gib | gib |... - +--------------------------------------+-----------+---------+---------+-------+------------+ - | 14e52a55-f6a7-40ad-a0b1-11c2c3b6e7e9 | /dev/sda | 2048 | HDD | 292. | 265.132 |... - | a639914b-23a9-4071-9f25-a5f1960846cc | /dev/sdb | 2064 | HDD | 100.0 | 99.997 |... - +--------------------------------------+-----------+---------+---------+-------+------------+... - -Create the 'nova-local' local volume group: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-lvg-add compute-0 nova-local - +-----------------+-------------------------------------------------------------------+ - | Property | Value | - +-----------------+-------------------------------------------------------------------+ - | lvm_vg_name | nova-local | - | vg_state | adding | - | uuid | 37f4c178-f0fe-422d-b66e-24ae057da674 | - | ihost_uuid | f56921a6-8784-45ac-bd72-c0372cd95964 | - | lvm_vg_access | None | - | lvm_max_lv | 0 | - | lvm_cur_lv | 0 | - | lvm_max_pv | 0 | - | lvm_cur_pv | 0 | - | lvm_vg_size_gib | 0.00 | - | lvm_vg_total_pe | 0 | - | lvm_vg_free_pe | 0 | - | created_at | 2018-08-16T00:57:46.340454+00:00 | - | updated_at | None | - | parameters | {u'concurrent_disk_operations': 2, u'instance_backing': u'image'} | - +-----------------+-------------------------------------------------------------------+ - -Create a disk partition to add to the volume group based on uuid of the -physical disk: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-pv-add compute-0 nova-local a639914b-23a9-4071-9f25-a5f1960846cc - +--------------------------+--------------------------------------------+ - | Property | Value | - +--------------------------+--------------------------------------------+ - | uuid | 56fdb63a-1078-4394-b1ce-9a0b3bff46dc | - | pv_state | adding | - | pv_type | disk | - | disk_or_part_uuid | a639914b-23a9-4071-9f25-a5f1960846cc | - | disk_or_part_device_node | /dev/sdb | - | disk_or_part_device_path | /dev/disk/by-path/pci-0000:00:0d.0-ata-2.0 | - | lvm_pv_name | /dev/sdb | - | lvm_vg_name | nova-local | - | lvm_pv_uuid | None | - | lvm_pv_size_gib | 0.0 | - | lvm_pe_total | 0 | - | lvm_pe_alloced | 0 | - | ihost_uuid | f56921a6-8784-45ac-bd72-c0372cd95964 | - | created_at | 2018-08-16T01:05:59.013257+00:00 | - | updated_at | None | - +--------------------------+--------------------------------------------+ - -Remote RAW Ceph storage backed will be used to back nova local ephemeral -volumes: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-lvg-modify -b remote compute-0 nova-local - -************************ -Unlocking a compute host -************************ - -On controller-0, use the system host-unlock command to unlock the -compute-N: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-unlock compute-0 - -Wait while the compute-N is rebooted. Up to 10 minutes may be required -for a reboot, depending on hardware. The host is rebooted, and its -availability state is reported as in-test, followed by unlocked/enabled. - -------------------- -System health check -------------------- - -*********************** -Listing StarlingX nodes -*********************** - -On controller-0, after a few minutes, all nodes shall be reported as -unlocked, enabled, and available: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | unlocked | enabled | available | - | 3 | compute-0 | compute | unlocked | enabled | available | - | 4 | compute-1 | compute | unlocked | enabled | available | - | 5 | storage-0 | storage | unlocked | enabled | available | - | 6 | storage-1 | storage | unlocked | enabled | available | - +----+--------------+-------------+----------------+-------------+--------------+ - -****************************** -Checking StarlingX Ceph health -****************************** - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ ceph -s - cluster e14ebfd6-5030-4592-91c3-7e6146b3c910 - health HEALTH_OK - monmap e1: 3 mons at {controller-0=192.168.204.3:6789/0,controller-1=192.168.204.4:6789/0,storage-0=192.168.204.204:6789/0} - election epoch 22, quorum 0,1,2 controller-0,controller-1,storage-0 - osdmap e84: 2 osds: 2 up, 2 in - flags sortbitwise,require_jewel_osds - pgmap v168: 1600 pgs, 5 pools, 0 bytes data, 0 objects - 87444 kB used, 197 GB / 197 GB avail - 1600 active+clean - controller-0:~$ - -***************** -System alarm list -***************** - -When all nodes are unlocked, enabled and available: check 'fm alarm-list' for -issues. - -Your StarlingX deployment is now up and running with 2x HA controllers with -Cinder storage, 1x compute, 3x storages and all OpenStack services up and -running. You can now proceed with standard OpenStack APIs, CLIs and/or Horizon -to load Glance images, configure Nova Flavors, configure Neutron networks and -launch Nova virtual machines. - ----------------------- -Deployment terminology ----------------------- - -.. include:: deployment_terminology.rst - :start-after: incl-standard-controller-deployment-terminology: - :end-before: incl-standard-controller-deployment-terminology-end: - -.. include:: deployment_terminology.rst - :start-after: incl-dedicated-storage-deployment-terminology: - :end-before: incl-dedicated-storage-deployment-terminology-end: - -.. include:: deployment_terminology.rst - :start-after: incl-common-deployment-terminology: - :end-before: incl-common-deployment-terminology-end: diff --git a/doc/source/deploy_install_guides/r1_release/deployment_terminology.rst b/doc/source/deploy_install_guides/r1_release/deployment_terminology.rst deleted file mode 100644 index 6d695ee73..000000000 --- a/doc/source/deploy_install_guides/r1_release/deployment_terminology.rst +++ /dev/null @@ -1,119 +0,0 @@ -.. _incl-simplex-deployment-terminology: - -**All-in-one controller node** - A single physical node that provides a controller function, compute - function, and storage function. - -.. _incl-simplex-deployment-terminology-end: - - -.. _incl-standard-controller-deployment-terminology: - -**Controller node / function** - A node that runs cloud control function for managing cloud resources. - - - Runs cloud control functions for managing cloud resources. - - Runs all OpenStack control functions (e.g. managing images, virtual - volumes, virtual network, and virtual machines). - - Can be part of a two-node HA control node cluster for running control - functions either active/active or active/standby. - -**Compute ( & network ) node / function** - A node that hosts applications in virtual machines using compute resources - such as CPU, memory, and disk. - - - Runs virtual switch for realizing virtual networks. - - Provides L3 routing and NET services. - -.. _incl-standard-controller-deployment-terminology-end: - - -.. _incl-dedicated-storage-deployment-terminology: - -**Storage node / function** - A node that contains a set of disks (e.g. SATA, SAS, SSD, and/or NVMe). - - - Runs CEPH distributed storage software. - - Part of an HA multi-node CEPH storage cluster supporting a replication - factor of two or three, journal caching, and class tiering. - - Provides HA persistent storage for images, virtual volumes - (i.e. block storage), and object storage. - -.. _incl-dedicated-storage-deployment-terminology-end: - -.. _incl-common-deployment-terminology: - -**OAM network** - The network on which all external StarlingX platform APIs are exposed, - (i.e. REST APIs, Horizon web server, SSH, and SNMP), typically 1GE. - - Only controller type nodes are required to be connected to the OAM - network. - -**Management network** - A private network (i.e. not connected externally), tipically 10GE, - used for the following: - - - Internal OpenStack / StarlingX monitoring and control. - - VM I/O access to a storage cluster. - - All nodes are required to be connected to the management network. - -**Data network(s)** - Networks on which the OpenStack / Neutron provider networks are realized - and become the VM tenant networks. - - Only compute type and all-in-one type nodes are required to be connected - to the data network(s). These node types require one or more interface(s) - on the data network(s). - -**IPMI network** - An optional network on which IPMI interfaces of all nodes are connected. - The network must be reachable using L3/IP from the controller's OAM - interfaces. - - You can optionally connect all node types to the IPMI network. - -**PXEBoot network** - An optional network for controllers to boot/install other nodes over the - network. - - By default, controllers use the management network for boot/install of other - nodes in the openstack cloud. If this optional network is used, all node - types are required to be connected to the PXEBoot network. - - A PXEBoot network is required for a variety of special case situations: - - - Cases where the management network must be IPv6: - - - IPv6 does not support PXEBoot. Therefore, IPv4 PXEBoot network must be - configured. - - - Cases where the management network must be VLAN tagged: - - - Most server's BIOS do not support PXEBooting over tagged networks. - Therefore, you must configure an untagged PXEBoot network. - - - Cases where a management network must be shared across regions but - individual regions' controllers want to only network boot/install nodes - of their own region: - - - You must configure separate, per-region PXEBoot networks. - -**Infra network** - A deprecated optional network that was historically used for access to the - storage cluster. - - If this optional network is used, all node types are required to be - connected to the INFRA network, - -**Node interfaces** - All nodes' network interfaces can, in general, optionally be either: - - - Untagged single port. - - Untagged two-port LAG and optionally split between redudant L2 switches - running vPC (Virtual Port-Channel), also known as multichassis - EtherChannel (MEC). - - VLAN on either single-port ETH interface or two-port LAG interface. - -.. _incl-common-deployment-terminology-end: diff --git a/doc/source/deploy_install_guides/r1_release/duplex.rst b/doc/source/deploy_install_guides/r1_release/duplex.rst deleted file mode 100644 index c5b06c1af..000000000 --- a/doc/source/deploy_install_guides/r1_release/duplex.rst +++ /dev/null @@ -1,1563 +0,0 @@ -====================== -All-in-one Duplex R1.0 -====================== - -.. contents:: - :local: - :depth: 1 - -**NOTE:** The instructions to setup a StarlingX All-in-One Duplex -(AIO-DX) with containerized openstack services in this guide -are under development. -For approved instructions, see the -`All in One Duplex Configuration wiki page `__. - ----------------------- -Deployment description ----------------------- - -***************** -All-In-One Duplex -***************** - -The All-In-One Duplex (AIO-DX) deployment option provides all three cloud -functions (controller, compute, and storage) on two physical servers. With cloud -technologies, multiple diverse application types can be deployed and -consolidated onto a protected pair of physical servers. For example: - -- Consolidate legacy applications that must run standalone on a server by - using multiple virtual machines. -- Consolidate legacy applications that run on different operating systems - or different distributions of operating systems by using multiple virtual - machines. - -.. figure:: figures/starlingx-deployment-options-duplex.png - :scale: 50% - :alt: All-In-One Duplex deployment configuration - - *All-In-One Duplex deployment configuration* - -This two node cluster enables the following: - -- High availability services running on the controller function across the - two physical servers in either active/active or active/standby mode. -- Storage function running on top of LVM on single second disk, DRBD-sync'd - between the servers. -- Virtual machines being scheduled on both compute functions. - -An All-In-One Duplex deployment provides protection against overall server -hardware fault. Should an overall server hardware fault occur: - -- All controller high availability services go active on remaining - healthy server. -- All virtual machines are recovered on the remaining healthy server. - -The All-In-One Duplex deployment solution is required for a variety of special -case situations. -Here are two examples: - -- Small amount of cloud processing/storage. -- Protection against overall server hardware faults. - -************************** -All-In-One Duplex extended -************************** - -The All-In-One Duplex Extended deployment option extends the capacity of the -All-In-One Duplex deployment by adding up to four compute nodes to the -deployment. The extended deployment option provides a capacity growth path for -someone starting with an All-In-One Duplex deployment. - -With this option, virtual machines can be scheduled on either of the -all-in-one controller nodes and/or the compute nodes. - -.. figure:: figures/starlingx-deployment-options-duplex-extended.png - :scale: 50% - :alt: All-In-One Duplex Extended Deployment Configuration - - *All-In-One Duplex Extended deployment configuration* - -This configuration is limited to four compute nodes as the controller function -on the all-in-one controllers has only a portion of the processing power of the -overall server. - ------------------------------------ -Preparing All-In-One Duplex servers ------------------------------------ - -********** -Bare metal -********** - -Required Servers: - -- Combined servers (controller + compute): 2 - -^^^^^^^^^^^^^^^^^^^^^ -Hardware requirements -^^^^^^^^^^^^^^^^^^^^^ - -The recommended minimum requirements for the physical servers where -All-In-One Duplex is deployed include the following: - -- Minimum processor: - - - Typical hardware form factor: - - - Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) 8 cores/socket - - Low cost / low power hardware form factor - - - Single-CPU Intel Xeon D-15xx family, 8 cores - -- Memory: 64 GB -- BIOS: - - - Hyper-Threading technology: Enabled - - Virtualization technology: Enabled - - VT for directed I/O: Enabled - - CPU power and performance policy: Performance - - CPU C state control: Disabled - - Plug & play BMC detection: Disabled - -- Primary disk: - - - 500 GB SSD or NVMe - -- Additional disks: - - - Zero or more 500 GB disks (min. 10K RPM) - -- Network ports: - - **NOTE:** The All-In-One Duplex configuration requires one or more data ports. - - - Management: 10GE - - OAM: 10GE - - Data: n x 10GE - -******************* -Virtual environment -******************* - -Run the libvirt QEMU setup scripts to set up virtualized OAM and -management networks: - -:: - - $ bash setup_network.sh - -Building XML for definition of virtual servers: - -:: - - $ bash setup_configuration.sh -c duplex -i - -The default XML server definitions that are created by the previous script -are: - -- duplex-controller-0 -- duplex-controller-1 - -^^^^^^^^^^^^^^^^^^^^^^^^^ -Power up a virtual server -^^^^^^^^^^^^^^^^^^^^^^^^^ - -To power up a virtual server, run the following command: - -:: - - $ sudo virsh start - -Here is an example: - -:: - - $ sudo virsh start duplex-controller-0 - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Access virtual server consoles -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The XML for virtual servers in stx-tools repo, deployment/libvirt, -provides both graphical and text consoles. -Follow these steps to access virtual server consoles: - -#. Access the graphical console in virt-manager by right-clicking on the - domain (i.e. the server) and selecting "Open". - -#. Access the textual console using the command "virsh console $DOMAIN", - where DOMAIN is the name of the server shown in virsh. - -#. When booting the controller-0 for the first time, both the serial and - graphical consoles present the initial configuration menu for the - cluster. You can select the serial or graphical console for controller-0. - However, for the other nodes, you can only use the serial console - regardless of the selected option. - -#. Open the graphic console on all servers before powering them on to - observe the boot device selection and PXI boot progress. Run the "virsh - console $DOMAIN" command promptly after powering up to see the initial boot - sequence that follows the boot device selection. Only a few seconds exist - during which you can see the sequence. - --------------------------------- -Installing the controller-0 host --------------------------------- - -Installing controller-0 involves initializing a host with software and -then applying a bootstrap configuration from the command line. The -configured bootstrapped host becomes controller-0. - -Following is the general procedure: - -#. Be sure the StarlingX ISO is on a USB device and it is plugged into - the USB port of the server that will be controller-0 and then - power on the server. - -#. Configure the controller using the config_controller script. - -************************* -Initializing controller-0 -************************* - -This section describes how to initialize StarlingX in host controller-0. -Except where noted, all the commands must be executed from a console of -the host. - -#. Be sure the StarlingX ISO is on a USB device and it is plugged into - the USB port of the server that will be controller-0. - -#. Power on the server. - -#. Wait for the console to show the StarlingX ISO booting options: - - - **All-in-one Controller Configuration** - - - When the installer is loaded and the installer welcome screen - appears in the controller-0 host, select "All-in-one Controller Configuration" - for the type of installation. - - - **Graphical Console** - - - Select the "Graphical Console" as the console to use during - installation. - - - **Standard Security Boot Profile** - - - Select "Standard Security Boot Profile" as the Security Profile. - -#. Monitor the initialization. When the installation is complete, a reboot is initiated - on the controller-0 host. The GNU GRUB screen briefly displays and then - boots automatically into the StarlingX image. - -#. Log into controller-0 as user wrsroot and use wrsroot as the password. The - first time you log in as wrsroot, you are required to change your - password. Enter the current password (i.e. wrsroot): - - :: - - Changing password for wrsroot. - (current) UNIX Password: - -#. Enter a new password for the wrsroot account: - - :: - - New password: - -#. Enter the new password again to confirm it: - - :: - - Retype new password: - -#. The controller-0 is initialized with StarlingX and is ready for configuration. - -************************ -Configuring controller-0 -************************ - -This section describes how to interactively configure controller-0 -to bootstrap the system with minimal critical data. -Except where noted, you must execute all commands from the console -of the active controller (i.e. controller-0). - -When run interactively, the config_controller script presents a series -of prompts for initial configuration of StarlingX: - -- For the virtual environment, you can accept all the default values - immediately after "system date and time". -- For a physical deployment, answer the bootstrap configuration - questions with answers applicable to your particular physical setup. - -The script configures the first controller in the StarlingX -cluster as controller-0. The prompts are grouped by configuration -area. - -Follow this procedure to interactively configure controller-0: - -#. Start the script with no parameters: - - :: - - controller-0:~$ sudo config_controller - System Configuration - ================ - Enter ! at any prompt to abort... - ... - -#. Select [y] for System date and time: - - :: - - System date and time: - ----------------------------- - - Is the current date and time correct? [y/N]: y - -#. For System mode choose "duplex": - - :: - - System mode. Available options are: - - 1) duplex-direct: two node-redundant configuration. Management and - infrastructure networks are directly connected to peer ports - 2) duplex - two node redundant configuration - 3) simplex - single node non-redundant configuration - System mode [duplex-direct]: 2 - -#. After System date and time and System mode: - - :: - - Applying configuration (this will take several minutes): - - 01/08: Creating bootstrap configuration ... DONE - 02/08: Applying bootstrap manifest ... DONE - 03/08: Persisting local configuration ... DONE - 04/08: Populating initial system inventory ... DONE - 05:08: Creating system configuration ... DONE - 06:08: Applying controller manifest ... DONE - 07:08: Finalize controller configuration ... DONE - 08:08: Waiting for service activation ... DONE - - Configuration was applied - - Please complete any out of service commissioning steps with system commands and unlock controller to proceed. - -#. After config_controller bootstrap configuration, REST API, CLI and - Horizon interfaces are enabled on the controller-0 OAM IP address. The - remaining installation instructions use the CLI. - ----------------------------------- -Provisioning the controller-0 host ----------------------------------- - -On controller-0, acquire Keystone administrative privileges: - -:: - - controller-0:~$ source /etc/nova/openrc - -********************************************* -Configuring provider networks at installation -********************************************* - -Set up one provider network of the vlan type and name it providernet-a: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ neutron providernet-create providernet-a --type=vlan - [wrsroot@controller-0 ~(keystone_admin)]$ neutron providernet-range-create --name providernet-a-range1 --range 100-400 providernet-a - -***************************************** -Providing data interfaces on controller-0 -***************************************** - -Follow these steps: - -#. List all interfaces: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-if-list -a controller-0 - +--------------------------------------+---------+----------+...+------+--------------+------+---------+------------+.. - | uuid | name | class |...| vlan | ports | uses | used by | attributes |.. - | | | |...| id | | i/f | i/f | |.. - +--------------------------------------+---------+----------+...+------+--------------+------+---------+------------+.. - | 49fd8938-e76f-49f1-879e-83c431a9f1af | enp0s3 | platform |...| None | [u'enp0s3'] | [] | [] | MTU=1500 |.. - | 8957bb2c-fec3-4e5d-b4ed-78071f9f781c | eth1000 | None |...| None | [u'eth1000'] | [] | [] | MTU=1500 |.. - | bf6f4cad-1022-4dd7-962b-4d7c47d16d54 | eth1001 | None |...| None | [u'eth1001'] | [] | [] | MTU=1500 |.. - | f59b9469-7702-4b46-bad5-683b95f0a1cb | enp0s8 | platform |...| None | [u'enp0s8'] | [] | [] | MTU=1500 |.. - +--------------------------------------+---------+----------+...+------+--------------+------+---------+------------+.. - -#. Configure the data interfaces: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-if-modify -c data controller-0 eth1000 -p providernet-a - +------------------+--------------------------------------+ - | Property | Value | - +------------------+--------------------------------------+ - | ifname | eth1000 | - | iftype | ethernet | - | ports | [u'eth1000'] | - | providernetworks | providernet-a | - | imac | 08:00:27:c4:ad:3e | - | imtu | 1500 | - | ifclass | data | - | aemode | None | - | schedpolicy | None | - | txhashpolicy | None | - | uuid | 8957bb2c-fec3-4e5d-b4ed-78071f9f781c | - | ihost_uuid | 9c332b27-6f22-433b-bf51-396371ac4608 | - | vlan_id | None | - | uses | [] | - | used_by | [] | - | created_at | 2018-08-28T12:50:51.820151+00:00 | - | updated_at | 2018-08-28T14:46:18.333109+00:00 | - | sriov_numvfs | 0 | - | ipv4_mode | disabled | - | ipv6_mode | disabled | - | accelerated | [True] | - +------------------+--------------------------------------+ - -************************************* -Configuring Cinder on controller disk -************************************* - -Follow these steps: - -#. Review the available disk space and capacity and obtain the uuid of the - physical disk: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-list controller-0 - +--------------------------------------+-----------+---------+---------+---------+------------+... - | uuid | device_no | device_ | device_ | size_mi | available_ |... - | | de | num | type | b | mib |... - +--------------------------------------+-----------+---------+---------+---------+------------+... - | 6b42c9dc-f7c0-42f1-a410-6576f5f069f1 | /dev/sda | 2048 | HDD | 600000 | 434072 |... - | | | | | | |... - | | | | | | |... - | 534352d8-fec2-4ca5-bda7-0e0abe5a8e17 | /dev/sdb | 2064 | HDD | 16240 | 16237 |... - | | | | | | |... - | | | | | | |... - | 146195b2-f3d7-42f9-935d-057a53736929 | /dev/sdc | 2080 | HDD | 16240 | 16237 |... - | | | | | | |... - | | | | | | |... - +--------------------------------------+-----------+---------+---------+---------+------------+... - -#. Create the 'cinder-volumes' local volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-lvg-add controller-0 cinder-volumes - +-----------------+--------------------------------------+ - | lvm_vg_name | cinder-volumes | - | vg_state | adding | - | uuid | 61cb5cd2-171e-4ef7-8228-915d3560cdc3 | - | ihost_uuid | 9c332b27-6f22-433b-bf51-396371ac4608 | - | lvm_vg_access | None | - | lvm_max_lv | 0 | - | lvm_cur_lv | 0 | - | lvm_max_pv | 0 | - | lvm_cur_pv | 0 | - | lvm_vg_size | 0.00 | - | lvm_vg_total_pe | 0 | - | lvm_vg_free_pe | 0 | - | created_at | 2018-08-28T13:45:20.218905+00:00 | - | updated_at | None | - | parameters | {u'lvm_type': u'thin'} | - +-----------------+--------------------------------------+ - -#. Create a disk partition to add to the volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-add controller-0 534352d8-fec2-4ca5-bda7-0e0abe5a8e17 16237 -t lvm_phys_vol - +-------------+--------------------------------------------------+ - | Property | Value | - +-------------+--------------------------------------------------+ - | device_path | /dev/disk/by-path/pci-0000:00:0d.0-ata-2.0-part1 | - | device_node | /dev/sdb1 | - | type_guid | ba5eba11-0000-1111-2222-000000000001 | - | type_name | None | - | start_mib | None | - | end_mib | None | - | size_mib | 16237 | - | uuid | 0494615f-bd79-4490-84b9-dcebbe5f377a | - | ihost_uuid | 9c332b27-6f22-433b-bf51-396371ac4608 | - | idisk_uuid | 534352d8-fec2-4ca5-bda7-0e0abe5a8e17 | - | ipv_uuid | None | - | status | Creating | - | created_at | 2018-08-28T13:45:48.512226+00:00 | - | updated_at | None | - +-------------+--------------------------------------------------+ - -#. Wait for the new partition to be created (i.e. status=Ready): - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-list controller-0 --disk 534352d8-fec2-4ca5-bda7-0e0abe5a8e17 - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - | uuid |...| device_nod |...| type_name | size_mib | status | - | |...| e |...| | | | - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - | 0494615f-bd79-4490-84b9-dcebbe5f377a |...| /dev/sdb1 |...| LVM Physical Volume | 16237 | Ready | - | |...| |...| | | | - | |...| |...| | | | - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - -#. Add the partition to the volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-pv-add controller-0 cinder-volumes 0494615f-bd79-4490-84b9-dcebbe5f377a - +--------------------------+--------------------------------------------------+ - | Property | Value | - +--------------------------+--------------------------------------------------+ - | uuid | 9a0ad568-0ace-4d57-9e03-e7a63f609cf2 | - | pv_state | adding | - | pv_type | partition | - | disk_or_part_uuid | 0494615f-bd79-4490-84b9-dcebbe5f377a | - | disk_or_part_device_node | /dev/sdb1 | - | disk_or_part_device_path | /dev/disk/by-path/pci-0000:00:0d.0-ata-2.0-part1 | - | lvm_pv_name | /dev/sdb1 | - | lvm_vg_name | cinder-volumes | - | lvm_pv_uuid | None | - | lvm_pv_size | 0 | - | lvm_pe_total | 0 | - | lvm_pe_alloced | 0 | - | ihost_uuid | 9c332b27-6f22-433b-bf51-396371ac4608 | - | created_at | 2018-08-28T13:47:39.450763+00:00 | - | updated_at | None | - +--------------------------+--------------------------------------------------+ - -********************************************* -Adding an LVM storage backend at installation -********************************************* - -Follow these steps: - -#. Ensure requirements are met to add LVM storage: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system storage-backend-add lvm -s cinder - - WARNING : THIS OPERATION IS NOT REVERSIBLE AND CANNOT BE CANCELLED. - - By confirming this operation, the LVM backend will be created. - - Please refer to the system admin guide for minimum spec for LVM - storage. Set the 'confirmed' field to execute this operation - for the lvm backend. - -#. Add the LVM storage backend: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system storage-backend-add lvm -s cinder --confirmed - - System configuration has changed. - Please follow the administrator guide to complete configuring the system. - - +--------------------------------------+------------+---------+-------------+...+----------+--------------+ - | uuid | name | backend | state |...| services | capabilities | - +--------------------------------------+------------+---------+-------------+...+----------+--------------+ - | 6d750a68-115a-4c26-adf4-58d6e358a00d | file-store | file | configured |...| glance | {} | - | e2697426-2d79-4a83-beb7-2eafa9ceaee5 | lvm-store | lvm | configuring |...| cinder | {} | - +--------------------------------------+------------+---------+-------------+...+----------+--------------+ - -#. Wait for the LVM storage backend to be configured (i.e. state=configured): - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system storage-backend-list - +--------------------------------------+------------+---------+------------+------+----------+--------------+ - | uuid | name | backend | state | task | services | capabilities | - +--------------------------------------+------------+---------+------------+------+----------+--------------+ - | 6d750a68-115a-4c26-adf4-58d6e358a00d | file-store | file | configured | None | glance | {} | - | e2697426-2d79-4a83-beb7-2eafa9ceaee5 | lvm-store | lvm | configured | None | cinder | {} | - +--------------------------------------+------------+---------+------------+------+----------+--------------+ - -*********************************************** -Configuring VM local storage on controller disk -*********************************************** - -Follow these steps: - -#. Review the available disk space and capacity and obtain the uuid of the - physical disk: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-list controller-0 - +--------------------------------------+-----------+---------+---------+---------+------------+... - | uuid | device_no | device_ | device_ | size_mi | available_ |... - | | de | num | type | b | mib |... - +--------------------------------------+-----------+---------+---------+---------+------------+... - | 6b42c9dc-f7c0-42f1-a410-6576f5f069f1 | /dev/sda | 2048 | HDD | 600000 | 434072 |... - | | | | | | |... - | | | | | | |... - | 534352d8-fec2-4ca5-bda7-0e0abe5a8e17 | /dev/sdb | 2064 | HDD | 16240 | 0 |... - | | | | | | |... - | | | | | | |... - | 146195b2-f3d7-42f9-935d-057a53736929 | /dev/sdc | 2080 | HDD | 16240 | 16237 |... - | | | | | | |... - | | | | | | |... - +--------------------------------------+-----------+---------+---------+---------+------------+... - -#. Create the 'noval-local' volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-lvg-add controller-0 nova-local - +-----------------+-------------------------------------------------------------------+ - | Property | Value | - +-----------------+-------------------------------------------------------------------+ - | lvm_vg_name | nova-local | - | vg_state | adding | - | uuid | 517d313e-8aa0-4b4d-92e6-774b9085f336 | - | ihost_uuid | 9c332b27-6f22-433b-bf51-396371ac4608 | - | lvm_vg_access | None | - | lvm_max_lv | 0 | - | lvm_cur_lv | 0 | - | lvm_max_pv | 0 | - | lvm_cur_pv | 0 | - | lvm_vg_size | 0.00 | - | lvm_vg_total_pe | 0 | - | lvm_vg_free_pe | 0 | - | created_at | 2018-08-28T14:02:58.486716+00:00 | - | updated_at | None | - | parameters | {u'concurrent_disk_operations': 2, u'instance_backing': u'image'} | - +-----------------+-------------------------------------------------------------------+ - -#. Create a disk partition to add to the volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-add controller-0 146195b2-f3d7-42f9-935d-057a53736929 16237 -t lvm_phys_vol - +-------------+--------------------------------------------------+ - | Property | Value | - +-------------+--------------------------------------------------+ - | device_path | /dev/disk/by-path/pci-0000:00:0d.0-ata-3.0-part1 | - | device_node | /dev/sdc1 | - | type_guid | ba5eba11-0000-1111-2222-000000000001 | - | type_name | None | - | start_mib | None | - | end_mib | None | - | size_mib | 16237 | - | uuid | 009ce3b1-ed07-46e9-9560-9d2371676748 | - | ihost_uuid | 9c332b27-6f22-433b-bf51-396371ac4608 | - | idisk_uuid | 146195b2-f3d7-42f9-935d-057a53736929 | - | ipv_uuid | None | - | status | Creating | - | created_at | 2018-08-28T14:04:29.714030+00:00 | - | updated_at | None | - +-------------+--------------------------------------------------+ - -#. Wait for the new partition to be created (i.e. status=Ready): - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-list controller-0 --disk 146195b2-f3d7-42f9-935d-057a53736929 - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - | uuid |...| device_nod |...| type_name | size_mib | status | - | |...| e |...| | | | - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - | 009ce3b1-ed07-46e9-9560-9d2371676748 |...| /dev/sdc1 |...| LVM Physical Volume | 16237 | Ready | - | |...| |...| | | | - | |...| |...| | | | - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - -#. Add the partition to the volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-pv-add controller-0 nova-local 009ce3b1-ed07-46e9-9560-9d2371676748 - +--------------------------+--------------------------------------------------+ - | Property | Value | - +--------------------------+--------------------------------------------------+ - | uuid | 830c9dc8-c71a-4cb2-83be-c4d955ef4f6b | - | pv_state | adding | - | pv_type | partition | - | disk_or_part_uuid | 009ce3b1-ed07-46e9-9560-9d2371676748 | - | disk_or_part_device_node | /dev/sdc1 | - | disk_or_part_device_path | /dev/disk/by-path/pci-0000:00:0d.0-ata-3.0-part1 | - | lvm_pv_name | /dev/sdc1 | - | lvm_vg_name | nova-local | - | lvm_pv_uuid | None | - | lvm_pv_size | 0 | - | lvm_pe_total | 0 | - | lvm_pe_alloced | 0 | - | ihost_uuid | 9c332b27-6f22-433b-bf51-396371ac4608 | - | created_at | 2018-08-28T14:06:05.705546+00:00 | - | updated_at | None | - +--------------------------+--------------------------------------------------+ - -********************** -Unlocking controller-0 -********************** - -You must unlock controller-0 so that you can use it to install -controller-1. Use the system host-unlock command: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-unlock controller-0 - -The host is rebooted. During the reboot, the command line is -unavailable, and any ssh connections are dropped. To monitor the -progress of the reboot, use the controller-0 console. - -**************************************** -Verifying the controller-0 configuration -**************************************** - -Follow these steps: - -#. On controller-0, acquire Keystone administrative privileges: - - :: - - controller-0:~$ source /etc/nova/openrc - -#. Verify that the controller-0 services are running: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system service-list - +-----+-------------------------------+--------------+----------------+ - | id | service_name | hostname | state | - +-----+-------------------------------+--------------+----------------+ - ... - | 1 | oam-ip | controller-0 | enabled-active | - | 2 | management-ip | controller-0 | enabled-active | - ... - +-----+-------------------------------+--------------+----------------+ - -#. Verify that controller-0 has controller and compute subfunctions: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-show 1 | grep subfunctions - | subfunctions | controller,compute | - -#. Verify that controller-0 is unlocked, enabled, and available: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - +----+--------------+-------------+----------------+-------------+--------------+ - --------------------------------- -Installing the controller-1 host --------------------------------- - -After initializing and configuring controller-0, you can add and -configure a backup controller controller-1. - -****************************** -Initializing controller-1 host -****************************** - -Power on controller-1. In the controller-1 console you will see: - -:: - - Waiting for this node to be configured. - - Please configure the personality for this node from the - controller node in order to proceed. - -*************************************************** -Updating controller-1 host hostname and personality -*************************************************** - -Follow these steps: - -#. On controller-0, acquire Keystone administrative privileges: - - :: - - controller-0:~$ source /etc/nova/openrc - -#. Wait for controller-0 to discover new host. - List the host until a new UNKNOWN host appears in table: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. Use the system host-update command to update the contoller-1 host personality - attribute: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-update 2 personality=controller hostname=controller-1 - +---------------------+--------------------------------------+ - | Property | Value | - +---------------------+--------------------------------------+ - | action | none | - | administrative | locked | - | availability | offline | - | bm_ip | None | - | bm_type | None | - | bm_username | None | - | boot_device | sda | - | capabilities | {} | - | config_applied | None | - | config_status | None | - | config_target | None | - | console | ttyS0,115200 | - | created_at | 2018-08-28T15:09:13.812906+00:00 | - | hostname | controller-1 | - | id | 2 | - | install_output | text | - | install_state | None | - | install_state_info | None | - | invprovision | None | - | location | {} | - | mgmt_ip | 192.168.204.4 | - | mgmt_mac | 08:00:27:3d:e2:66 | - | operational | disabled | - | personality | controller | - | reserved | False | - | rootfs_device | sda | - | serialid | None | - | software_load | 18.03 | - | subfunction_avail | not-installed | - | subfunction_oper | disabled | - | subfunctions | controller,compute | - | task | None | - | tboot | false | - | ttys_dcd | None | - | updated_at | None | - | uptime | 0 | - | uuid | be0f35f7-31d9-4145-bf6a-0c2556cf398c | - | vim_progress_status | None | - +---------------------+--------------------------------------+ - -**************************** -Monitoring controller-1 host -**************************** - -On controller-0, you can monitor the installation progress by running -the system host-show command for the host periodically. Progress appears -in the install_state field: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-show controller-1 | grep install - | install_output | text | - | install_state | booting | - | install_state_info | None | - -Wait while the controller-1 is configured and rebooted. -It might take up to 20 minutes for the reboot to complete depending -on the hardware. -When the reboot completes, controller-1 is reported as locked, disabled, and online. - -************************* -Listing controller-1 host -************************* - -Once controller-1 has been installed, configured, and rebooted, -list the hosts on controller-0: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - ----------------------------------- -Provisioning the controller-1 host ----------------------------------- - -List the hosts on controller-0: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - ... - | 2 | controller-1 | controller | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - -*********************************************** -Provisioning network interfaces on controller-1 -*********************************************** - -Follow these steps: - -#. Use the host-port-list command to list hardware port names, types, - and PCI addresses that have been discovered: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-port-list controller-1 - -#. Provision the controller-1 OAM interface: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-if-modify -n ens6 -c platform --networks oam controller-1 ens6 - +------------------+--------------------------------------+ - | Property | Value | - +------------------+--------------------------------------+ - | ifname | ens6 | - | iftype | ethernet | - | ports | [u'ens6'] | - | providernetworks | None | - | imac | 08:00:27:ba:3c:38 | - | imtu | 1500 | - | ifclass | oam | - | aemode | None | - | schedpolicy | None | - | txhashpolicy | None | - | uuid | 160bfede-0950-42ba-acef-d0eb31e7fc49 | - | ihost_uuid | be0f35f7-31d9-4145-bf6a-0c2556cf398c | - | vlan_id | None | - | uses | [] | - | used_by | [] | - | created_at | 2018-08-28T15:59:10.701772+00:00 | - | updated_at | 2018-08-29T05:44:38.585642+00:00 | - | sriov_numvfs | 0 | - | ipv4_mode | static | - | ipv6_mode | disabled | - | accelerated | [False] | - +------------------+--------------------------------------+ - -***************************************** -Providing data interfaces on controller-1 -***************************************** - -Follow these steps: - -#. List all interfaces: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-if-list -a controller-1 - +--------------------------------------+---------+---------+...+------+--------------+------+------+------------+.. - | uuid | name | network |...| vlan | ports | uses | used | attributes |.. - | | | type |...| id | | i/f | by | |.. - | | | |...| | | | i/f | |.. - +--------------------------------------+---------+---------+...+------+--------------+------+------+------------+.. - | 160bfede-0950-42ba-acef-d0eb31e7fc49 | ens6 | oam |...| None | [u'enp0s3'] | [] | [] | MTU=1500 |.. - | 37b3abcd-bcbe-44d5-b2fb-759c34efec89 | eth1001 | None |...| None | [u'eth1001'] | [] | [] | MTU=1500 |.. - | 81d66feb-b23c-4533-bd4b-129f9b75ecd6 | mgmt0 | mgmt |...| None | [u'enp0s8'] | [] | [] | MTU=1500 |.. - | e78ad9a9-e74d-4c6c-9de8-0e41aad8d7b7 | eth1000 | None |...| None | [u'eth1000'] | [] | [] | MTU=1500 |.. - +--------------------------------------+---------+---------+...+------+--------------+------+------+------------+.. - -#. Configure the data interfaces: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-if-modify -p providernet-a -c data controller-1 eth1000 - +------------------+--------------------------------------+ - | Property | Value | - +------------------+--------------------------------------+ - | ifname | eth1000 | - | networktype | data | - | iftype | ethernet | - | ports | [u'eth1000'] | - | providernetworks | providernet-a | - | imac | 08:00:27:39:61:6e | - | imtu | 1500 | - | aemode | None | - | schedpolicy | None | - | txhashpolicy | None | - | uuid | e78ad9a9-e74d-4c6c-9de8-0e41aad8d7b7 | - | ihost_uuid | be0f35f7-31d9-4145-bf6a-0c2556cf398c | - | vlan_id | None | - | uses | [] | - | used_by | [] | - | created_at | 2018-08-28T15:59:17.667899+00:00 | - | updated_at | 2018-08-29T06:04:55.116653+00:00 | - | sriov_numvfs | 0 | - | ipv4_mode | disabled | - | ipv6_mode | disabled | - | accelerated | [True] | - +------------------+--------------------------------------+ - -************************************ -Provisioning storage on controller-1 -************************************ - -Follow these steps: - -#. Review the available disk space and capacity and obtain the uuid of the - physical disk: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-list controller-1 - +--------------------------------------+-------------+------------+-------------+----------+---------------+... - | uuid | device_node | device_num | device_type | size_mib | available_mib |... - +--------------------------------------+-------------+------------+-------------+----------+---------------+... - | 2dcc3d33-ba43-4b5a-b0b0-2b5a2e5737b7 | /dev/sda | 2048 | HDD | 600000 | 434072 |... - | f53437c6-77e3-4185-9453-67eaa8b461b1 | /dev/sdb | 2064 | HDD | 16240 | 16237 |... - | 623bbfc0-2b38-432a-acf4-a28db6066cce | /dev/sdc | 2080 | HDD | 16240 | 16237 |... - +--------------------------------------+-------------+------------+-------------+----------+---------------+... - -#. Assign Cinder storage to the physical disk: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-lvg-add controller-1 cinder-volumes - +-----------------+--------------------------------------+ - | Property | Value | - +-----------------+--------------------------------------+ - | lvm_vg_name | cinder-volumes | - | vg_state | adding | - | uuid | 3ccadc5c-e4f7-4b04-8403-af5d2ecef96d | - | ihost_uuid | be0f35f7-31d9-4145-bf6a-0c2556cf398c | - | lvm_vg_access | None | - | lvm_max_lv | 0 | - | lvm_cur_lv | 0 | - | lvm_max_pv | 0 | - | lvm_cur_pv | 0 | - | lvm_vg_size | 0.00 | - | lvm_vg_total_pe | 0 | - | lvm_vg_free_pe | 0 | - | created_at | 2018-08-29T05:51:13.965883+00:00 | - | updated_at | None | - | parameters | {u'lvm_type': u'thin'} | - +-----------------+--------------------------------------+ - -#. Create a disk partition to add to the volume group based on the uuid of the - physical disk: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-add controller-1 f53437c6-77e3-4185-9453-67eaa8b461b1 16237 -t lvm_phys_vol - +-------------+--------------------------------------------------+ - | Property | Value | - +-------------+--------------------------------------------------+ - | device_path | /dev/disk/by-path/pci-0000:00:0d.0-ata-2.0-part1 | - | device_node | /dev/sdb1 | - | type_guid | ba5eba11-0000-1111-2222-000000000001 | - | type_name | None | - | start_mib | None | - | end_mib | None | - | size_mib | 16237 | - | uuid | 7a41aab0-6695-4d16-9003-73238adda75b | - | ihost_uuid | be0f35f7-31d9-4145-bf6a-0c2556cf398c | - | idisk_uuid | f53437c6-77e3-4185-9453-67eaa8b461b1 | - | ipv_uuid | None | - | status | Creating (on unlock) | - | created_at | 2018-08-29T05:54:23.326612+00:00 | - | updated_at | None | - +-------------+--------------------------------------------------+ - -#. Wait for the new partition to be created (i.e. status=Ready): - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-list controller-1 --disk f53437c6-77e3-4185-9453-67eaa8b461b1 - +--------------------------------------+...+-------------+...+-----------+----------+----------------------+ - | uuid |...| device_node |...| type_name | size_mib | status | - +--------------------------------------+...+-------------+...+-----------+----------+----------------------+ - | 7a41aab0-6695-4d16-9003-73238adda75b |...| /dev/sdb1 |...| None | 16237 | Creating (on unlock) | - +--------------------------------------+...+-------------+...+-----------+----------+----------------------+ - -#. Add the partition to the volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-pv-add controller-1 cinder-volumes 7a41aab0-6695-4d16-9003-73238adda75b - +--------------------------+--------------------------------------------------+ - | Property | Value | - +--------------------------+--------------------------------------------------+ - | uuid | 11628316-56ab-41b2-b2be-a5d72667a5e9 | - | pv_state | adding | - | pv_type | partition | - | disk_or_part_uuid | 7a41aab0-6695-4d16-9003-73238adda75b | - | disk_or_part_device_node | /dev/sdb1 | - | disk_or_part_device_path | /dev/disk/by-path/pci-0000:00:0d.0-ata-2.0-part1 | - | lvm_pv_name | /dev/sdb1 | - | lvm_vg_name | cinder-volumes | - | lvm_pv_uuid | None | - | lvm_pv_size | 0 | - | lvm_pe_total | 0 | - | lvm_pe_alloced | 0 | - | ihost_uuid | be0f35f7-31d9-4145-bf6a-0c2556cf398c | - | created_at | 2018-08-29T06:25:54.550430+00:00 | - | updated_at | None | - +--------------------------+--------------------------------------------------+ - -*********************************************** -Configuring VM local storage on controller disk -*********************************************** - -Follow these steps: - -#. Review the available disk space and capacity and obtain the uuid of the - physical disk: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-list controller-1 - +--------------------------------------+-------------+------------+-------------+----------+---------------+... - | uuid | device_node | device_num | device_type | size_mib | available_mib |... - +--------------------------------------+-------------+------------+-------------+----------+---------------+... - | 2dcc3d33-ba43-4b5a-b0b0-2b5a2e5737b7 | /dev/sda | 2048 | HDD | 600000 | 434072 |... - | f53437c6-77e3-4185-9453-67eaa8b461b1 | /dev/sdb | 2064 | HDD | 16240 | 16237 |... - | 623bbfc0-2b38-432a-acf4-a28db6066cce | /dev/sdc | 2080 | HDD | 16240 | 16237 |... - +--------------------------------------+-------------+------------+-------------+----------+---------------+... - -#. Create the 'cinder-volumes' local volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-lvg-add controller-1 nova-local - +-----------------+-------------------------------------------------------------------+ - | Property | Value | - +-----------------+-------------------------------------------------------------------+ - | lvm_vg_name | nova-local | - | vg_state | adding | - | uuid | d205f839-0930-4e77-9f10-97089150f812 | - | ihost_uuid | be0f35f7-31d9-4145-bf6a-0c2556cf398c | - | lvm_vg_access | None | - | lvm_max_lv | 0 | - | lvm_cur_lv | 0 | - | lvm_max_pv | 0 | - | lvm_cur_pv | 0 | - | lvm_vg_size | 0.00 | - | lvm_vg_total_pe | 0 | - | lvm_vg_free_pe | 0 | - | created_at | 2018-08-29T06:28:28.226907+00:00 | - | updated_at | None | - | parameters | {u'concurrent_disk_operations': 2, u'instance_backing': u'image'} | - +-----------------+-------------------------------------------------------------------+ - -#. Create a disk partition to add to the volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-add controller-1 623bbfc0-2b38-432a-acf4-a28db6066cce 16237 -t lvm_phys_vol - +-------------+--------------------------------------------------+ - | Property | Value | - +-------------+--------------------------------------------------+ - | device_path | /dev/disk/by-path/pci-0000:00:0d.0-ata-3.0-part1 | - | device_node | /dev/sdc1 | - | type_guid | ba5eba11-0000-1111-2222-000000000001 | - | type_name | None | - | start_mib | None | - | end_mib | None | - | size_mib | 16237 | - | uuid | f7bc6095-9375-49fe-83c7-12601c202376 | - | ihost_uuid | be0f35f7-31d9-4145-bf6a-0c2556cf398c | - | idisk_uuid | 623bbfc0-2b38-432a-acf4-a28db6066cce | - | ipv_uuid | None | - | status | Creating (on unlock) | - | created_at | 2018-08-29T06:30:33.176428+00:00 | - | updated_at | None | - +-------------+--------------------------------------------------+ - -#. Wait for the new partition to be created (i.e. status=Ready): - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-list controller-1 - +--------------------------------------+...+-------------+...+-----------+----------+----------------------+ - | uuid |...| device_node |...| type_name | size_mib | status | - +--------------------------------------+...+-------------+...+-----------+----------+----------------------+ - | 7a41aab0-6695-4d16-9003-73238adda75b |...| /dev/sdb1 |...| None | 16237 | Creating (on unlock) | - | f7bc6095-9375-49fe-83c7-12601c202376 |...| /dev/sdc1 |...| None | 16237 | Creating (on unlock) | - +--------------------------------------+...+-------------+...+-----------+----------+----------------------+ - -#. Add the partition to the volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-pv-add controller-1 nova-local f7bc6095-9375-49fe-83c7-12601c202376 - +--------------------------+--------------------------------------------------+ - | Property | Value | - +--------------------------+--------------------------------------------------+ - | uuid | 94003d64-4e1b-483a-8a6c-0fc4b1e0e272 | - | pv_state | adding | - | pv_type | partition | - | disk_or_part_uuid | f7bc6095-9375-49fe-83c7-12601c202376 | - | disk_or_part_device_node | /dev/sdc1 | - | disk_or_part_device_path | /dev/disk/by-path/pci-0000:00:0d.0-ata-3.0-part1 | - | lvm_pv_name | /dev/sdc1 | - | lvm_vg_name | nova-local | - | lvm_pv_uuid | None | - | lvm_pv_size | 0 | - | lvm_pe_total | 0 | - | lvm_pe_alloced | 0 | - | ihost_uuid | be0f35f7-31d9-4145-bf6a-0c2556cf398c | - | created_at | 2018-08-29T06:33:08.625604+00:00 | - | updated_at | None | - +--------------------------+--------------------------------------------------+ - -********************** -Unlocking controller-1 -********************** - -Follow these steps: - -#. Unlock controller-1: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-unlock controller-1 - -#. Wait while the controller-1 is rebooted. - It might take up to 10 minutes for the boot to complete depending - on the hardware. - - **NOTE:** controller-1 will remain in a degraded state until data-syncing - completes. The duration is dependant on the virtualization host's - configuration (i.e. the number and configuration of physical disks - used to host the nodes' virtual disks. Also, the management network is - expected to have link capacity of 10000. - Link capacity of 1000 is not supported due to excessive data-sync time. - Use 'fm alarm-list' to confirm status. - -#. List the hosts: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | unlocked | enabled | available | - +----+--------------+-------------+----------------+-------------+--------------+ - ------------------------------------ -Extending the compute node capacity ------------------------------------ - -You can add up to four compute nodes to the All-in-One Duplex deployment. - -************************** -Compute hosts installation -************************** - -After initializing and configuring the two controllers, you can add up -to four additional compute hosts. To add a host, do the following: - -^^^^^^^^^^^^^^^^^^^ -Initialize the host -^^^^^^^^^^^^^^^^^^^ - -Power on the host. The following appears in the host console: - -:: - - Waiting for this node to be configured. - - Please configure the personality for this node from the - controller node in order to proceed. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Update the hostname and personality -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Follow these steps: - -#. On controller-0, acquire Keystone administrative privileges: - - :: - - controller-0:~$ source /etc/nova/openrc - -#. Wait for the controller-0 to both discover the new host and to list that host - as UNKNOWN in the table: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | online | - | 2 | controller-1 | controller | unlocked | enabled | online | - | 3 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. Use the system host-update command to update the host personality attribute: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-update 3 personality=compute hostname=compute-0 - - **NOTE:** You can also see the 'system help host-update' for more information. - - Unless it is known that the host's configuration can support the - installation of more than one node, it is recommended that the - installation and configuration of each node be serialized. For example, - if the virtual disks for the entire cluster are hosted on the host's - root disk and that disk happens to be a single rotational type hard disk, - then the host cannot reliably support parallel node installation. - -^^^^^^^^^^^^ -Monitor host -^^^^^^^^^^^^ - -On controller-0, you can monitor the installation progress by periodically -running the system host-show command for the host. Progress appears -in the install_state field. - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-show | grep install - | install_output | text | - | install_state | booting | - | install_state_info | None | - -Wait while the host is installed, configured, and rebooted. -It might take up to 20 minutes for the boot to complete depending on the hardware. -When the reboot completes, the host is reported as locked, disabled, -and online. - -^^^^^^^^^^ -List hosts -^^^^^^^^^^ - -You can use the system host-list command to list the hosts once the node -has been installed, configured, and rebooted: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | online | - | 2 | controller-1 | controller | unlocked | enabled | online | - | 3 | compute-0 | compute | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - -***************************** -Provisioning the compute host -***************************** - -You must configure the network interfaces and the storage disks on a -host before you can unlock it. For each compute host, do the following: - -On controller-0, acquire Keystone administrative privileges: - -:: - - controller-0:~$ source /etc/nova/openrc - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Provision network interfaces on a compute host -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Follow these steps: - -#. In order to identify hardware port names, types, and discovered - pci-addresses on controller-0, list the host ports: - - - **Only in virtual environment**: Ensure that the interface used is - one of those attached to the host bridge with model type "virtio" (i.e. - eth1000 and eth1001). The model type "e1000" emulated devices will - not work for provider networks: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-port-list compute-0 - +--------------------------------------+---------+----------+--------------+... - | uuid | name | type | pci address |... - +--------------------------------------+---------+----------+--------------+... - | de9ec830-cf33-4a06-8985-cd3262f6ecd3 | enp2s1 | ethernet | 0000:02:01.0 |... - | 9def88fb-d871-4542-83e2-d4b6e35169a1 | enp2s2 | ethernet | 0000:02:02.0 |... - | b2e38da9-840f-446c-b466-ceb6479266f6 | eth1000 | ethernet | 0000:02:03.0 |... - | c1694675-643d-4ba7-b821-cd147450112e | eth1001 | ethernet | 0000:02:04.0 |... - +--------------------------------------+---------+----------+--------------+... - -#. Use the following command to provision the data interface for compute: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-if-modify -p providernet-a -c data compute-0 eth1000 - -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -VSwitch virtual environment -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -**Only in virtual environment**. If the compute node has more than four CPUs, -the system auto-configures the vswitch to use two cores. However, some virtual -environments do not properly support multi-queue, which is required in a -multi-CPU environment. Therefore, run the following command to reduce the -vswitch cores to one: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-cpu-modify compute-0 -f vswitch -p0 1 - +--------------------------------------+-------+-----------+-------+--------+... - | uuid | log_c | processor | phy_c | thread |... - +--------------------------------------+-------+-----------+-------+--------+... - | 9d53c015-8dd5-4cd8-9abb-6f231fa773c2 | 0 | 0 | 0 | 0 |... - | 8620eaa7-19af-4ef7-a5aa-690ed57f01c7 | 1 | 0 | 1 | 0 |... - | f26598a5-8029-4d20-999e-2ec5d532d62e | 2 | 0 | 2 | 0 |... - | f7b3ce4a-10da-485d-873c-4e6988f7e9cf | 3 | 0 | 3 | 0 |... - +--------------------------------------+-------+-----------+-------+--------+... - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Provision storage on a compute host -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Follow these steps: - -#. Review the available disk space and capacity and then obtain the uuid(s) of - the physical disk(s) to be used for nova local: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-list compute-0 - +--------------------------------------+-----------+---------+---------+-------+------------+... - | uuid | device_no | device_ | device_ | size_ | available |... - | | de | num | type | gib | gib |... - +--------------------------------------+-----------+---------+---------+-------+------------+... - | 0ae45272-c9f4-4824-8405-f6c8946fda1e | /dev/sda | 2048 | HDD | 200.0 | 120.976 |... - | d751abfe-de57-4b23-b166-1d3d5b4d5ca6 | /dev/sdb | 2064 | HDD | 200.0 | 199.997 |... - +--------------------------------------+-----------+---------+---------+-------+------------+... - -#. Use the following command to create the 'nova-local' local volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-lvg-add compute-0 nova-local - +-----------------------+-------------------------------------------------------------------+ - | Property | Value | - +-----------------------+-------------------------------------------------------------------+ - | lvm_vg_name | nova-local | - | vg_state | adding | - | uuid | 78e84a57-c40e-438c-97a4-49ebec6394d1 | - | ihost_uuid | 6f2de9b6-c55c-47b0-b40e-aff47f1e1bda | - | lvm_vg_access | None | - | lvm_max_lv | 0 | - | lvm_cur_lv | 0 | - | lvm_max_pv | 0 | - | lvm_cur_pv | 0 | - | lvm_vg_size_gib | 0.0 | - | lvm_vg_avail_size_gib | 0.0 | - | lvm_vg_total_pe | 0 | - | lvm_vg_free_pe | 0 | - | created_at | 2019-01-15T12:31:45.796538+00:00 | - | updated_at | None | - | parameters | {u'concurrent_disk_operations': 2, u'instance_backing': u'image'} | - +-----------------------+-------------------------------------------------------------------+ - -#. Use the following command to create a disk partition to add to the volume - group based on the uuid of the physical disk: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-pv-add compute-0 nova-local d751abfe-de57-4b23-b166-1d3d5b4d5ca6 - +--------------------------+--------------------------------------------+ - | Property | Value | - +--------------------------+--------------------------------------------+ - | uuid | bba20f20-81fc-40a2-bf1e-a2fae849625b | - | pv_state | adding | - | pv_type | disk | - | disk_or_part_uuid | d751abfe-de57-4b23-b166-1d3d5b4d5ca6 | - | disk_or_part_device_node | /dev/sdb | - | disk_or_part_device_path | /dev/disk/by-path/pci-0000:00:1f.2-ata-2.0 | - | lvm_pv_name | /dev/sdb | - | lvm_vg_name | nova-local | - | lvm_pv_uuid | None | - | lvm_pv_size_gib | 0.0 | - | lvm_pe_total | 0 | - | lvm_pe_alloced | 0 | - | ihost_uuid | 6f2de9b6-c55c-47b0-b40e-aff47f1e1bda | - | created_at | 2019-01-15T12:32:40.535160+00:00 | - | updated_at | None | - +--------------------------+--------------------------------------------+ - -^^^^^^^^^^^^^^^^^^^^^ -Unlock a compute host -^^^^^^^^^^^^^^^^^^^^^ - -On controller-0, use the system host-unlock command to unlock the -compute node: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-unlock compute-0 - -Wait while the compute node is rebooted and re-configured. -It might take up to 10 minutes for the reboot to complete depending -on the hardware. -Once the reboot is complete, the nodes availability state appears in the -"in-test" field and is followed by unlocked/enabled. - -------------------- -System health check -------------------- - -*********************** -Listing StarlingX nodes -*********************** - -On controller-0, after a few minutes, all nodes are reported as -unlocked, enabled, and available: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | unlocked | enabled | available | - | 3 | compute-0 | compute | unlocked | enabled | available | - +----+--------------+-------------+----------------+-------------+--------------+ - -***************** -System alarm list -***************** - -When all nodes are unlocked, enabled, and available, check 'fm alarm-list' for -issues. - -Your StarlingX deployment is now up and running with 2x HA controllers with -Cinder storage and all OpenStack services up and running. You can now proceed -with standard OpenStack APIs, CLIs and/or Horizon to load Glance images, -configure Nova Flavors, configure Neutron networks, and launch Nova virtual -machines. - ----------------------- -Deployment terminology ----------------------- - -.. include:: deployment_terminology.rst - :start-after: incl-simplex-deployment-terminology: - :end-before: incl-simplex-deployment-terminology-end: - -.. include:: deployment_terminology.rst - :start-after: incl-standard-controller-deployment-terminology: - :end-before: incl-standard-controller-deployment-terminology-end: - -.. include:: deployment_terminology.rst - :start-after: incl-common-deployment-terminology: - :end-before: incl-common-deployment-terminology-end: diff --git a/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-controller-storage.png b/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-controller-storage.png deleted file mode 100644 index c1d028acf..000000000 Binary files a/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-controller-storage.png and /dev/null differ diff --git a/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-dedicated-storage.png b/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-dedicated-storage.png deleted file mode 100644 index 00e4c3eba..000000000 Binary files a/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-dedicated-storage.png and /dev/null differ diff --git a/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-duplex-extended.png b/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-duplex-extended.png deleted file mode 100644 index 64bb7f5ab..000000000 Binary files a/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-duplex-extended.png and /dev/null differ diff --git a/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-duplex.png b/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-duplex.png deleted file mode 100644 index 3638e4a10..000000000 Binary files a/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-duplex.png and /dev/null differ diff --git a/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-simplex.png b/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-simplex.png deleted file mode 100644 index 317b7cf49..000000000 Binary files a/doc/source/deploy_install_guides/r1_release/figures/starlingx-deployment-options-simplex.png and /dev/null differ diff --git a/doc/source/deploy_install_guides/r1_release/index.rst b/doc/source/deploy_install_guides/r1_release/index.rst deleted file mode 100644 index f712ae237..000000000 --- a/doc/source/deploy_install_guides/r1_release/index.rst +++ /dev/null @@ -1,300 +0,0 @@ -=========================== -StarlingX R1.0 Installation -=========================== - -.. important:: - - Significant changes in the underlying StarlingX infrastructure have occurred - since the R1.0 release. Due to these changes, the R1.0 installation - instructions may not work as described. - - Installation of the current :ref:`latest_release` is recommended. - -This is the installation guide for the StarlingX R1.0 release. If this is not -the installation guide you want to use, see the :doc:`available installation -guides `. - ------------- -Introduction ------------- - -StarlingX may be installed in: - -- **Bare metal**: Real deployments of StarlingX are only supported on - physical servers. -- **Virtual environment**: It should only be used for evaluation or - development purposes. - -StarlingX installed in virtual environments has two options: - -- :doc:`Libvirt/QEMU ` -- VirtualBox - ------------- -Requirements ------------- - -Different use cases require different configurations. - -********** -Bare metal -********** - -The minimum requirements for the physical servers where StarlingX might -be deployed, include: - -- **Controller hosts** - - - Minimum processor is: - - - Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) 8 - cores/socket - - - Minimum memory: 64 GB - - Hard drives: - - - Primary hard drive, minimum 500 GB for OS and system databases. - - Secondary hard drive, minimum 500 GB for persistent VM storage. - - - 2 physical Ethernet interfaces: OAM and MGMT network. - - USB boot support. - - PXE boot support. - -- **Storage hosts** - - - Minimum processor is: - - - Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) 8 - cores/socket. - - - Minimum memory: 64 GB. - - Hard drives: - - - Primary hard drive, minimum 500 GB for OS. - - 1 or more additional hard drives for CEPH OSD storage, and - - Optionally 1 or more SSD or NVMe drives for CEPH journals. - - - 1 physical Ethernet interface: MGMT network - - PXE boot support. - -- **Compute hosts** - - - Minimum processor is: - - - Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) 8 - cores/socket. - - - Minimum memory: 32 GB. - - Hard drives: - - - Primary hard drive, minimum 500 GB for OS. - - 1 or more additional hard drives for ephemeral VM storage. - - - 2 or more physical Ethernet interfaces: MGMT network and 1 or more - provider networks. - - PXE boot support. - -- **All-In-One Simplex or Duplex, controller + compute hosts** - - - Minimum processor is: - - - Typical hardware form factor: - - - Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) 8 cores/socket - - Low cost / low power hardware form factor - - - Single-CPU Intel Xeon D-15xx family, 8 cores - - - Minimum memory: 64 GB. - - Hard drives: - - - Primary hard drive, minimum 500 GB SSD or NVMe. - - 0 or more 500 GB disks (min. 10K RPM). - - - Network ports: - - **NOTE:** Duplex and Simplex configurations require one or more data - ports. - The Duplex configuration requires a management port. - - - Management: 10GE (Duplex only) - - OAM: 10GE - - Data: n x 10GE - -The recommended minimum requirements for the physical servers are -described later in each StarlingX deployment guide. - -^^^^^^^^^^^^^^^^^^^^^^^^ -NVMe drive as boot drive -^^^^^^^^^^^^^^^^^^^^^^^^ - -To use a Non-Volatile Memory Express (NVMe) drive as the boot drive for any of -your nodes, you must configure your host and adjust kernel parameters during -installation: - -- Configure the host to be in UEFI mode. -- Edit the kernel boot parameter. After you are presented with the StarlingX - ISO boot options and after you have selected the preferred installation option - (e.g. Standard Configuration / All-in-One Controller Configuration), press the - TAB key to edit the kernel boot parameters. Modify the **boot_device** and - **rootfs_device** from the default **sda** so that it is the correct device - name for the NVMe drive (e.g. "nvme0n1"). - - :: - - vmlinuz rootwait console=tty0 inst.text inst.stage2=hd:LABEL=oe_iso_boot - inst.ks=hd:LABEL=oe_iso_boot:/smallsystem_ks.cfg boot_device=nvme0n1 - rootfs_device=nvme0n1 biosdevname=0 usbcore.autosuspend=-1 inst.gpt - security_profile=standard user_namespace.enable=1 initrd=initrd.img - - -******************* -Virtual environment -******************* - -The recommended minimum requirements for the workstation, hosting the -virtual machine(s) where StarlingX will be deployed, include: - -^^^^^^^^^^^^^^^^^^^^^ -Hardware requirements -^^^^^^^^^^^^^^^^^^^^^ - -A workstation computer with: - -- Processor: x86_64 only supported architecture with BIOS enabled - hardware virtualization extensions -- Cores: 8 (4 with careful monitoring of cpu load) -- Memory: At least 32GB RAM -- Hard Disk: 500GB HDD -- Network: Two network adapters with active Internet connection - -^^^^^^^^^^^^^^^^^^^^^ -Software requirements -^^^^^^^^^^^^^^^^^^^^^ - -A workstation computer with: - -- Operating System: Freshly installed Ubuntu 16.04 LTS 64-bit -- Proxy settings configured (if applies) -- Git -- KVM/VirtManager -- Libvirt library -- QEMU full-system emulation binaries -- stx-tools project -- StarlingX ISO image - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Deployment environment setup -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This section describes how to set up the workstation computer which will -host the virtual machine(s) where StarlingX will be deployed. - -'''''''''''''''''''''''''''''' -Updating your operating system -'''''''''''''''''''''''''''''' - -Before proceeding with the build, ensure your OS is up to date. You’ll -first need to update the local database list of available packages: - -:: - - $ sudo apt-get update - -''''''''''''''''''''''''' -Install stx-tools project -''''''''''''''''''''''''' - -Clone the stx-tools project. Usually you’ll want to clone it under your -user’s home directory. - -:: - - $ cd $HOME - $ git clone https://git.starlingx.io/stx-tools - - -'''''''''''''''''''''''''''''''''''''''' -Installing requirements and dependencies -'''''''''''''''''''''''''''''''''''''''' - -Navigate to the stx-tools installation libvirt directory: - -:: - - $ cd $HOME/stx-tools/deployment/libvirt/ - - -Install the required packages: - -:: - - $ bash install_packages.sh - - -'''''''''''''''''' -Disabling firewall -'''''''''''''''''' - -Unload firewall and disable firewall on boot: - -:: - - $ sudo ufw disable - Firewall stopped and disabled on system startup - $ sudo ufw status - Status: inactive - - -------------------------------- -Getting the StarlingX ISO image -------------------------------- - -Follow the instructions from the :doc:`/developer_resources/build_guide` to build a -StarlingX ISO image. - -********** -Bare metal -********** - -A bootable USB flash drive containing StarlingX ISO image. - - -******************* -Virtual environment -******************* - -Copy the StarlingX ISO Image to the stx-tools deployment libvirt project -directory: - -:: - - $ cp $HOME/stx-tools/deployment/libvirt/ - - ------------------- -Deployment options ------------------- - -- Standard controller - - .. toctree:: - :maxdepth: 1 - - controller_storage - dedicated_storage - -- All-in-one - - .. toctree:: - :maxdepth: 1 - - simplex - duplex - - -.. toctree:: - :hidden: - - installation_libvirt_qemu - diff --git a/doc/source/deploy_install_guides/r1_release/installation_libvirt_qemu.rst b/doc/source/deploy_install_guides/r1_release/installation_libvirt_qemu.rst deleted file mode 100644 index 504cda311..000000000 --- a/doc/source/deploy_install_guides/r1_release/installation_libvirt_qemu.rst +++ /dev/null @@ -1,204 +0,0 @@ -============================== -Installation libvirt qemu R1.0 -============================== - -Installation for StarlingX R1.0 using Libvirt/QEMU virtualization. - ---------------------- -Hardware requirements ---------------------- - -A workstation computer with: - -- Processor: x86_64 only supported architecture with BIOS enabled - hardware virtualization extensions -- Memory: At least 32GB RAM -- Hard disk: 500GB HDD -- Network: One network adapter with active Internet connection - ---------------------- -Software requirements ---------------------- - -A workstation computer with: - -- Operating system: This process is known to work on Ubuntu 16.04 and - is likely to work on other Linux OS's with some appropriate adjustments. -- Proxy settings configured (if applies) -- Git -- KVM/VirtManager -- Libvirt library -- QEMU full-system emulation binaries -- stx-tools project -- StarlingX ISO image - ----------------------------- -Deployment environment setup ----------------------------- - -************* -Configuration -************* - -These scripts are configured using environment variables that all have -built-in defaults. On shared systems you probably do not want to use the -defaults. The simplest way to handle this is to keep a rc file that can -be sourced into an interactive shell that configures everything. Here's -an example called stxcloud.rc: - -:: - - export CONTROLLER=stxcloud - export COMPUTE=stxnode - export STORAGE=stxstorage - export BRIDGE_INTERFACE=stxbr - export INTERNAL_NETWORK=172.30.20.0/24 - export INTERNAL_IP=172.30.20.1/24 - export EXTERNAL_NETWORK=192.168.20.0/24 - export EXTERNAL_IP=192.168.20.1/24 - - -This rc file shows the defaults baked into the scripts: - -:: - - export CONTROLLER=controller - export COMPUTE=compute - export STORAGE=storage - export BRIDGE_INTERFACE=stxbr - export INTERNAL_NETWORK=10.10.10.0/24 - export INTERNAL_IP=10.10.10.1/24 - export EXTERNAL_NETWORK=192.168.204.0/24 - export EXTERNAL_IP=192.168.204.1/24 - - -************************* -Install stx-tools project -************************* - -Clone the stx-tools project into a working directory. - -:: - - git clone https://git.openstack.org/openstack/stx-tools.git - - -It is convenient to set up a shortcut to the deployment script -directory: - -:: - - SCRIPTS=$(pwd)/stx-tools/deployment/libvirt - - -If you created a configuration, load it from stxcloud.rc: - -:: - - source stxcloud.rc - - -**************************************** -Installing requirements and dependencies -**************************************** - -Install the required packages and configure QEMU. This only needs to be -done once per host. (NOTE: this script only knows about Ubuntu at this -time): - -:: - - $SCRIPTS/install_packages.sh - - -****************** -Disabling firewall -****************** - -Unload firewall and disable firewall on boot: - -:: - - sudo ufw disable - sudo ufw status - - -****************** -Configure networks -****************** - -Configure the network bridges using setup_network.sh before doing -anything else. It will create 4 bridges named stxbr1, stxbr2, stxbr3 and -stxbr4. Set the BRIDGE_INTERFACE environment variable if you need to -change stxbr to something unique. - -:: - - $SCRIPTS/setup_network.sh - - -The destroy_network.sh script does the reverse, and should not be used -lightly. It should also only be used after all of the VMs created below -have been destroyed. - -There is also a script cleanup_network.sh that will remove networking -configuration from libvirt. - -********************* -Configure controllers -********************* - -One script exists for building different StarlingX cloud configurations: -setup_configuration.sh. - -The script uses the cloud configuration with the -c option: - -- simplex -- duplex -- controllerstorage -- dedicatedstorage - -You need an ISO file for the installation, the script takes a file name -with the -i option: - -:: - - $SCRIPTS/setup_configuration.sh -c -i - - -And the setup will begin. The scripts create one or more VMs and start -the boot of the first controller, named oddly enough \``controller-0``. -If you have Xwindows available you will get virt-manager running. If -not, Ctrl-C out of that attempt if it doesn't return to a shell prompt. -Then connect to the serial console: - -:: - - virsh console controller-0 - - -Continue the usual StarlingX installation from this point forward. - -Tear down the VMs using destroy_configuration.sh. - -:: - - $SCRIPTS/destroy_configuration.sh -c - - --------- -Continue --------- - -Pick up the installation in one of the existing guides at the initializing -controller-0 step. - -- Standard controller - - - :doc:`StarlingX Cloud with Dedicated Storage Virtual Environment ` - - :doc:`StarlingX Cloud with Controller Storage Virtual Environment ` - -- All-in-one - - - :doc:`StarlingX Cloud Duplex Virtual Environment ` - - :doc:`StarlingX Cloud Simplex Virtual Environment ` diff --git a/doc/source/deploy_install_guides/r1_release/simplex.rst b/doc/source/deploy_install_guides/r1_release/simplex.rst deleted file mode 100644 index c751ac962..000000000 --- a/doc/source/deploy_install_guides/r1_release/simplex.rst +++ /dev/null @@ -1,748 +0,0 @@ -======================= -All-in-one Simplex R1.0 -======================= - -.. contents:: - :local: - :depth: 1 - -**NOTE:** The instructions to set up a StarlingX One Node Configuration -(AIO-SX) system with containerized openstack services in this guide -are under development. -For approved instructions, see the -`One Node Configuration wiki page `__. - ----------------------- -Deployment description ----------------------- - -The All-In-One Simplex (AIO-SX) deployment option provides all three cloud -functions (controller, compute, and storage) on a single physical server. With -these cloud functions, multiple application types can be deployed and -consolidated onto a single physical server. For example, with a AIO-SX -deployment you can do the following: - -- Consolidate legacy applications that must run standalone on a server by using - multiple virtual machines on a single physical server. -- Consolidate legacy applications that run on different operating systems or - different distributions of operating systems by using multiple virtual - machines on a single physical server. - -Only a small amount of cloud processing / storage power is required with an -All-In-One Simplex deployment. - -.. figure:: figures/starlingx-deployment-options-simplex.png - :scale: 50% - :alt: All-In-One Simplex deployment configuration - - *All-In-One Simplex deployment configuration* - -An All-In-One Simplex deployment provides no protection against an overall -server hardware fault. Protection against overall server hardware faults is -either not required, or done at a higher level. Hardware component protection -could be enabled if, for example, an HW RAID or 2x Port LAG is used in the -deployment. - --------------------------------------- -Preparing an All-In-One Simplex server --------------------------------------- - -********** -Bare metal -********** - -Required Server: - -- Combined server (controller + compute): 1 - -^^^^^^^^^^^^^^^^^^^^^ -Hardware requirements -^^^^^^^^^^^^^^^^^^^^^ - -The recommended minimum requirements for the physical servers where -All-In-One Simplex is deployed are as follows: - -- Minimum processor: - - - Typical hardware form factor: - - - Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) 8 cores/socket - - Low cost / low power hardware form factor - - - Single-CPU Intel Xeon D-15xx family, 8 cores - -- Memory: 64 GB -- BIOS: - - - Hyper-Threading technology: Enabled - - Virtualization technology: Enabled - - VT for directed I/O: Enabled - - CPU power and performance policy: Performance - - CPU C state control: Disabled - - Plug & play BMC detection: Disabled - -- Primary disk: - - - 500 GB SSD or NVMe - -- Additional disks: - - - Zero or more 500 GB disks (min. 10K RPM) - -- Network ports - - **NOTE:** All-In-One Simplex configuration requires one or more data ports. - This configuration does not require a management port. - - - OAM: 10GE - - Data: n x 10GE - -******************* -Virtual environment -******************* - -Run the libvirt QEMU setup scripts to set up virtualized OAM and -management networks: - -:: - - $ bash setup_network.sh - -Building XML for definition of virtual servers: - -:: - - $ bash setup_configuration.sh -c simplex -i - -The default XML server definition created by the previous script is as follows: - -- simplex-controller-0 - -^^^^^^^^^^^^^^^^^^^^^^^^^ -Power up a virtual server -^^^^^^^^^^^^^^^^^^^^^^^^^ - -To power up the virtual server, run the following command: - -:: - - $ sudo virsh start - -Here is an example: - -:: - - $ sudo virsh start simplex-controller-0 - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Access a virtual server console -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The XML for virtual servers in stx-tools repo, deployment/libvirt, -provides both graphical and text consoles. -Follow these steps to access a virtual server console: - -#. Access the graphical console in virt-manager by right-clicking on the - domain (i.e. the server) and selecting "Open". - -#. Access the textual console using the command "virsh console $DOMAIN", - where DOMAIN is the name of the server shown in virsh. - -#. When booting controller-0 for the first time, both the serial and - graphical consoles present the initial configuration menu for the - cluster. You can select the serial or graphical console for controller-0. - However, for the other nodes, you can only use the serial console - regardless of the selected option. - -#. Open the graphic console on all servers before powering them on to - observe the boot device selection and PXI boot progress. Run the "virsh - console $DOMAIN" command promptly after powering up to see the initial boot - sequence that follows the boot device selection. Only a few seconds exist - during which you can see the sequence. - ------------------------------- -Installing the controller host ------------------------------- - -Installing controller-0 involves initializing a host with software and -then applying a bootstrap configuration from the command line. The -configured bootstrapped host becomes controller-0. - -Following is the general procedure: - -#. Be sure the StarlingX ISO is on a USB device and it is plugged into - the USB port of the server that will be controller-0 and then - power on the server. - -#. Configure the controller using the config_controller script. - -************************* -Initializing controller-0 -************************* - -This section describes how to initialize StarlingX in host controller-0. -Except where noted, you must execute all the commands from a console of -the host. - -#. Be sure the StarlingX ISO is on a USB device and it is plugged into - the USB port of the server that will be controller-0. - -#. Power on the server. - -#. Wait for the console to show the StarlingX ISO booting options: - - - **All-in-one Controller Configuration** - - - When the installer is loaded and the installer welcome screen - appears in the controller-0 host, select "All-in-one Controller Configuration" - for the type of installation. - - - **Graphical Console** - - - Select the "Graphical Console" as the console to use during - installation. - - - **Standard Security Boot Profile** - - - Select "Standard Security Boot Profile" as the Security Profile. - -#. Monitor the initialization. When the installation is complete, a reboot is initiated - on the controller-0 host. The GNU GRUB screen briefly displays and then - boots automatically into the StarlingX image. - -#. Log into controller-0 as user wrsroot and use wrsroot as the password. The - first time you log in as wrsroot, you are required to change your - password. Enter the current password (i.e. wrsroot): - - :: - - Changing password for wrsroot. - (current) UNIX Password: - -#. Enter a new password for the wrsroot account: - - :: - - New password: - -#. Enter the new password again to confirm it: - - :: - - Retype new password: - -#. The controller-0 is initialized with StarlingX and is ready for configuration. - - -************************ -Configuring controller-0 -************************ - -This section describes how to interactively configure controller-0 -to bootstrap the system with minimal critical data. -Except where noted, you must execute all commands from the console -of the active controller (i.e. controller-0). - -When run interactively, the config_controller script presents a series -of prompts for initial configuration of StarlingX: - -- For the virtual environment, you can accept all the default values - immediately after "system date and time". -- For a physical deployment, answer the bootstrap configuration - questions with answers applicable to your particular physical setup. - -The script configures the first controller in the StarlingX -cluster as controller-0. The prompts are grouped by configuration -area. - -Follow this procedure to interactively configure controller-0: - -#. Start the script with no parameters: - - :: - - controller-0:~$ sudo config_controller - System Configuration - ================ - Enter ! at any prompt to abort... - ... - -#. Select [y] for System date and time: - - :: - - System date and time: - ----------------------------- - - Is the current date and time correct? [y/N]: y - -#. For System mode choose "simplex": - - :: - - ... - 1) duplex-direct: two node-redundant configuration. Management and - infrastructure networks are directly connected to peer ports - 2) duplex - two node redundant configuration - 3) simplex - single node non-redundant configuration - System mode [duplex-direct]: 3 - -#. After System date and time and System mode: - - :: - - Applying configuration (this will take several minutes): - - 01/08: Creating bootstrap configuration ... DONE - 02/08: Applying bootstrap manifest ... DONE - 03/08: Persisting local configuration ... DONE - 04/08: Populating initial system inventory ... DONE - 05:08: Creating system configuration ... DONE - 06:08: Applying controller manifest ... DONE - 07:08: Finalize controller configuration ... DONE - 08:08: Waiting for service activation ... DONE - - Configuration was applied - - Please complete any out of service commissioning steps with system - commands and unlock controller to proceed. - -#. After config_controller bootstrap configuration, REST API, CLI and - Horizon interfaces are enabled on the controller-0 OAM IP address. The - remaining installation instructions use the CLI. - --------------------------------- -Provisioning the controller host --------------------------------- - -On controller-0, acquire Keystone administrative privileges: - -:: - - controller-0:~$ source /etc/nova/openrc - -********************************************* -Configuring provider networks at installation -********************************************* - -Set up one provider network of the vlan type and name it providernet-a: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ neutron providernet-create providernet-a --type=vlan - [wrsroot@controller-0 ~(keystone_admin)]$ neutron providernet-range-create --name providernet-a-range1 --range 100-400 providernet-a - -***************************************** -Providing data interfaces on controller-0 -***************************************** - -Follow these steps: - -#. List all interfaces: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-if-list -a controller-0 - +--------------------------------------+---------+----------+...+------+--------------+------+---------+------------+.. - | uuid | name | class |...| vlan | ports | uses | used by | attributes |.. - | | | |...| id | | i/f | i/f | |.. - +--------------------------------------+----------+---------+...+------+--------------+------+---------+------------+.. - | 49fd8938-e76f-49f1-879e-83c431a9f1af | enp0s3 | platform |...| None | [u'enp0s3'] | [] | [] | MTU=1500 |.. - | 8957bb2c-fec3-4e5d-b4ed-78071f9f781c | eth1000 | None |...| None | [u'eth1000'] | [] | [] | MTU=1500 |.. - | bf6f4cad-1022-4dd7-962b-4d7c47d16d54 | eth1001 | None |...| None | [u'eth1001'] | [] | [] | MTU=1500 |.. - | f59b9469-7702-4b46-bad5-683b95f0a1cb | enp0s8 | platform |...| None | [u'enp0s8'] | [] | [] | MTU=1500 |.. - +--------------------------------------+---------+----------+...+------+--------------+------+---------+------------+.. - -#. Configure the data interfaces: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-if-modify -c data controller-0 eth1000 -p providernet-a - +------------------+--------------------------------------+ - | Property | Value | - +------------------+--------------------------------------+ - | ifname | eth1000 | - | iftype | ethernet | - | ports | [u'eth1000'] | - | providernetworks | providernet-a | - | imac | 08:00:27:c4:ad:3e | - | imtu | 1500 | - | ifclass | data | - | aemode | None | - | schedpolicy | None | - | txhashpolicy | None | - | uuid | 8957bb2c-fec3-4e5d-b4ed-78071f9f781c | - | ihost_uuid | 9c332b27-6f22-433b-bf51-396371ac4608 | - | vlan_id | None | - | uses | [] | - | used_by | [] | - | created_at | 2018-08-28T12:50:51.820151+00:00 | - | updated_at | 2018-08-28T14:46:18.333109+00:00 | - | sriov_numvfs | 0 | - | ipv4_mode | disabled | - | ipv6_mode | disabled | - | accelerated | [True] | - +------------------+--------------------------------------+ - -************************************* -Configuring Cinder on controller disk -************************************* - -Follow these steps: - -#. Review the available disk space and capacity and obtain the uuid of the - physical disk: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-list controller-0 - +--------------------------------------+-----------+---------+---------+---------+------------+... - | uuid | device_no | device_ | device_ | size_mi | available_ |... - | | de | num | type | b | mib |... - +--------------------------------------+-----------+---------+---------+---------+------------+... - | 6b42c9dc-f7c0-42f1-a410-6576f5f069f1 | /dev/sda | 2048 | HDD | 600000 | 434072 |... - | | | | | | |... - | | | | | | |... - | 534352d8-fec2-4ca5-bda7-0e0abe5a8e17 | /dev/sdb | 2064 | HDD | 16240 | 16237 |... - | | | | | | |... - | | | | | | |... - | 146195b2-f3d7-42f9-935d-057a53736929 | /dev/sdc | 2080 | HDD | 16240 | 16237 |... - | | | | | | |... - | | | | | | |... - +--------------------------------------+-----------+---------+---------+---------+------------+... - -#. Create the 'cinder-volumes' local volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-lvg-add controller-0 cinder-volumes - +-----------------+--------------------------------------+ - | lvm_vg_name | cinder-volumes | - | vg_state | adding | - | uuid | 61cb5cd2-171e-4ef7-8228-915d3560cdc3 | - | ihost_uuid | 9c332b27-6f22-433b-bf51-396371ac4608 | - | lvm_vg_access | None | - | lvm_max_lv | 0 | - | lvm_cur_lv | 0 | - | lvm_max_pv | 0 | - | lvm_cur_pv | 0 | - | lvm_vg_size | 0.00 | - | lvm_vg_total_pe | 0 | - | lvm_vg_free_pe | 0 | - | created_at | 2018-08-28T13:45:20.218905+00:00 | - | updated_at | None | - | parameters | {u'lvm_type': u'thin'} | - +-----------------+--------------------------------------+ - -#. Create a disk partition to add to the volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-add controller-0 534352d8-fec2-4ca5-bda7-0e0abe5a8e17 16237 -t lvm_phys_vol - +-------------+--------------------------------------------------+ - | Property | Value | - +-------------+--------------------------------------------------+ - | device_path | /dev/disk/by-path/pci-0000:00:0d.0-ata-2.0-part1 | - | device_node | /dev/sdb1 | - | type_guid | ba5eba11-0000-1111-2222-000000000001 | - | type_name | None | - | start_mib | None | - | end_mib | None | - | size_mib | 16237 | - | uuid | 0494615f-bd79-4490-84b9-dcebbe5f377a | - | ihost_uuid | 9c332b27-6f22-433b-bf51-396371ac4608 | - | idisk_uuid | 534352d8-fec2-4ca5-bda7-0e0abe5a8e17 | - | ipv_uuid | None | - | status | Creating | - | created_at | 2018-08-28T13:45:48.512226+00:00 | - | updated_at | None | - +-------------+--------------------------------------------------+ - -#. Wait for the new partition to be created (i.e. status=Ready): - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-list controller-0 --disk 534352d8-fec2-4ca5-bda7-0e0abe5a8e17 - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - | uuid |...| device_nod |...| type_name | size_mib | status | - | |...| e |...| | | | - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - | 0494615f-bd79-4490-84b9-dcebbe5f377a |...| /dev/sdb1 |...| LVM Physical Volume | 16237 | Ready | - | |...| |...| | | | - | |...| |...| | | | - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - -#. Add the partition to the volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-pv-add controller-0 cinder-volumes 0494615f-bd79-4490-84b9-dcebbe5f377a - +--------------------------+--------------------------------------------------+ - | Property | Value | - +--------------------------+--------------------------------------------------+ - | uuid | 9a0ad568-0ace-4d57-9e03-e7a63f609cf2 | - | pv_state | adding | - | pv_type | partition | - | disk_or_part_uuid | 0494615f-bd79-4490-84b9-dcebbe5f377a | - | disk_or_part_device_node | /dev/sdb1 | - | disk_or_part_device_path | /dev/disk/by-path/pci-0000:00:0d.0-ata-2.0-part1 | - | lvm_pv_name | /dev/sdb1 | - | lvm_vg_name | cinder-volumes | - | lvm_pv_uuid | None | - | lvm_pv_size | 0 | - | lvm_pe_total | 0 | - | lvm_pe_alloced | 0 | - | ihost_uuid | 9c332b27-6f22-433b-bf51-396371ac4608 | - | created_at | 2018-08-28T13:47:39.450763+00:00 | - | updated_at | None | - +--------------------------+--------------------------------------------------+ - -********************************************* -Adding an LVM storage backend at installation -********************************************* - -Follow these steps: - -#. Ensure requirements are met to add LVM storage: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system storage-backend-add lvm -s cinder - - WARNING : THIS OPERATION IS NOT REVERSIBLE AND CANNOT BE CANCELLED. - - By confirming this operation, the LVM backend will be created. - - Please refer to the system admin guide for minimum spec for LVM - storage. Set the 'confirmed' field to execute this operation - for the lvm backend. - -#. Add the LVM storage backend: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system storage-backend-add lvm -s cinder --confirmed - - System configuration has changed. - Please follow the administrator guide to complete configuring the system. - - +--------------------------------------+------------+---------+-------------+...+----------+--------------+ - | uuid | name | backend | state |...| services | capabilities | - +--------------------------------------+------------+---------+-------------+...+----------+--------------+ - | 6d750a68-115a-4c26-adf4-58d6e358a00d | file-store | file | configured |...| glance | {} | - | e2697426-2d79-4a83-beb7-2eafa9ceaee5 | lvm-store | lvm | configuring |...| cinder | {} | - +--------------------------------------+------------+---------+-------------+...+----------+--------------+ - -#. Wait for the LVM storage backend to be configured (i.e. state=configured): - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system storage-backend-list - +--------------------------------------+------------+---------+------------+------+----------+--------------+ - | uuid | name | backend | state | task | services | capabilities | - +--------------------------------------+------------+---------+------------+------+----------+--------------+ - | 6d750a68-115a-4c26-adf4-58d6e358a00d | file-store | file | configured | None | glance | {} | - | e2697426-2d79-4a83-beb7-2eafa9ceaee5 | lvm-store | lvm | configured | None | cinder | {} | - +--------------------------------------+------------+---------+------------+------+----------+--------------+ - -*********************************************** -Configuring VM local storage on controller disk -*********************************************** - -Follow these steps: - -#. Review the available disk space and capacity and obtain the uuid of the - physical disk: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-list controller-0 - +--------------------------------------+-----------+---------+---------+---------+------------+... - | uuid | device_no | device_ | device_ | size_mi | available_ |... - | | de | num | type | b | mib |... - +--------------------------------------+-----------+---------+---------+---------+------------+... - | 6b42c9dc-f7c0-42f1-a410-6576f5f069f1 | /dev/sda | 2048 | HDD | 600000 | 434072 |... - | | | | | | |... - | | | | | | |... - | 534352d8-fec2-4ca5-bda7-0e0abe5a8e17 | /dev/sdb | 2064 | HDD | 16240 | 0 |... - | | | | | | |... - | | | | | | |... - | 146195b2-f3d7-42f9-935d-057a53736929 | /dev/sdc | 2080 | HDD | 16240 | 16237 |... - | | | | | | |... - | | | | | | |... - +--------------------------------------+-----------+---------+---------+---------+------------+... - -#. Create the 'nova-local' volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-lvg-add controller-0 nova-local - +-----------------+-------------------------------------------------------------------+ - | Property | Value | - +-----------------+-------------------------------------------------------------------+ - | lvm_vg_name | nova-local | - | vg_state | adding | - | uuid | 517d313e-8aa0-4b4d-92e6-774b9085f336 | - | ihost_uuid | 9c332b27-6f22-433b-bf51-396371ac4608 | - | lvm_vg_access | None | - | lvm_max_lv | 0 | - | lvm_cur_lv | 0 | - | lvm_max_pv | 0 | - | lvm_cur_pv | 0 | - | lvm_vg_size | 0.00 | - | lvm_vg_total_pe | 0 | - | lvm_vg_free_pe | 0 | - | created_at | 2018-08-28T14:02:58.486716+00:00 | - | updated_at | None | - | parameters | {u'concurrent_disk_operations': 2, u'instance_backing': u'image'} | - +-----------------+-------------------------------------------------------------------+ - -#. Create a disk partition to add to the volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-add controller-0 146195b2-f3d7-42f9-935d-057a53736929 16237 -t lvm_phys_vol - +-------------+--------------------------------------------------+ - | Property | Value | - +-------------+--------------------------------------------------+ - | device_path | /dev/disk/by-path/pci-0000:00:0d.0-ata-3.0-part1 | - | device_node | /dev/sdc1 | - | type_guid | ba5eba11-0000-1111-2222-000000000001 | - | type_name | None | - | start_mib | None | - | end_mib | None | - | size_mib | 16237 | - | uuid | 009ce3b1-ed07-46e9-9560-9d2371676748 | - | ihost_uuid | 9c332b27-6f22-433b-bf51-396371ac4608 | - | idisk_uuid | 146195b2-f3d7-42f9-935d-057a53736929 | - | ipv_uuid | None | - | status | Creating | - | created_at | 2018-08-28T14:04:29.714030+00:00 | - | updated_at | None | - +-------------+--------------------------------------------------+ - -#. Wait for the new partition to be created (i.e. status=Ready): - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-disk-partition-list controller-0 --disk 146195b2-f3d7-42f9-935d-057a53736929 - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - | uuid |...| device_nod |...| type_name | size_mib | status | - | |...| e |...| | | | - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - | 009ce3b1-ed07-46e9-9560-9d2371676748 |...| /dev/sdc1 |...| LVM Physical Volume | 16237 | Ready | - | |...| |...| | | | - | |...| |...| | | | - +--------------------------------------+...+------------+...+---------------------+----------+--------+ - -#. Add the partition to the volume group: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-pv-add controller-0 nova-local 009ce3b1-ed07-46e9-9560-9d2371676748 - +--------------------------+--------------------------------------------------+ - | Property | Value | - +--------------------------+--------------------------------------------------+ - | uuid | 830c9dc8-c71a-4cb2-83be-c4d955ef4f6b | - | pv_state | adding | - | pv_type | partition | - | disk_or_part_uuid | 009ce3b1-ed07-46e9-9560-9d2371676748 | - | disk_or_part_device_node | /dev/sdc1 | - | disk_or_part_device_path | /dev/disk/by-path/pci-0000:00:0d.0-ata-3.0-part1 | - | lvm_pv_name | /dev/sdc1 | - | lvm_vg_name | nova-local | - | lvm_pv_uuid | None | - | lvm_pv_size | 0 | - | lvm_pe_total | 0 | - | lvm_pe_alloced | 0 | - | ihost_uuid | 9c332b27-6f22-433b-bf51-396371ac4608 | - | created_at | 2018-08-28T14:06:05.705546+00:00 | - | updated_at | None | - +--------------------------+--------------------------------------------------+ - -********************** -Unlocking controller-0 -********************** - -You must unlock controller-0 so that you can use it to install -controller-1. Use the system host-unlock command: - -:: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-unlock controller-0 - -The host reboots. During the reboot, the command line is -unavailable and any ssh connections are dropped. To monitor the -progress of the reboot, use the controller-0 console. - -**************************************** -Verifying the controller-0 configuration -**************************************** - -Follow these steps: - -#. On controller-0, acquire Keystone administrative privileges: - - :: - - controller-0:~$ source /etc/nova/openrc - -#. Verify that the controller-0 services are running: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system service-list - +-----+-------------------------------+--------------+----------------+ - | id | service_name | hostname | state | - +-----+-------------------------------+--------------+----------------+ - ... - | 1 | oam-ip | controller-0 | enabled-active | - | 2 | management-ip | controller-0 | enabled-active | - ... - +-----+-------------------------------+--------------+----------------+ - -#. Verify that controller-0 has controller and compute subfunctions: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-show 1 | grep subfunctions - | subfunctions | controller,compute | - -#. Verify that controller-0 is unlocked, enabled, and available: - - :: - - [wrsroot@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - +----+--------------+-------------+----------------+-------------+--------------+ - -***************** -System alarm list -***************** - -When all nodes are unlocked, enabled, and available, check 'fm alarm-list' for -issues. - -Your StarlingX deployment is now up and running with one controller with Cinder -storage and all OpenStack services up and running. You can now proceed with -standard OpenStack APIs, CLIs and/or Horizon to load Glance images, configure -Nova Flavors, configure Neutron networks, and launch Nova virtual machines. - ----------------------- -Deployment terminology ----------------------- - -.. include:: deployment_terminology.rst - :start-after: incl-simplex-deployment-terminology: - :end-before: incl-simplex-deployment-terminology-end: - -.. include:: deployment_terminology.rst - :start-after: incl-standard-controller-deployment-terminology: - :end-before: incl-standard-controller-deployment-terminology-end: - -.. include:: deployment_terminology.rst - :start-after: incl-common-deployment-terminology: - :end-before: incl-common-deployment-terminology-end: diff --git a/doc/source/deploy_install_guides/r2_release/ansible_bootstrap_configs.rst b/doc/source/deploy_install_guides/r2_release/ansible_bootstrap_configs.rst deleted file mode 100644 index a57095f6f..000000000 --- a/doc/source/deploy_install_guides/r2_release/ansible_bootstrap_configs.rst +++ /dev/null @@ -1,246 +0,0 @@ -================================ -Ansible Bootstrap Configurations -================================ - -This section describes additional Ansible bootstrap configurations for advanced -Ansible bootstrap scenarios. - -.. contents:: - :local: - :depth: 1 - ----- -IPv6 ----- - -If you are using IPv6, provide IPv6 configuration overrides for the Ansible -bootstrap playbook. Note that all addressing, except pxeboot_subnet, should be -updated to IPv6 addressing. - -Example IPv6 override values are shown below: - -:: - - dns_servers: - ‐ 2001:4860:4860::8888 - ‐ 2001:4860:4860::8844 - pxeboot_subnet: 169.254.202.0/24 - management_subnet: 2001:db8:2::/64 - cluster_host_subnet: 2001:db8:3::/64 - cluster_pod_subnet: 2001:db8:4::/64 - cluster_service_subnet: 2001:db8:4::/112 - external_oam_subnet: 2001:db8:1::/64 - external_oam_gateway_address: 2001:db8::1 - external_oam_floating_address: 2001:db8::2 - external_oam_node_0_address: 2001:db8::3 - external_oam_node_1_address: 2001:db8::4 - management_multicast_subnet: ff08::1:1:0/124 - -.. note:: - - The `external_oam_node_0_address`, and `external_oam_node_1_address` parameters - are not required for the AIO‐SX installation. - ----------------- -Private registry ----------------- - -To bootstrap StarlingX requires pulling container images for multiple system -services. By default these container images are pulled from public registries: -k8s.gcr.io, gcr.io, quay.io, and docker.io. - -It may be required (or desired) to copy the container images to a private -registry and pull the images from the private registry (instead of the public -registries) as part of the StarlingX bootstrap. For example, a private registry -would be required if a StarlingX system was deployed in an air-gapped network -environment. - -Use the `docker_registries` structure in the bootstrap overrides file to specify -alternate registry(s) for the public registries from which container images are -pulled. These alternate registries are used during the bootstrapping of -controller-0, and on :command:`system application-apply` of application packages. - -The `docker_registries` structure is a map of public registries and the -alternate registry values for each public registry. For each public registry the -key is a fully scoped registry name of a public registry (for example "k8s.gcr.io") -and the alternate registry URL and username/password (if authenticated). - -url - The fully scoped registry name (and optionally namespace/) for the alternate - registry location where the images associated with this public registry - should now be pulled from. - - Valid formats for the `url` value are: - - * Domain. For example: - - :: - example.domain - - * Domain with port. For example: - - :: - example.domain:5000 - - * IPv4 address. For example: - - :: - 1.2.3.4 - - * IPv4 address with port. For example: - - :: - 1.2.3.4:5000 - - * IPv6 address. For example: - - :: - FD01::0100 - - * IPv6 address with port. For example: - - :: - [FD01::0100]:5000 - -username - The username for logging into the alternate registry, if authenticated. - -password - The password for logging into the alternate registry, if authenticated. - - -Additional configuration options in the `docker_registries` structure are: - -unified - A special public registry key which, if defined, will specify that images - from all public registries should be retrieved from this single source. - Alternate registry values, if specified, are ignored. The `unified` key - supports the same set of alternate registry values of `url`, `username`, and - `password`. - -is_secure_registry - Specifies whether the registry(s) supports HTTPS (secure) or HTTP (not secure). - Applies to all alternate registries. A boolean value. The default value is - True (secure, HTTPS). - - -If an alternate registry is specified to be secure (using HTTPS), the certificate -used by the registry may not be signed by a well-known Certificate Authority (CA). -This results in the :command:`docker pull` of images from this registry to fail. -Use the `ssl_ca_cert` override to specify the public certificate of the CA that -signed the alternate registry’s certificate. This will add the CA as a trusted -CA to the StarlingX system. - -ssl_ca_cert - The `ssl_ca_cert` value is the absolute path of the certificate file. The - certificate must be in PEM format and the file may contain a single CA - certificate or multiple CA certificates in a bundle. - - -The following example specifies a single alternate registry from which to -bootstrap StarlingX, where the images of the public registries have been -copied to the single alternate registry. It additionally defines an alternate -registry certificate: - -:: - - docker_registries: - k8s.gcr.io: - url: - gcr.io: - url: - quay.io: - url: - docker.io: - url: - unified: - url: my.registry.io - username: myreguser - password: myregP@ssw0rd - is_secure_registry: True - - ssl_ca_cert: /path/to/ssl_ca_cert_file - ------------- -Docker proxy ------------- - -If the StarlingX OAM interface or network is behind a http/https proxy, relative -to the Docker registries used by StarlingX or applications running on StarlingX, -then Docker within StarlingX must be configured to use these http/https proxies. - -Use the following configuration overrides to configure your Docker proxy settings. - -docker_http_proxy - Specify the HTTP proxy URL to use. For example: - - :: - - docker_http_proxy: http://my.proxy.com:1080 - -docker_https_proxy - Specify the HTTPS proxy URL to use. For example: - - :: - - docker_https_proxy: https://my.proxy.com:1443 - -docker_no_proxy - A no-proxy address list can be provided for registries not on the other side - of the proxies. This list will be added to the default no-proxy list derived - from localhost, loopback, management, and OAM floating addresses at run time. - Each address in the no-proxy list must neither contain a wildcard nor have - subnet format. For example: - - :: - - docker_no_proxy: - - 1.2.3.4 - - 5.6.7.8 - -------------------------------- -K8S Root CA Certificate and Key -------------------------------- - -By default the K8S Root CA Certificate and Key are auto-generated and result in -the use of self-signed certificates for the Kubernetes API server. In the case -where self-signed certificates are not acceptable, use the bootstrap override -values `k8s_root_ca_cert` and `k8s_root_ca_key` to specify the certificate and -key for the Kubernetes root CA. - -k8s_root_ca_cert - Specifies the certificate for the Kubernetes root CA. The `k8s_root_ca_cert` - value is the absolute path of the certificate file. The certificate must be - in PEM format and the value must be provided as part of a pair with - `k8s_root_ca_key`. The playbook will not proceed if only one value is provided. - -k8s_root_ca_key - Specifies the key for the Kubernetes root CA. The `k8s_root_ca_key` - value is the absolute path of the certificate file. The certificate must be - in PEM format and the value must be provided as part of a pair with - `k8s_root_ca_cert`. The playbook will not proceed if only one value is provided. - -.. important:: - - The default length for the generated Kubernetes root CA certificate is 10 - years. Replacing the root CA certificate is an involved process so the custom - certificate expiry should be as long as possible. We recommend ensuring root - CA certificate has an expiry of at least 5-10 years. - -The administrator can also provide values to add to the Kubernetes API server -certificate Subject Alternative Name list using the 'apiserver_cert_sans` -override parameter. - -apiserver_cert_sans - Specifies a list of Subject Alternative Name entries that will be added to the - Kubernetes API server certificate. Each entry in the list must be an IP address - or domain name. For example: - - :: - - apiserver_cert_sans: - - hostname.domain - - 198.51.100.75 - -StarlingX automatically updates this parameter to include IP records for the OAM -floating IP and both OAM unit IP addresses. diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/aio_duplex.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/aio_duplex.rst deleted file mode 100644 index 7d85e038f..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/aio_duplex.rst +++ /dev/null @@ -1,26 +0,0 @@ -============================================== -Bare metal All-in-one Duplex Installation R2.0 -============================================== - --------- -Overview --------- - -.. include:: ../desc_aio_duplex.txt - -The bare metal AIO-DX deployment configuration may be extended with up to four -worker/compute nodes (not shown in the diagram). Installation instructions for -these additional nodes are described in :doc:`aio_duplex_extend`. - -.. include:: ../ipv6_note.txt - ------------- -Installation ------------- - -.. toctree:: - :maxdepth: 1 - - aio_duplex_hardware - aio_duplex_install_kubernetes - aio_duplex_extend \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/aio_duplex_extend.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/aio_duplex_extend.rst deleted file mode 100644 index b42411f1c..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/aio_duplex_extend.rst +++ /dev/null @@ -1,192 +0,0 @@ -================================================ -Extend Capacity with Worker and/or Compute Nodes -================================================ - -This section describes the steps to extend capacity with worker and/or compute -nodes on a **StarlingX R2.0 bare metal All-in-one Duplex** deployment -configuration. - -.. contents:: - :local: - :depth: 1 - ---------------------------------- -Install software on compute nodes ---------------------------------- - -#. Power on the compute servers and force them to network boot with the - appropriate BIOS boot options for your particular server. - -#. As the compute servers boot, a message appears on their console instructing - you to configure the personality of the node. - -#. On the console of controller-0, list hosts to see newly discovered compute - hosts (hostname=None): - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-0 | controller | unlocked | enabled | available | - | 3 | None | None | locked | disabled | offline | - | 4 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. Using the host id, set the personality of this host to 'controller': - - :: - - system host-update 3 personality=worker hostname=compute-0 - system host-update 4 personality=worker hostname=compute-1 - - This initiates the install of software on compute nodes. - This can take 5-10 minutes, depending on the performance of the host machine. - -#. Wait for the install of software on the computes to complete, the computes to - reboot and to both show as locked/disabled/online in 'system host-list'. - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | unlocked | enabled | available | - | 3 | compute-0 | compute | locked | disabled | online | - | 4 | compute-1 | compute | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - ------------------------ -Configure compute nodes ------------------------ - -#. Assign the cluster-host network to the MGMT interface for the compute nodes: - - (Note that the MGMT interfaces are partially set up automatically by the - network install procedure.) - - :: - - for COMPUTE in compute-0 compute-1; do - system interface-network-assign $COMPUTE mgmt0 cluster-host - done - -#. Configure data interfaces for compute nodes. Use the DATA port names, for - example eth0, that are applicable to your deployment environment. - - .. important:: - - This step is **required** for OpenStack. - - This step is optional for Kubernetes: Do this step if using SRIOV network - attachments in hosted application containers. - - For Kubernetes SRIOV network attachments: - - * Configure SRIOV device plug in: - - :: - - system host-label-assign controller-1 sriovdp=enabled - - * If planning on running DPDK in containers on this host, configure the number - of 1G Huge pages required on both NUMA nodes: - - :: - - system host-memory-modify controller-1 0 -1G 100 - system host-memory-modify controller-1 1 -1G 100 - - For both Kubernetes and OpenStack: - - :: - - DATA0IF= - DATA1IF= - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - - # configure the datanetworks in sysinv, prior to referencing it - # in the ``system host-if-modify`` command'. - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - for COMPUTE in compute-0 compute-1; do - echo "Configuring interface for: $COMPUTE" - set -ex - system host-port-list ${COMPUTE} --nowrap > ${SPL} - system host-if-list -a ${COMPUTE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - system host-if-modify -m 1500 -n data0 -c data ${COMPUTE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${COMPUTE} ${DATA1IFUUID} - system interface-datanetwork-assign ${COMPUTE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${COMPUTE} ${DATA1IFUUID} ${PHYSNET1} - set +ex - done - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to the compute nodes in - support of installing the stx-openstack manifest and helm-charts later. - - :: - - for NODE in compute-0 compute-1; do - system host-label-assign $NODE openstack-compute-node=enabled - system host-label-assign $NODE openvswitch=enabled - system host-label-assign $NODE sriov=enabled - done - -#. **For OpenStack only:** Setup disk partition for nova-local volume group, - needed for stx-openstack nova ephemeral disks. - - :: - - for COMPUTE in compute-0 compute-1; do - echo "Configuring Nova local for: $COMPUTE" - ROOT_DISK=$(system host-show ${COMPUTE} | grep rootfs | awk '{print $4}') - ROOT_DISK_UUID=$(system host-disk-list ${COMPUTE} --nowrap | grep ${ROOT_DISK} | awk '{print $2}') - PARTITION_SIZE=10 - NOVA_PARTITION=$(system host-disk-partition-add -t lvm_phys_vol ${COMPUTE} ${ROOT_DISK_UUID} ${PARTITION_SIZE}) - NOVA_PARTITION_UUID=$(echo ${NOVA_PARTITION} | grep -ow "| uuid | [a-z0-9\-]* |" | awk '{print $4}') - system host-lvg-add ${COMPUTE} nova-local - system host-pv-add ${COMPUTE} nova-local ${NOVA_PARTITION_UUID} - done - - --------------------- -Unlock compute nodes --------------------- - -Unlock compute nodes in order to bring them into service: - -:: - - for COMPUTE in compute-0 compute-1; do - system host-unlock $COMPUTE - done - -The compute nodes will reboot to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host -machine. - diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/aio_duplex_hardware.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/aio_duplex_hardware.rst deleted file mode 100644 index b8f55d119..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/aio_duplex_hardware.rst +++ /dev/null @@ -1,58 +0,0 @@ -===================== -Hardware Requirements -===================== - -This section describes the hardware requirements and server preparation for a -**StarlingX R2.0 bare metal All-in-one Duplex** deployment configuration. - -.. contents:: - :local: - :depth: 1 - ------------------------------ -Minimum hardware requirements ------------------------------ - -The recommended minimum hardware requirements for bare metal servers for various -host types are: - -+-------------------------+-----------------------------------------------------------+ -| Minimum Requirement | All-in-one Controller Node | -+=========================+===========================================================+ -| Number of servers | 2 | -+-------------------------+-----------------------------------------------------------+ -| Minimum processor class | - Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) | -| | 8 cores/socket | -| | | -| | or | -| | | -| | - Single-CPU Intel® Xeon® D-15xx family, 8 cores | -| | (low-power/low-cost option) | -+-------------------------+-----------------------------------------------------------+ -| Minimum memory | 64 GB | -+-------------------------+-----------------------------------------------------------+ -| Primary disk | 500 GB SSD or NVMe (see :doc:`../../nvme_config`) | -+-------------------------+-----------------------------------------------------------+ -| Additional disks | - 1 or more 500 GB (min. 10K RPM) for Ceph OSD | -| | - Recommended, but not required: 1 or more SSDs or NVMe | -| | drives for Ceph journals (min. 1024 MiB per OSD journal)| -| | - For OpenStack, recommend 1 or more 500 GB (min. 10K RPM)| -| | for VM local ephemeral storage | -+-------------------------+-----------------------------------------------------------+ -| Minimum network ports | - Mgmt/Cluster: 1x10GE | -| | - OAM: 1x1GE | -| | - Data: 1 or more x 10GE | -+-------------------------+-----------------------------------------------------------+ -| BIOS settings | - Hyper-Threading technology enabled | -| | - Virtualization technology enabled | -| | - VT for directed I/O enabled | -| | - CPU power and performance policy set to performance | -| | - CPU C state control disabled | -| | - Plug & play BMC detection disabled | -+-------------------------+-----------------------------------------------------------+ - --------------------------- -Prepare bare metal servers --------------------------- - -.. include:: prep_servers.txt \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/aio_duplex_install_kubernetes.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/aio_duplex_install_kubernetes.rst deleted file mode 100644 index c4f0f2bc6..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/aio_duplex_install_kubernetes.rst +++ /dev/null @@ -1,435 +0,0 @@ -================================================= -Install StarlingX Kubernetes on Bare Metal AIO-DX -================================================= - -This section describes the steps to install the StarlingX Kubernetes platform -on a **StarlingX R2.0 bare metal All-in-one Duplex** deployment configuration. - -.. contents:: - :local: - :depth: 1 - ---------------------- -Create a bootable USB ---------------------- - -Refer to :doc:`/deploy_install_guides/bootable_usb` for instructions on how to -create a bootable USB with the StarlingX ISO on your system. - --------------------------------- -Install software on controller-0 --------------------------------- - -.. include:: aio_simplex_install_kubernetes.rst - :start-after: incl-install-software-controller-0-aio-simplex-start: - :end-before: incl-install-software-controller-0-aio-simplex-end: - --------------------------------- -Bootstrap system on controller-0 --------------------------------- - -#. Login using the username / password of "sysadmin" / "sysadmin". - When logging in for the first time, you will be forced to change the password. - - :: - - Login: sysadmin - Password: - Changing password for sysadmin. - (current) UNIX Password: sysadmin - New Password: - (repeat) New Password: - -#. Verify and/or configure IP connectivity. - - External connectivity is required to run the Ansible bootstrap playbook. The - StarlingX boot image will DHCP out all interfaces so the server may have - obtained an IP address and have external IP connectivity if a DHCP server is - present in your environment. Verify this using the :command:`ip addr` and - :command:`ping 8.8.8.8` commands. - - Otherwise, manually configure an IP address and default IP route. Use the - PORT, IP-ADDRESS/SUBNET-LENGTH and GATEWAY-IP-ADDRESS applicable to your - deployment environment. - - :: - - sudo ip address add / dev - sudo ip link set up dev - sudo ip route add default via dev - ping 8.8.8.8 - -#. Specify user configuration overrides for the Ansible bootstrap playbook. - - Ansible is used to bootstrap StarlingX on controller-0. Key files for Ansible - configuration are: - - ``/etc/ansible/hosts`` - The default Ansible inventory file. Contains a single host: localhost. - - ``/usr/share/ansible/stx-ansible/playbooks/bootstrap/bootstrap.yml`` - The Ansible bootstrap playbook. - - ``/usr/share/ansible/stx-ansible/playbooks/host_vars/bootstrap/default.yml`` - The default configuration values for the bootstrap playbook. - - sysadmin home directory ($HOME) - The default location where Ansible looks for and imports user - configuration override files for hosts. For example: ``$HOME/.yml``. - - Specify the user configuration override file for the Ansible bootstrap - playbook using one of the following methods: - - #. Use a copy of the default.yml file listed above to provide your overrides. - - The default.yml file lists all available parameters for bootstrap - configuration with a brief description for each parameter in the file comments. - - To use this method, copy the default.yml file listed above to - ``$HOME/localhost.yml`` and edit the configurable values as desired. - - #. Create a minimal user configuration override file. - - To use this method, create your override file at ``$HOME/localhost.yml`` - and provide the minimum required parameters for the deployment configuration - as shown in the example below. Use the OAM IP SUBNET and IP ADDRESSing - applicable to your deployment environment. - - :: - - cd ~ - cat < localhost.yml - system_mode: duplex - - dns_servers: - - 8.8.8.8 - - 8.8.4.4 - - external_oam_subnet: / - external_oam_gateway_address: - external_oam_floating_address: - external_oam_node_0_address: - external_oam_node_1_address: - - admin_username: admin - admin_password: - ansible_become_pass: - EOF - - Refer to :doc:`/deploy_install_guides/r2_release/ansible_bootstrap_configs` - for information on additional Ansible bootstrap configurations for advanced - Ansible bootstrap scenarios. - -#. Run the Ansible bootstrap playbook: - - :: - - ansible-playbook /usr/share/ansible/stx-ansible/playbooks/bootstrap/bootstrap.yml - - Wait for Ansible bootstrap playbook to complete. - This can take 5-10 minutes, depending on the performance of the host machine. - ----------------------- -Configure controller-0 ----------------------- - -#. Acquire admin credentials: - - :: - - source /etc/platform/openrc - -#. Configure the OAM and MGMT interfaces of controller-0 and specify the - attached networks. Use the OAM and MGMT port names, for example eth0, that are - applicable to your deployment environment. - - :: - - OAM_IF= - MGMT_IF= - system host-if-modify controller-0 lo -c none - IFNET_UUIDS=$(system interface-network-list controller-0 | awk '{if ($6=="lo") print $4;}') - for UUID in $IFNET_UUIDS; do - system interface-network-remove ${UUID} - done - system host-if-modify controller-0 $OAM_IF -c platform - system interface-network-assign controller-0 $OAM_IF oam - system host-if-modify controller-0 $MGMT_IF -c platform - system interface-network-assign controller-0 $MGMT_IF mgmt - system interface-network-assign controller-0 $MGMT_IF cluster-host - -#. Configure NTP Servers for network time synchronization: - - :: - - system ntp-modify ntpservers=0.pool.ntp.org,1.pool.ntp.org - -#. Configure data interfaces for controller-0. Use the DATA port names, for example - eth0, applicable to your deployment environment. - - .. important:: - - This step is **required** for OpenStack. - - This step is optional for Kubernetes: Do this step if using SRIOV network - attachments in hosted application containers. - - For Kubernetes SRIOV network attachments: - - * Configure the SRIOV device plugin - - :: - - system host-label-assign controller-0 sriovdp=enabled - - * If planning on running DPDK in containers on this host, configure the number - of 1G Huge pages required on both NUMA nodes. - - :: - - system host-memory-modify controller-0 0 -1G 100 - system host-memory-modify controller-0 1 -1G 100 - - For both Kubernetes and OpenStack: - - :: - - DATA0IF= - DATA1IF= - export COMPUTE=controller-0 - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - system host-port-list ${COMPUTE} --nowrap > ${SPL} - system host-if-list -a ${COMPUTE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - system host-if-modify -m 1500 -n data0 -c data ${COMPUTE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${COMPUTE} ${DATA1IFUUID} - system interface-datanetwork-assign ${COMPUTE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${COMPUTE} ${DATA1IFUUID} ${PHYSNET1} - -#. Add an OSD on controller-0 for Ceph. The following example adds an OSD - to the `sdb` disk: - - :: - - echo ">>> Add OSDs to primary tier" - system host-disk-list controller-0 - system host-disk-list controller-0 | awk '/\/dev\/sdb/{print $2}' | xargs -i system host-stor-add controller-0 {} - system host-stor-list controller-0 - -************************************* -OpenStack-specific host configuration -************************************* - -.. include:: aio_simplex_install_kubernetes.rst - :start-after: incl-config-controller-0-openstack-specific-aio-simplex-start: - :end-before: incl-config-controller-0-openstack-specific-aio-simplex-end: - -------------------- -Unlock controller-0 -------------------- - -.. include:: aio_simplex_install_kubernetes.rst - :start-after: incl-unlock-controller-0-aio-simplex-start: - :end-before: incl-unlock-controller-0-aio-simplex-end: - -------------------------------------- -Install software on controller-1 node -------------------------------------- - -#. Power on the controller-1 server and force it to network boot with the - appropriate BIOS boot options for your particular server. - -#. As controller-1 boots, a message appears on its console instructing you to - configure the personality of the node. - -#. On the console of controller-0, list hosts to see newly discovered controller-1 - host (hostname=None): - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. Using the host id, set the personality of this host to 'controller': - - :: - - system host-update 2 personality=controller - -#. Wait for the software installation on controller-1 to complete, for controller-1 to - reboot, and for controller-1 to show as locked/disabled/online in 'system host-list'. - - This can take 5-10 minutes, depending on the performance of the host machine. - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - ----------------------- -Configure controller-1 ----------------------- - -#. Configure the OAM and MGMT interfaces of controller-1 and specify the - attached networks. Use the OAM and MGMT port names, for example eth0, that are - applicable to your deployment environment: - - (Note that the MGMT interface is partially set up automatically by the network - install procedure.) - - :: - - OAM_IF= - MGMT_IF= - system host-if-modify controller-1 $OAM_IF -c platform - system interface-network-assign controller-1 $OAM_IF oam - system interface-network-assign controller-1 mgmt0 cluster-host - -#. Configure data interfaces for controller-1. Use the DATA port names, for example - eth0, applicable to your deployment environment. - - .. important:: - - This step is **required** for OpenStack. - - This step is optional for Kubernetes: Do this step if using SRIOV network - attachments in hosted application containers. - - For Kubernetes SRIOV network attachments: - - * Configure the SRIOV device plugin: - - :: - - system host-label-assign controller-1 sriovdp=enabled - - * If planning on running DPDK in containers on this host, configure the number - of 1G Huge pages required on both NUMA nodes: - - :: - - system host-memory-modify controller-1 0 -1G 100 - system host-memory-modify controller-1 1 -1G 100 - - - For both Kubernetes and OpenStack: - - :: - - DATA0IF= - DATA1IF= - export COMPUTE=controller-1 - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - system host-port-list ${COMPUTE} --nowrap > ${SPL} - system host-if-list -a ${COMPUTE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - system host-if-modify -m 1500 -n data0 -c data ${COMPUTE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${COMPUTE} ${DATA1IFUUID} - system interface-datanetwork-assign ${COMPUTE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${COMPUTE} ${DATA1IFUUID} ${PHYSNET1} - -#. Add an OSD on controller-1 for Ceph: - - :: - - echo ">>> Add OSDs to primary tier" - system host-disk-list controller-1 - system host-disk-list controller-1 | awk '/\/dev\/sdb/{print $2}' | xargs -i system host-stor-add controller-1 {} - system host-stor-list controller-1 - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to controller-1 in - support of installing the stx-openstack manifest and helm-charts later. - - :: - - system host-label-assign controller-1 openstack-control-plane=enabled - system host-label-assign controller-1 openstack-compute-node=enabled - system host-label-assign controller-1 openvswitch=enabled - system host-label-assign controller-1 sriov=enabled - -#. **For OpenStack only:** Set up disk partition for nova-local volume group, - which is needed for stx-openstack nova ephemeral disks. - - :: - - export COMPUTE=controller-1 - - echo ">>> Getting root disk info" - ROOT_DISK=$(system host-show ${COMPUTE} | grep rootfs | awk '{print $4}') - ROOT_DISK_UUID=$(system host-disk-list ${COMPUTE} --nowrap | grep ${ROOT_DISK} | awk '{print $2}') - echo "Root disk: $ROOT_DISK, UUID: $ROOT_DISK_UUID" - - echo ">>>> Configuring nova-local" - NOVA_SIZE=34 - NOVA_PARTITION=$(system host-disk-partition-add -t lvm_phys_vol ${COMPUTE} ${ROOT_DISK_UUID} ${NOVA_SIZE}) - NOVA_PARTITION_UUID=$(echo ${NOVA_PARTITION} | grep -ow "| uuid | [a-z0-9\-]* |" | awk '{print $4}') - system host-lvg-add ${COMPUTE} nova-local - system host-pv-add ${COMPUTE} nova-local ${NOVA_PARTITION_UUID} - sleep 2 - -------------------- -Unlock controller-1 -------------------- - -Unlock controller-1 in order to bring it into service: - -:: - - system host-unlock controller-1 - -Controller-1 will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host -machine. - ----------- -Next steps ----------- - -.. include:: ../kubernetes_install_next.txt diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/aio_simplex.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/aio_simplex.rst deleted file mode 100644 index 6f8dbdb54..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/aio_simplex.rst +++ /dev/null @@ -1,21 +0,0 @@ -=============================================== -Bare metal All-in-one Simplex Installation R2.0 -=============================================== - --------- -Overview --------- - -.. include:: ../desc_aio_simplex.txt - -.. include:: ../ipv6_note.txt - ------------- -Installation ------------- - -.. toctree:: - :maxdepth: 1 - - aio_simplex_hardware - aio_simplex_install_kubernetes diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/aio_simplex_hardware.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/aio_simplex_hardware.rst deleted file mode 100644 index ede69cd8c..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/aio_simplex_hardware.rst +++ /dev/null @@ -1,58 +0,0 @@ -===================== -Hardware Requirements -===================== - -This section describes the hardware requirements and server preparation for a -**StarlingX R2.0 bare metal All-in-one Simplex** deployment configuration. - -.. contents:: - :local: - :depth: 1 - ------------------------------ -Minimum hardware requirements ------------------------------ - -The recommended minimum hardware requirements for bare metal servers for various -host types are: - -+-------------------------+-----------------------------------------------------------+ -| Minimum Requirement | All-in-one Controller Node | -+=========================+===========================================================+ -| Number of servers | 1 | -+-------------------------+-----------------------------------------------------------+ -| Minimum processor class | - Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) | -| | 8 cores/socket | -| | | -| | or | -| | | -| | - Single-CPU Intel® Xeon® D-15xx family, 8 cores | -| | (low-power/low-cost option) | -+-------------------------+-----------------------------------------------------------+ -| Minimum memory | 64 GB | -+-------------------------+-----------------------------------------------------------+ -| Primary disk | 500 GB SSD or NVMe (see :doc:`../../nvme_config`) | -+-------------------------+-----------------------------------------------------------+ -| Additional disks | - 1 or more 500 GB (min. 10K RPM) for Ceph OSD | -| | - Recommended, but not required: 1 or more SSDs or NVMe | -| | drives for Ceph journals (min. 1024 MiB per OSD | -| | journal) | -| | - For OpenStack, recommend 1 or more 500 GB (min. 10K | -| | RPM) for VM local ephemeral storage | -+-------------------------+-----------------------------------------------------------+ -| Minimum network ports | - OAM: 1x1GE | -| | - Data: 1 or more x 10GE | -+-------------------------+-----------------------------------------------------------+ -| BIOS settings | - Hyper-Threading technology enabled | -| | - Virtualization technology enabled | -| | - VT for directed I/O enabled | -| | - CPU power and performance policy set to performance | -| | - CPU C state control disabled | -| | - Plug & play BMC detection disabled | -+-------------------------+-----------------------------------------------------------+ - --------------------------- -Prepare bare metal servers --------------------------- - -.. include:: prep_servers.txt \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/aio_simplex_install_kubernetes.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/aio_simplex_install_kubernetes.rst deleted file mode 100644 index 80ed575e0..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/aio_simplex_install_kubernetes.rst +++ /dev/null @@ -1,347 +0,0 @@ -================================================= -Install StarlingX Kubernetes on Bare Metal AIO-SX -================================================= - -This section describes the steps to install the StarlingX Kubernetes platform -on a **StarlingX R2.0 bare metal All-in-one Simplex** deployment configuration. - -.. contents:: - :local: - :depth: 1 - ---------------------- -Create a bootable USB ---------------------- - -Refer to :doc:`/deploy_install_guides/bootable_usb` for instructions on how to -create a bootable USB with the StarlingX ISO on your system. - --------------------------------- -Install software on controller-0 --------------------------------- - -.. incl-install-software-controller-0-aio-simplex-start: - -#. Insert the bootable USB into a bootable USB port on the host you are - configuring as controller-0. - -#. Power on the host. - -#. Attach to a console, ensure the host boots from the USB, and wait for the - StarlingX Installer Menus. - -#. Make the following menu selections in the installer: - - #. First menu: Select 'All-in-one Controller Configuration' - #. Second menu: Select 'Graphical Console' or 'Textual Console' depending on - your terminal access to the console port - #. Third menu: Select 'Standard Security Profile' - -#. Wait for non-interactive install of software to complete and server to reboot. - This can take 5-10 minutes, depending on the performance of the server. - -.. incl-install-software-controller-0-aio-simplex-end: - --------------------------------- -Bootstrap system on controller-0 --------------------------------- - -#. Login using the username / password of "sysadmin" / "sysadmin". - When logging in for the first time, you will be forced to change the password. - - :: - - Login: sysadmin - Password: - Changing password for sysadmin. - (current) UNIX Password: sysadmin - New Password: - (repeat) New Password: - -#. Verify and/or configure IP connectivity. - - External connectivity is required to run the Ansible bootstrap playbook. The - StarlingX boot image will DHCP out all interfaces so the server may have - obtained an IP address and have external IP connectivity if a DHCP server is - present in your environment. Verify this using the :command:`ip addr` and - :command:`ping 8.8.8.8` commands. - - Otherwise, manually configure an IP address and default IP route. Use the - PORT, IP-ADDRESS/SUBNET-LENGTH and GATEWAY-IP-ADDRESS applicable to your - deployment environment. - - :: - - sudo ip address add / dev - sudo ip link set up dev - sudo ip route add default via dev - ping 8.8.8.8 - -#. Specify user configuration overrides for the Ansible bootstrap playbook. - - Ansible is used to bootstrap StarlingX on controller-0. Key files for Ansible - configuration are: - - ``/etc/ansible/hosts`` - The default Ansible inventory file. Contains a single host: localhost. - - ``/usr/share/ansible/stx-ansible/playbooks/bootstrap/bootstrap.yml`` - The Ansible bootstrap playbook. - - ``/usr/share/ansible/stx-ansible/playbooks/host_vars/bootstrap/default.yml`` - The default configuration values for the bootstrap playbook. - - sysadmin home directory ($HOME) - The default location where Ansible looks for and imports user - configuration override files for hosts. For example: ``$HOME/.yml``. - - Specify the user configuration override file for the Ansible bootstrap - playbook using one of the following methods: - - #. Use a copy of the default.yml file listed above to provide your overrides. - - The default.yml file lists all available parameters for bootstrap - configuration with a brief description for each parameter in the file comments. - - To use this method, copy the default.yml file listed above to - ``$HOME/localhost.yml`` and edit the configurable values as desired. - - #. Create a minimal user configuration override file. - - To use this method, create your override file at ``$HOME/localhost.yml`` - and provide the minimum required parameters for the deployment configuration - as shown in the example below. Use the OAM IP SUBNET and IP ADDRESSing - applicable to your deployment environment. - - :: - - cd ~ - cat < localhost.yml - system_mode: simplex - - dns_servers: - - 8.8.8.8 - - 8.8.4.4 - - external_oam_subnet: / - external_oam_gateway_address: - external_oam_floating_address: - - admin_username: admin - admin_password: - ansible_become_pass: - EOF - - Refer to :doc:`/deploy_install_guides/r2_release/ansible_bootstrap_configs` - for information on additional Ansible bootstrap configurations for advanced - Ansible bootstrap scenarios. - -#. Run the Ansible bootstrap playbook: - - :: - - ansible-playbook /usr/share/ansible/stx-ansible/playbooks/bootstrap/bootstrap.yml - - Wait for Ansible bootstrap playbook to complete. - This can take 5-10 minutes, depending on the performance of the host machine. - ----------------------- -Configure controller-0 ----------------------- - -#. Acquire admin credentials: - - :: - - source /etc/platform/openrc - -#. Configure the OAM interface of controller-0 and specify the attached network - as "oam". Use the OAM port name, for example eth0, that is applicable to your - deployment environment: - - :: - - OAM_IF= - system host-if-modify controller-0 $OAM_IF -c platform - system interface-network-assign controller-0 $OAM_IF oam - -#. Configure NTP Servers for network time synchronization: - - :: - - system ntp-modify ntpservers=0.pool.ntp.org,1.pool.ntp.org - -#. Configure data interfaces for controller-0. Use the DATA port names, for example - eth0, applicable to your deployment environment. - - .. important:: - - This step is **required** for OpenStack. - - This step is optional for Kubernetes: Do this step if using SRIOV network - attachments in hosted application containers. - - For Kubernetes SRIOV network attachments: - - * Configure the SRIOV device plugin - - :: - - system host-label-assign controller-0 sriovdp=enabled - - * If planning on running DPDK in containers on this host, configure the number - of 1G Huge pages required on both NUMA nodes. - - :: - - system host-memory-modify controller-0 0 -1G 100 - system host-memory-modify controller-0 1 -1G 100 - - For both Kubernetes and OpenStack: - - :: - - DATA0IF= - DATA1IF= - export COMPUTE=controller-0 - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - system host-port-list ${COMPUTE} --nowrap > ${SPL} - system host-if-list -a ${COMPUTE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - system host-if-modify -m 1500 -n data0 -c data ${COMPUTE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${COMPUTE} ${DATA1IFUUID} - system interface-datanetwork-assign ${COMPUTE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${COMPUTE} ${DATA1IFUUID} ${PHYSNET1} - -#. Add an OSD on controller-0 for Ceph. The following example adds an OSD - to the `sdb` disk: - - :: - - echo ">>> Add OSDs to primary tier" - system host-disk-list controller-0 - system host-disk-list controller-0 | awk '/\/dev\/sdb/{print $2}' | xargs -i system host-stor-add controller-0 {} - system host-stor-list controller-0 - -************************************* -OpenStack-specific host configuration -************************************* - -.. incl-config-controller-0-openstack-specific-aio-simplex-start: - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to controller-0 in - support of installing the stx-openstack manifest and helm-charts later. - - :: - - system host-label-assign controller-0 openstack-control-plane=enabled - system host-label-assign controller-0 openstack-compute-node=enabled - system host-label-assign controller-0 openvswitch=enabled - system host-label-assign controller-0 sriov=enabled - -#. **For OpenStack only:** Configure the system setting for the vSwitch. - - StarlingX has OVS (kernel-based) vSwitch configured as default: - - * Runs in a container; defined within the helm charts of stx-openstack - manifest. - * Shares the core(s) assigned to the platform. - - If you require better performance, OVS-DPDK should be used: - - * Runs directly on the host (it is not containerized). - * Requires that at least 1 core be assigned/dedicated to the vSwitch function. - - To deploy the default containerized OVS: - - :: - - system modify --vswitch_type none - - Do not run any vSwitch directly on the host, instead, use the containerized - OVS defined in the helm charts of stx-openstack manifest. - - To deploy OVS-DPDK (OVS with the Data Plane Development Kit, which is - supported only on bare metal hardware), run the following command: - - :: - - system modify --vswitch_type ovs-dpdk - system host-cpu-modify -f vswitch -p0 1 controller-0 - - Once vswitch_type is set to OVS-DPDK, any subsequent nodes created will - default to automatically assigning 1 vSwitch core for AIO controllers and 2 - vSwitch cores for computes. - - When using OVS-DPDK, virtual machines must be configured to use a flavor with - property: hw:mem_page_size=large - - .. note:: - - After controller-0 is unlocked, changing vswitch_type requires - locking and unlocking all computes (and/or AIO Controllers) to - apply the change. - -#. **For OpenStack only:** Set up disk partition for nova-local volume group, - which is needed for stx-openstack nova ephemeral disks. - - :: - - export COMPUTE=controller-0 - - echo ">>> Getting root disk info" - ROOT_DISK=$(system host-show ${COMPUTE} | grep rootfs | awk '{print $4}') - ROOT_DISK_UUID=$(system host-disk-list ${COMPUTE} --nowrap | grep ${ROOT_DISK} | awk '{print $2}') - echo "Root disk: $ROOT_DISK, UUID: $ROOT_DISK_UUID" - - echo ">>>> Configuring nova-local" - NOVA_SIZE=34 - NOVA_PARTITION=$(system host-disk-partition-add -t lvm_phys_vol ${COMPUTE} ${ROOT_DISK_UUID} ${NOVA_SIZE}) - NOVA_PARTITION_UUID=$(echo ${NOVA_PARTITION} | grep -ow "| uuid | [a-z0-9\-]* |" | awk '{print $4}') - system host-lvg-add ${COMPUTE} nova-local - system host-pv-add ${COMPUTE} nova-local ${NOVA_PARTITION_UUID} - sleep 2 - -.. incl-config-controller-0-openstack-specific-aio-simplex-end: - -------------------- -Unlock controller-0 -------------------- - -.. incl-unlock-controller-0-aio-simplex-start: - -Unlock controller-0 in order to bring it into service: - -:: - - system host-unlock controller-0 - -Controller-0 will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host machine. - -.. incl-unlock-controller-0-aio-simplex-end: - ----------- -Next steps ----------- - -.. include:: ../kubernetes_install_next.txt diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/controller_storage.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/controller_storage.rst deleted file mode 100644 index a73dc5e7c..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/controller_storage.rst +++ /dev/null @@ -1,22 +0,0 @@ -============================================================= -Bare metal Standard with Controller Storage Installation R2.0 -============================================================= - --------- -Overview --------- - -.. include:: ../desc_controller_storage.txt - -.. include:: ../ipv6_note.txt - - ------------- -Installation ------------- - -.. toctree:: - :maxdepth: 1 - - controller_storage_hardware - controller_storage_install_kubernetes diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/controller_storage_hardware.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/controller_storage_hardware.rst deleted file mode 100644 index e326e0df7..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/controller_storage_hardware.rst +++ /dev/null @@ -1,56 +0,0 @@ -===================== -Hardware Requirements -===================== - -This section describes the hardware requirements and server preparation for a -**StarlingX R2.0 bare metal Standard with Controller Storage** deployment -configuration. - -.. contents:: - :local: - :depth: 1 - ------------------------------ -Minimum hardware requirements ------------------------------ - -The recommended minimum hardware requirements for bare metal servers for various -host types are: - -+-------------------------+-----------------------------+-----------------------------+ -| Minimum Requirement | Controller Node | Compute Node | -+=========================+=============================+=============================+ -| Number of servers | 2 | 2-10 | -+-------------------------+-----------------------------+-----------------------------+ -| Minimum processor class | - Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) | -| | 8 cores/socket | -+-------------------------+-----------------------------+-----------------------------+ -| Minimum memory | 64 GB | 32 GB | -+-------------------------+-----------------------------+-----------------------------+ -| Primary disk | 500 GB SSD or NVMe (see | 120 GB (Minimum 10k RPM) | -| | :doc:`../../nvme_config`) | | -+-------------------------+-----------------------------+-----------------------------+ -| Additional disks | - 1 or more 500 GB (min. | - For OpenStack, recommend | -| | 10K RPM) for Ceph OSD | 1 or more 500 GB (min. | -| | - Recommended, but not | 10K RPM) for VM local | -| | required: 1 or more SSDs | ephemeral storage | -| | or NVMe drives for Ceph | | -| | journals (min. 1024 MiB | | -| | per OSD journal) | | -+-------------------------+-----------------------------+-----------------------------+ -| Minimum network ports | - Mgmt/Cluster: 1x10GE | - Mgmt/Cluster: 1x10GE | -| | - OAM: 1x1GE | - Data: 1 or more x 10GE | -+-------------------------+-----------------------------+-----------------------------+ -| BIOS settings | - Hyper-Threading technology enabled | -| | - Virtualization technology enabled | -| | - VT for directed I/O enabled | -| | - CPU power and performance policy set to performance | -| | - CPU C state control disabled | -| | - Plug & play BMC detection disabled | -+-------------------------+-----------------------------+-----------------------------+ - --------------------------- -Prepare bare metal servers --------------------------- - -.. include:: prep_servers.txt \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/controller_storage_install_kubernetes.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/controller_storage_install_kubernetes.rst deleted file mode 100644 index 35ed0f6df..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/controller_storage_install_kubernetes.rst +++ /dev/null @@ -1,586 +0,0 @@ -=========================================================================== -Install StarlingX Kubernetes on Bare Metal Standard with Controller Storage -=========================================================================== - -This section describes the steps to install the StarlingX Kubernetes platform -on a **StarlingX R2.0 bare metal Standard with Controller Storage** deployment -configuration. - -.. contents:: - :local: - :depth: 1 - -------------------- -Create bootable USB -------------------- - -Refer to :doc:`/deploy_install_guides/bootable_usb` for instructions on how to -create a bootable USB with the StarlingX ISO on your system. - --------------------------------- -Install software on controller-0 --------------------------------- - -.. incl-install-software-controller-0-standard-start: - -#. Insert the bootable USB into a bootable USB port on the host you are - configuring as controller-0. - -#. Power on the host. - -#. Attach to a console, ensure the host boots from the USB, and wait for the - StarlingX Installer Menus. - -#. Make the following menu selections in the installer: - - #. First menu: Select 'Standard Controller Configuration' - #. Second menu: Select 'Graphical Console' or 'Textual Console' depending on - your terminal access to the console port - #. Third menu: Select 'Standard Security Profile' - -#. Wait for non-interactive install of software to complete and server to reboot. - This can take 5-10 minutes, depending on the performance of the server. - -.. incl-install-software-controller-0-standard-end: - --------------------------------- -Bootstrap system on controller-0 --------------------------------- - -.. incl-bootstrap-sys-controller-0-standard-start: - -#. Login using the username / password of "sysadmin" / "sysadmin". - - When logging in for the first time, you will be forced to change the password. - - :: - - Login: sysadmin - Password: - Changing password for sysadmin. - (current) UNIX Password: sysadmin - New Password: - (repeat) New Password: - -#. Verify and/or configure IP connectivity. - - External connectivity is required to run the Ansible bootstrap playbook. The - StarlingX boot image will DHCP out all interfaces so the server may have - obtained an IP address and have external IP connectivity if a DHCP server is - present in your environment. Verify this using the :command:`ip addr` and - :command:`ping 8.8.8.8` commands. - - Otherwise, manually configure an IP address and default IP route. Use the - PORT, IP-ADDRESS/SUBNET-LENGTH and GATEWAY-IP-ADDRESS applicable to your - deployment environment. - - :: - - sudo ip address add / dev - sudo ip link set up dev - sudo ip route add default via dev - ping 8.8.8.8 - -#. Specify user configuration overrides for the Ansible bootstrap playbook. - - Ansible is used to bootstrap StarlingX on controller-0. Key files for Ansible - configuration are: - - ``/etc/ansible/hosts`` - The default Ansible inventory file. Contains a single host: localhost. - - ``/usr/share/ansible/stx-ansible/playbooks/bootstrap/bootstrap.yml`` - The Ansible bootstrap playbook. - - ``/usr/share/ansible/stx-ansible/playbooks/host_vars/bootstrap/default.yml`` - The default configuration values for the bootstrap playbook. - - sysadmin home directory ($HOME) - The default location where Ansible looks for and imports user - configuration override files for hosts. For example: ``$HOME/.yml``. - - Specify the user configuration override file for the Ansible bootstrap - playbook using one of the following methods: - - #. Use a copy of the default.yml file listed above to provide your overrides. - - The default.yml file lists all available parameters for bootstrap - configuration with a brief description for each parameter in the file comments. - - To use this method, copy the default.yml file listed above to - ``$HOME/localhost.yml`` and edit the configurable values as desired. - - #. Create a minimal user configuration override file. - - To use this method, create your override file at ``$HOME/localhost.yml`` - and provide the minimum required parameters for the deployment configuration - as shown in the example below. Use the OAM IP SUBNET and IP ADDRESSing - applicable to your deployment environment. - - :: - - cd ~ - cat < localhost.yml - system_mode: duplex - - dns_servers: - - 8.8.8.8 - - 8.8.4.4 - - external_oam_subnet: / - external_oam_gateway_address: - external_oam_floating_address: - external_oam_node_0_address: - external_oam_node_1_address: - - admin_username: admin - admin_password: - ansible_become_pass: - EOF - - Refer to :doc:`/deploy_install_guides/r2_release/ansible_bootstrap_configs` - for information on additional Ansible bootstrap configurations for advanced - Ansible bootstrap scenarios. - -#. Run the Ansible bootstrap playbook: - - :: - - ansible-playbook /usr/share/ansible/stx-ansible/playbooks/bootstrap/bootstrap.yml - - Wait for Ansible bootstrap playbook to complete. - This can take 5-10 minutes, depending on the performance of the host machine. - -.. incl-bootstrap-sys-controller-0-standard-end: - - ----------------------- -Configure controller-0 ----------------------- - -.. incl-config-controller-0-storage-start: - -#. Acquire admin credentials: - - :: - - source /etc/platform/openrc - -#. Configure the OAM and MGMT interfaces of controller-0 and specify the - attached networks. Use the OAM and MGMT port names, for example eth0, that are - applicable to your deployment environment. - - :: - - OAM_IF= - MGMT_IF= - system host-if-modify controller-0 lo -c none - IFNET_UUIDS=$(system interface-network-list controller-0 | awk '{if ($6=="lo") print $4;}') - for UUID in $IFNET_UUIDS; do - system interface-network-remove ${UUID} - done - system host-if-modify controller-0 $OAM_IF -c platform - system interface-network-assign controller-0 $OAM_IF oam - system host-if-modify controller-0 $MGMT_IF -c platform - system interface-network-assign controller-0 $MGMT_IF mgmt - system interface-network-assign controller-0 $MGMT_IF cluster-host - -#. Configure NTP Servers for network time synchronization: - - :: - - system ntp-modify ntpservers=0.pool.ntp.org,1.pool.ntp.org - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to controller-0 in - support of installing the stx-openstack manifest and helm-charts later. - - :: - - system host-label-assign controller-0 openstack-control-plane=enabled - -#. **For OpenStack only:** Configure the system setting for the vSwitch. - - StarlingX has OVS (kernel-based) vSwitch configured as default: - - * Runs in a container; defined within the helm charts of stx-openstack - manifest. - * Shares the core(s) assigned to the platform. - - If you require better performance, OVS-DPDK should be used: - - * Runs directly on the host (it is not containerized). - * Requires that at least 1 core be assigned/dedicated to the vSwitch function. - - To deploy the default containerized OVS: - - :: - - system modify --vswitch_type none - - Do not run any vSwitch directly on the host, instead, use the containerized - OVS defined in the helm charts of stx-openstack manifest. - - To deploy OVS-DPDK (OVS with the Data Plane Development Kit, which is - supported only on bare metal hardware), run the following command: - - :: - - system modify --vswitch_type ovs-dpdk - system host-cpu-modify -f vswitch -p0 1 controller-0 - - Once vswitch_type is set to OVS-DPDK, any subsequent nodes created will - default to automatically assigning 1 vSwitch core for AIO controllers and 2 - vSwitch cores for computes. - - When using OVS-DPDK, Virtual Machines must be configured to use a flavor with - property: hw:mem_page_size=large. - - .. note:: - - After controller-0 is unlocked, changing vswitch_type requires - locking and unlocking all computes (and/or AIO controllers) to - apply the change. - -.. incl-config-controller-0-storage-end: - -------------------- -Unlock controller-0 -------------------- - -Unlock controller-0 in order to bring it into service: - -:: - - system host-unlock controller-0 - -Controller-0 will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host machine. - --------------------------------------------------- -Install software on controller-1 and compute nodes --------------------------------------------------- - -#. Power on the controller-1 server and force it to network boot with the - appropriate BIOS boot options for your particular server. - -#. As controller-1 boots, a message appears on its console instructing you to - configure the personality of the node. - -#. On the console of controller-0, list hosts to see newly discovered controller-1 - host (hostname=None): - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. Using the host id, set the personality of this host to 'controller': - - :: - - system host-update 2 personality=controller - - This initiates the install of software on controller-1. - This can take 5-10 minutes, depending on the performance of the host machine. - -#. While waiting for the previous step to complete, power on the compute-0 and - compute-1 servers. Set the personality to 'worker' and assign a unique - hostname for each. - - For example, power on compute-0 and wait for the new host (hostname=None) to - be discovered by checking 'system host-list': - - :: - - system host-update 3 personality=worker hostname=compute-0 - - Repeat for compute-1. Power on compute-1 and wait for the new host (hostname=None) to - be discovered by checking 'system host-list': - - :: - - system host-update 4 personality=worker hostname=compute-1 - -#. Wait for the software installation on controller-1, compute-0, and compute-1 to - complete, for all servers to reboot, and for all to show as locked/disabled/online in - 'system host-list'. - - :: - - system host-list - - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | locked | disabled | online | - | 3 | compute-0 | compute | locked | disabled | online | - | 4 | compute-1 | compute | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - ----------------------- -Configure controller-1 ----------------------- - -.. incl-config-controller-1-start: - -Configure the OAM and MGMT interfaces of controller-0 and specify the attached -networks. Use the OAM and MGMT port names, for example eth0, that are applicable -to your deployment environment. - -(Note that the MGMT interface is partially set up automatically by the network -install procedure.) - -:: - - OAM_IF= - MGMT_IF= - system host-if-modify controller-1 $OAM_IF -c platform - system interface-network-assign controller-1 $OAM_IF oam - system interface-network-assign controller-1 $MGMT_IF cluster-host - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -**For OpenStack only:** Assign OpenStack host labels to controller-1 in support -of installing the stx-openstack manifest and helm-charts later. - -:: - - system host-label-assign controller-1 openstack-control-plane=enabled - -.. incl-config-controller-1-end: - -------------------- -Unlock controller-1 -------------------- - -.. incl-unlock-controller-1-start: - -Unlock controller-1 in order to bring it into service: - -:: - - system host-unlock controller-1 - -Controller-1 will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host -machine. - -.. incl-unlock-controller-1-end: - ------------------------ -Configure compute nodes ------------------------ - -#. Add the third Ceph monitor to compute-0: - - (The first two Ceph monitors are automatically assigned to controller-0 and - controller-1.) - - :: - - system ceph-mon-add compute-0 - -#. Wait for the compute node monitor to complete configuration: - - :: - - system ceph-mon-list - +--------------------------------------+-------+--------------+------------+------+ - | uuid | ceph_ | hostname | state | task | - | | mon_g | | | | - | | ib | | | | - +--------------------------------------+-------+--------------+------------+------+ - | 64176b6c-e284-4485-bb2a-115dee215279 | 20 | controller-1 | configured | None | - | a9ca151b-7f2c-4551-8167-035d49e2df8c | 20 | controller-0 | configured | None | - | f76bc385-190c-4d9a-aa0f-107346a9907b | 20 | compute-0 | configured | None | - +--------------------------------------+-------+--------------+------------+------+ - -#. Assign the cluster-host network to the MGMT interface for the compute nodes: - - (Note that the MGMT interfaces are partially set up automatically by the - network install procedure.) - - :: - - for COMPUTE in compute-0 compute-1; do - system interface-network-assign $COMPUTE mgmt0 cluster-host - done - -#. Configure data interfaces for compute nodes. Use the DATA port names, for - example eth0, that are applicable to your deployment environment. - - .. important:: - - This step is **required** for OpenStack. - - This step is optional for Kubernetes: Do this step if using SRIOV network - attachments in hosted application containers. - - For Kubernetes SRIOV network attachments: - - * Configure SRIOV device plug in: - - :: - - for COMPUTE in compute-0 compute-1; do - system host-label-assign ${COMPUTE} sriovdp=enabled - done - - * If planning on running DPDK in containers on this host, configure the number - of 1G Huge pages required on both NUMA nodes: - - :: - - for COMPUTE in compute-0 compute-1; do - system host-memory-modify ${COMPUTE} 0 -1G 100 - system host-memory-modify ${COMPUTE} 1 -1G 100 - done - - For both Kubernetes and OpenStack: - - :: - - DATA0IF= - DATA1IF= - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - - # configure the datanetworks in sysinv, prior to referencing it - # in the ``system host-if-modify`` command'. - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - for COMPUTE in compute-0 compute-1; do - echo "Configuring interface for: $COMPUTE" - set -ex - system host-port-list ${COMPUTE} --nowrap > ${SPL} - system host-if-list -a ${COMPUTE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - system host-if-modify -m 1500 -n data0 -c data ${COMPUTE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${COMPUTE} ${DATA1IFUUID} - system interface-datanetwork-assign ${COMPUTE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${COMPUTE} ${DATA1IFUUID} ${PHYSNET1} - set +ex - done - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to the compute nodes in - support of installing the stx-openstack manifest and helm-charts later. - - :: - - for NODE in compute-0 compute-1; do - system host-label-assign $NODE openstack-compute-node=enabled - system host-label-assign $NODE openvswitch=enabled - system host-label-assign $NODE sriov=enabled - done - -#. **For OpenStack only:** Set up disk partition for nova-local volume group, - which is needed for stx-openstack nova ephemeral disks. - - :: - - for COMPUTE in compute-0 compute-1; do - echo "Configuring Nova local for: $COMPUTE" - ROOT_DISK=$(system host-show ${COMPUTE} | grep rootfs | awk '{print $4}') - ROOT_DISK_UUID=$(system host-disk-list ${COMPUTE} --nowrap | grep ${ROOT_DISK} | awk '{print $2}') - PARTITION_SIZE=10 - NOVA_PARTITION=$(system host-disk-partition-add -t lvm_phys_vol ${COMPUTE} ${ROOT_DISK_UUID} ${PARTITION_SIZE}) - NOVA_PARTITION_UUID=$(echo ${NOVA_PARTITION} | grep -ow "| uuid | [a-z0-9\-]* |" | awk '{print $4}') - system host-lvg-add ${COMPUTE} nova-local - system host-pv-add ${COMPUTE} nova-local ${NOVA_PARTITION_UUID} - done - --------------------- -Unlock compute nodes --------------------- - -Unlock compute nodes in order to bring them into service: - -:: - - for COMPUTE in compute-0 compute-1; do - system host-unlock $COMPUTE - done - -The compute nodes will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host machine. - ----------------------------- -Add Ceph OSDs to controllers ----------------------------- - -#. Add OSDs to controller-0. The following example adds OSDs to the `sdb` disk: - - :: - - HOST=controller-0 - DISKS=$(system host-disk-list ${HOST}) - TIERS=$(system storage-tier-list ceph_cluster) - OSDs="/dev/sdb" - for OSD in $OSDs; do - system host-stor-add ${HOST} $(echo "$DISKS" | grep "$OSD" | awk '{print $2}') --tier-uuid $(echo "$TIERS" | grep storage | awk '{print $2}') - while true; do system host-stor-list ${HOST} | grep ${OSD} | grep configuring; if [ $? -ne 0 ]; then break; fi; sleep 1; done - done - - system host-stor-list $HOST - -#. Add OSDs to controller-1. The following example adds OSDs to the `sdb` disk: - - :: - - HOST=controller-1 - DISKS=$(system host-disk-list ${HOST}) - TIERS=$(system storage-tier-list ceph_cluster) - OSDs="/dev/sdb" - for OSD in $OSDs; do - system host-stor-add ${HOST} $(echo "$DISKS" | grep "$OSD" | awk '{print $2}') --tier-uuid $(echo "$TIERS" | grep storage | awk '{print $2}') - while true; do system host-stor-list ${HOST} | grep ${OSD} | grep configuring; if [ $? -ne 0 ]; then break; fi; sleep 1; done - done - - system host-stor-list $HOST - ----------- -Next steps ----------- - -.. include:: ../kubernetes_install_next.txt diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/dedicated_storage.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/dedicated_storage.rst deleted file mode 100644 index 7562ff134..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/dedicated_storage.rst +++ /dev/null @@ -1,21 +0,0 @@ -============================================================ -Bare metal Standard with Dedicated Storage Installation R2.0 -============================================================ - --------- -Overview --------- - -.. include:: ../desc_dedicated_storage.txt - -.. include:: ../ipv6_note.txt - ------------- -Installation ------------- - -.. toctree:: - :maxdepth: 1 - - dedicated_storage_hardware - dedicated_storage_install_kubernetes diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/dedicated_storage_hardware.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/dedicated_storage_hardware.rst deleted file mode 100644 index dbb4ccd01..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/dedicated_storage_hardware.rst +++ /dev/null @@ -1,61 +0,0 @@ -===================== -Hardware Requirements -===================== - -This section describes the hardware requirements and server preparation for a -**StarlingX R2.0 bare metal Standard with Dedicated Storage** deployment -configuration. - -.. contents:: - :local: - :depth: 1 - ------------------------------ -Minimum hardware requirements ------------------------------ - -The recommended minimum hardware requirements for bare metal servers for various -host types are: - -+---------------------+---------------------------+-----------------------+-----------------------+ -| Minimum Requirement | Controller Node | Storage Node | Compute Node | -+=====================+===========================+=======================+=======================+ -| Number of servers | 2 | 2-9 | 2-100 | -+---------------------+---------------------------+-----------------------+-----------------------+ -| Minimum processor | Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) 8 cores/socket | -| class | | -+---------------------+---------------------------+-----------------------+-----------------------+ -| Minimum memory | 64 GB | 64 GB | 32 GB | -+---------------------+---------------------------+-----------------------+-----------------------+ -| Primary disk | 500 GB SSD or NVMe ( see | 120 GB (min. 10k RPM) | 120 GB (min. 10k RPM) | -| | :doc:`../../nvme_config`) | | | -+---------------------+---------------------------+-----------------------+-----------------------+ -| Additional disks | None | - 1 or more 500 GB | - For OpenStack, | -| | | (min. 10K RPM) for | recommend 1 or more | -| | | Ceph OSD | 500 GB (min. 10K | -| | | - Recommended, but | RPM) for VM | -| | | not required: 1 or | ephemeral storage | -| | | more SSDs or NVMe | | -| | | drives for Ceph | | -| | | journals (min. 1024 | | -| | | MiB per OSD | | -| | | journal) | | -+---------------------+---------------------------+-----------------------+-----------------------+ -| Minimum network | - Mgmt/Cluster: | - Mgmt/Cluster: | - Mgmt/Cluster: | -| ports | 1x10GE | 1x10GE | 1x10GE | -| | - OAM: 1x1GE | | - Data: 1 or more | -| | | | x 10GE | -+---------------------+---------------------------+-----------------------+-----------------------+ -| BIOS settings | - Hyper-Threading technology enabled | -| | - Virtualization technology enabled | -| | - VT for directed I/O enabled | -| | - CPU power and performance policy set to performance | -| | - CPU C state control disabled | -| | - Plug & play BMC detection disabled | -+---------------------+---------------------------+-----------------------+-----------------------+ - --------------------------- -Prepare bare metal servers --------------------------- - -.. include:: prep_servers.txt \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/dedicated_storage_install_kubernetes.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/dedicated_storage_install_kubernetes.rst deleted file mode 100644 index e901a545b..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/dedicated_storage_install_kubernetes.rst +++ /dev/null @@ -1,362 +0,0 @@ -========================================================================== -Install StarlingX Kubernetes on Bare Metal Standard with Dedicated Storage -========================================================================== - -This section describes the steps to install the StarlingX Kubernetes platform -on a **StarlingX R2.0 bare metal Standard with Dedicated Storage** deployment -configuration. - -.. contents:: - :local: - :depth: 1 - -------------------- -Create bootable USB -------------------- - -Refer to :doc:`/deploy_install_guides/bootable_usb` for instructions on how to -create a bootable USB with the StarlingX ISO on your system. - --------------------------------- -Install software on controller-0 --------------------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-install-software-controller-0-standard-start: - :end-before: incl-install-software-controller-0-standard-end: - --------------------------------- -Bootstrap system on controller-0 --------------------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-bootstrap-sys-controller-0-standard-start: - :end-before: incl-bootstrap-sys-controller-0-standard-end: - ----------------------- -Configure controller-0 ----------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-config-controller-0-storage-start: - :end-before: incl-config-controller-0-storage-end: - -------------------- -Unlock controller-0 -------------------- - -Unlock controller-0 in order to bring it into service: - -:: - - system host-unlock controller-0 - -Controller-0 will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host machine. - ------------------------------------------------------------------- -Install software on controller-1, storage nodes, and compute nodes ------------------------------------------------------------------- - -#. Power on the controller-1 server and force it to network boot with the - appropriate BIOS boot options for your particular server. - -#. As controller-1 boots, a message appears on its console instructing you to - configure the personality of the node. - -#. On the console of controller-0, list hosts to see newly discovered controller-1 - host (hostname=None): - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. Using the host id, set the personality of this host to 'controller': - - :: - - system host-update 2 personality=controller - - This initiates the install of software on controller-1. - This can take 5-10 minutes, depending on the performance of the host machine. - -#. While waiting for the previous step to complete, power on the storage-0 and - storage-1 servers. Set the personality to 'storage' and assign a unique - hostname for each. - - For example, power on storage-0 and wait for the new host (hostname=None) to - be discovered by checking 'system host-list': - - :: - - system host-update 3 personality=storage - - Repeat for storage-1. Power on storage-1 and wait for the new host - (hostname=None) to be discovered by checking 'system host-list': - - :: - - system host-update 4 personality=storage - - This initiates the software installation on storage-0 and storage-1. - This can take 5-10 minutes, depending on the performance of the host machine. - -#. While waiting for the previous step to complete, power on the compute-0 and - compute-1 servers. Set the personality to 'worker' and assign a unique - hostname for each. - - For example, power on compute-0 and wait for the new host (hostname=None) to - be discovered by checking 'system host-list': - - :: - - system host-update 5 personality=worker hostname=compute-0 - - Repeat for compute-1. Power on compute-1 and wait for the new host - (hostname=None) to be discovered by checking 'system host-list': - - :: - - system host-update 6 personality=worker hostname=compute-1 - - This initiates the install of software on compute-0 and compute-1. - -#. Wait for the software installation on controller-1, storage-0, storage-1, - compute-0, and compute-1 to complete, for all servers to reboot, and for all to - show as locked/disabled/online in 'system host-list'. - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | locked | disabled | online | - | 3 | storage-0 | storage | locked | disabled | online | - | 4 | storage-1 | storage | locked | disabled | online | - | 5 | compute-0 | compute | locked | disabled | online | - | 6 | compute-1 | compute | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - ----------------------- -Configure controller-1 ----------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-config-controller-1-start: - :end-before: incl-config-controller-1-end: - -------------------- -Unlock controller-1 -------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-unlock-controller-1-start: - :end-before: incl-unlock-controller-1-end: - ------------------------ -Configure storage nodes ------------------------ - -#. Assign the cluster-host network to the MGMT interface for the storage nodes: - - (Note that the MGMT interfaces are partially set up automatically by the - network install procedure.) - - :: - - for COMPUTE in storage-0 storage-1; do - system interface-network-assign $COMPUTE mgmt0 cluster-host - done - -#. Add OSDs to storage-0. The following example adds OSDs to the `sdb` disk: - - :: - - HOST=storage-0 - DISKS=$(system host-disk-list ${HOST}) - TIERS=$(system storage-tier-list ceph_cluster) - OSDs="/dev/sdb" - for OSD in $OSDs; do - system host-stor-add ${HOST} $(echo "$DISKS" | grep "$OSD" | awk '{print $2}') --tier-uuid $(echo "$TIERS" | grep storage | awk '{print $2}') - while true; do system host-stor-list ${HOST} | grep ${OSD} | grep configuring; if [ $? -ne 0 ]; then break; fi; sleep 1; done - done - - system host-stor-list $HOST - -#. Add OSDs to storage-1. The following example adds OSDs to the `sdb` disk: - - :: - - HOST=storage-1 - DISKS=$(system host-disk-list ${HOST}) - TIERS=$(system storage-tier-list ceph_cluster) - OSDs="/dev/sdb" - for OSD in $OSDs; do - system host-stor-add ${HOST} $(echo "$DISKS" | grep "$OSD" | awk '{print $2}') --tier-uuid $(echo "$TIERS" | grep storage | awk '{print $2}') - while true; do system host-stor-list ${HOST} | grep ${OSD} | grep configuring; if [ $? -ne 0 ]; then break; fi; sleep 1; done - done - - system host-stor-list $HOST - --------------------- -Unlock storage nodes --------------------- - -Unlock storage nodes in order to bring them into service: - -:: - - for STORAGE in storage-0 storage-1; do - system host-unlock $STORAGE - done - -The storage nodes will reboot in order to apply configuration changes and come -into service. This can take 5-10 minutes, depending on the performance of the -host machine. - ------------------------ -Configure compute nodes ------------------------ - -#. Assign the cluster-host network to the MGMT interface for the compute nodes: - - (Note that the MGMT interfaces are partially set up automatically by the - network install procedure.) - - :: - - for COMPUTE in compute-0 compute-1; do - system interface-network-assign $COMPUTE mgmt0 cluster-host - done - -#. Configure data interfaces for compute nodes. Use the DATA port names, for - example eth0, that are applicable to your deployment environment. - - .. important:: - - This step is **required** for OpenStack. - - This step is optional for Kubernetes: Do this step if using SRIOV network - attachments in hosted application containers. - - For Kubernetes SRIOV network attachments: - - * Configure SRIOV device plug in: - - :: - - for COMPUTE in compute-0 compute-1; do - system host-label-assign ${COMPUTE} sriovdp=enabled - done - - * If planning on running DPDK in containers on this host, configure the number - of 1G Huge pages required on both NUMA nodes: - - :: - - for COMPUTE in compute-0 compute-1; do - system host-memory-modify ${COMPUTE} 0 -1G 100 - system host-memory-modify ${COMPUTE} 1 -1G 100 - done - - For both Kubernetes and OpenStack: - - :: - - DATA0IF= - DATA1IF= - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - - # configure the datanetworks in sysinv, prior to referencing it - # in the ``system host-if-modify`` command'. - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - for COMPUTE in compute-0 compute-1; do - echo "Configuring interface for: $COMPUTE" - set -ex - system host-port-list ${COMPUTE} --nowrap > ${SPL} - system host-if-list -a ${COMPUTE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - system host-if-modify -m 1500 -n data0 -c data ${COMPUTE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${COMPUTE} ${DATA1IFUUID} - system interface-datanetwork-assign ${COMPUTE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${COMPUTE} ${DATA1IFUUID} ${PHYSNET1} - set +ex - done - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to the compute nodes in - support of installing the stx-openstack manifest and helm-charts later. - - :: - - for NODE in compute-0 compute-1; do - system host-label-assign $NODE openstack-compute-node=enabled - system host-label-assign $NODE openvswitch=enabled - system host-label-assign $NODE sriov=enabled - done - -#. **For OpenStack only:** Set up disk partition for nova-local volume group, - which is needed for stx-openstack nova ephemeral disks. - - :: - - for COMPUTE in compute-0 compute-1; do - echo "Configuring Nova local for: $COMPUTE" - ROOT_DISK=$(system host-show ${COMPUTE} | grep rootfs | awk '{print $4}') - ROOT_DISK_UUID=$(system host-disk-list ${COMPUTE} --nowrap | grep ${ROOT_DISK} | awk '{print $2}') - PARTITION_SIZE=10 - NOVA_PARTITION=$(system host-disk-partition-add -t lvm_phys_vol ${COMPUTE} ${ROOT_DISK_UUID} ${PARTITION_SIZE}) - NOVA_PARTITION_UUID=$(echo ${NOVA_PARTITION} | grep -ow "| uuid | [a-z0-9\-]* |" | awk '{print $4}') - system host-lvg-add ${COMPUTE} nova-local - system host-pv-add ${COMPUTE} nova-local ${NOVA_PARTITION_UUID} - done - --------------------- -Unlock compute nodes --------------------- - -Unlock compute nodes in order to bring them into service: - -:: - - for COMPUTE in compute-0 compute-1; do - system host-unlock $COMPUTE - done - -The compute nodes will reboot in order to apply configuration changes and come -into service. This can take 5-10 minutes, depending on the performance of the -host machine. - ----------- -Next steps ----------- - -.. include:: ../kubernetes_install_next.txt diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/ironic.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/ironic.rst deleted file mode 100644 index a722163d5..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/ironic.rst +++ /dev/null @@ -1,66 +0,0 @@ -==================================== -Bare metal Standard with Ironic R2.0 -==================================== - --------- -Overview --------- - -Ironic is an OpenStack project that provisions bare metal machines. For -information about the Ironic project, see -`Ironic Documentation `__. - -End user applications can be deployed on bare metal servers (instead of -virtual machines) by configuring OpenStack Ironic and deploying a pool of 1 or -more bare metal servers. - -.. figure:: ../figures/starlingx-deployment-options-ironic.png - :scale: 90% - :alt: Standard with Ironic deployment configuration - - *Figure 1: Standard with Ironic deployment configuration* - -Bare metal servers must be connected to: - -* IPMI for OpenStack Ironic control -* ironic-provisioning-net tenant network via their untagged physical interface, - which supports PXE booting - -As part of configuring OpenStack Ironic in StarlingX: - -* An ironic-provisioning-net tenant network must be identified as the boot - network for bare metal nodes. -* An additional untagged physical interface must be configured on controller - nodes and connected to the ironic-provisioning-net tenant network. The - OpenStack Ironic tftpboot server will PXE boot the bare metal servers over - this interface. - -.. note:: - - Bare metal servers are NOT: - - * Running any OpenStack / StarlingX software; they are running end user - applications (for example, Glance Images). - * To be connected to the internal management network. - ------------- -Installation ------------- - -StarlingX currently supports only a bare metal installation of Ironic with a -standard configuration, either: - -* :doc:`controller_storage` - -* :doc:`dedicated_storage` - - -This guide assumes that you have a standard deployment installed and configured -with 2x controllers and at least 1x compute node, with the StarlingX OpenStack -application (stx-openstack) applied. - -.. toctree:: - :maxdepth: 1 - - ironic_hardware - ironic_install diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/ironic_hardware.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/ironic_hardware.rst deleted file mode 100644 index f63500a6e..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/ironic_hardware.rst +++ /dev/null @@ -1,51 +0,0 @@ -===================== -Hardware Requirements -===================== - -This section describes the hardware requirements and server preparation for a -**StarlingX R2.0 bare metal Ironic** deployment configuration. - -.. contents:: - :local: - :depth: 1 - ------------------------------ -Minimum hardware requirements ------------------------------ - -* One or more bare metal hosts as Ironic nodes as well as tenant instance node. - -* BMC support on bare metal host and controller node connectivity to the BMC IP - address of bare metal hosts. - -For controller nodes: - -* Additional NIC port on both controller nodes for connecting to the - ironic-provisioning-net. - -For compute nodes: - -* If using a flat data network for the Ironic provisioning network, an additional - NIC port on one of the compute nodes is required. - -* Alternatively, use a VLAN data network for the Ironic provisioning network and - simply add the new data network to an existing interface on the compute node. - -* Additional switch ports / configuration for new ports on controller, compute, - and Ironic nodes, for connectivity to the Ironic provisioning network. - ------------------------------------ -BMC configuration of Ironic node(s) ------------------------------------ - -Enable BMC and allocate a static IP, username, and password in the BIOS settings. -For example, set: - -IP address - 10.10.10.126 - -username - root - -password - test123 diff --git a/doc/source/deploy_install_guides/r2_release/bare_metal/ironic_install.rst b/doc/source/deploy_install_guides/r2_release/bare_metal/ironic_install.rst deleted file mode 100644 index 17ce389f2..000000000 --- a/doc/source/deploy_install_guides/r2_release/bare_metal/ironic_install.rst +++ /dev/null @@ -1,392 +0,0 @@ -================================ -Install Ironic on StarlingX R2.0 -================================ - -This section describes the steps to install Ironic on a standard configuration, -either: - -* **StarlingX R2.0 bare metal Standard with Controller Storage** deployment - configuration - -* **StarlingX R2.0 bare metal Standard with Dedicated Storage** deployment - configuration - -.. contents:: - :local: - :depth: 1 - ---------------------- -Enable Ironic service ---------------------- - -This section describes the pre-configuration required to enable the Ironic service. -All the commands in this section are for the StarlingX platform. - -First acquire administrative privileges: - -:: - - source /etc/platform/openrc - -******************************** -Download Ironic deployment image -******************************** - -The Ironic service requires a deployment image (kernel and ramdisk) which is -used to clean Ironic nodes and install the end-user's image. The cleaning done -by the deployment image wipes the disks and tests connectivity to the Ironic -conductor on the controller nodes via the Ironic Python Agent (IPA). - -The Ironic deployment Stein image (**Ironic-kernel** and **Ironic-ramdisk**) -can be found here: - -* `Ironic-kernel coreos_production_pxe-stable-stein.vmlinuz - `__ -* `Ironic-ramdisk coreos_production_pxe_image-oem-stable-stein.cpio.gz - `__ - - -******************************************************* -Configure Ironic network on deployed standard StarlingX -******************************************************* - -#. Add an address pool for the Ironic network. This example uses `ironic-pool`: - - :: - - system addrpool-add --ranges 10.10.20.1-10.10.20.100 ironic-pool 10.10.20.0 24 - -#. Add the Ironic platform network. This example uses `ironic-net`: - - :: - - system addrpool-list | grep ironic-pool | awk '{print$2}' | xargs system network-add ironic-net ironic false - -#. Add the Ironic tenant network. This example uses `ironic-data`: - - .. note:: - - The tenant network is not the same as the platform network described in - the previous step. You can specify any name for the tenant network other - than ‘ironic’. If the name 'ironic' is used, a user override must be - generated to indicate the tenant network name. - - Refer to section `Generate user Helm overrides`_ for details. - - :: - - system datanetwork-add ironic-data flat - -#. Configure the new interfaces (for Ironic) on controller nodes and assign - them to the platform network. Host must be locked. This example uses the - platform network `ironic-net` that was named in a previous step. - - These new interfaces to the controllers are used to connect to the Ironic - provisioning network: - - **controller-0** - - :: - - system interface-network-assign controller-0 enp2s0 ironic-net - system host-if-modify -n ironic -c platform \ - --ipv4-mode static --ipv4-pool ironic-pool controller-0 enp2s0 - - # Apply the OpenStack Ironic node labels - system host-label-assign controller-0 openstack-ironic=enabled - - # Unlock the node to apply changes - system host-unlock controller-0 - - - **controller-1** - - :: - - system interface-network-assign controller-1 enp2s0 ironic-net - system host-if-modify -n ironic -c platform \ - --ipv4-mode static --ipv4-pool ironic-pool controller-1 enp2s0 - - # Apply the OpenStack Ironic node labels - system host-label-assign controller-1 openstack-ironic=enabled - - # Unlock the node to apply changes - system host-unlock controller-1 - -#. Configure the new interface (for Ironic) on one of the compute nodes and - assign it to the Ironic data network. This example uses the data network - `ironic-data` that was named in a previous step. - - :: - - system interface-datanetwork-assign compute-0 eno1 ironic-data - system host-if-modify -n ironicdata -c data compute-0 eno1 - -**************************** -Generate user Helm overrides -**************************** - -Ironic Helm Charts are included in the stx-openstack application. By default, -Ironic is disabled. - -To enable Ironic, update the following Ironic Helm Chart attributes: - -:: - - system helm-override-update stx-openstack ironic openstack \ - --set network.pxe.neutron_subnet_alloc_start=10.10.20.10 \ - --set network.pxe.neutron_subnet_gateway=10.10.20.1 \ - --set network.pxe.neutron_provider_network=ironic-data - -:command:`network.pxe.neutron_subnet_alloc_start` sets the DHCP start IP to -Neutron for Ironic node provision, and reserves several IPs for the platform. - -If the data network name for Ironic is changed, modify -:command:`network.pxe.neutron_provider_network` to the command above: - -:: - - --set network.pxe.neutron_provider_network=ironic-data - -******************************* -Apply stx-openstack application -******************************* - -Re-apply the stx-openstack application to apply the changes to Ironic: - -:: - - system helm-chart-attribute-modify stx-openstack ironic openstack \ - --enabled true - - system application-apply stx-openstack - --------------------- -Start an Ironic node --------------------- - -All the commands in this section are for the OpenStack application with -administrative privileges. - -From a new shell as a root user, without sourcing ``/etc/platform/openrc``: - -:: - - mkdir -p /etc/openstack - - tee /etc/openstack/clouds.yaml << EOF - clouds: - openstack_helm: - region_name: RegionOne - identity_api_version: 3 - endpoint_type: internalURL - auth: - username: 'admin' - password: 'Li69nux*' - project_name: 'admin' - project_domain_name: 'default' - user_domain_name: 'default' - auth_url: 'http://keystone.openstack.svc.cluster.local/v3' - EOF - - export OS_CLOUD=openstack_helm - -******************** -Create Glance images -******************** - -#. Create the **ironic-kernel** image: - - :: - - openstack image create \ - --file ~/coreos_production_pxe-stable-stein.vmlinuz \ - --disk-format aki \ - --container-format aki \ - --public \ - ironic-kernel - -#. Create the **ironic-ramdisk** image: - - :: - - openstack image create \ - --file ~/coreos_production_pxe_image-oem-stable-stein.cpio.gz \ - --disk-format ari \ - --container-format ari \ - --public \ - ironic-ramdisk - -#. Create the end user application image (for example, CentOS): - - :: - - openstack image create \ - --file ~/CentOS-7-x86_64-GenericCloud-root.qcow2 \ - --public --disk-format \ - qcow2 --container-format bare centos - -********************* -Create an Ironic node -********************* - -#. Create a node: - - :: - - openstack baremetal node create --driver ipmi --name ironic-test0 - -#. Add IPMI information: - - :: - - openstack baremetal node set \ - --driver-info ipmi_address=10.10.10.126 \ - --driver-info ipmi_username=root \ - --driver-info ipmi_password=test123 \ - --driver-info ipmi_terminal_port=623 ironic-test0 - -#. Set `ironic-kernel` and `ironic-ramdisk` images driver information, - on this bare metal node: - - :: - - openstack baremetal node set \ - --driver-info deploy_kernel=$(openstack image list | grep ironic-kernel | awk '{print$2}') \ - --driver-info deploy_ramdisk=$(openstack image list | grep ironic-ramdisk | awk '{print$2}') \ - ironic-test0 - -#. Set resource properties on this bare metal node based on actual Ironic node - capacities: - - :: - - openstack baremetal node set \ - --property cpus=4 \ - --property cpu_arch=x86_64\ - --property capabilities="boot_option:local" \ - --property memory_mb=65536 \ - --property local_gb=400 \ - --resource-class bm ironic-test0 - -#. Add pxe_template location: - - :: - - openstack baremetal node set --driver-info \ - pxe_template='/var/lib/openstack/lib64/python2.7/site-packages/ironic/drivers/modules/ipxe_config.template' \ - ironic-test0 - -#. Create a port to identify the specific port used by the Ironic node. - Substitute **a4:bf:01:2b:3b:c8** with the MAC address for the Ironic node - port which connects to the Ironic network: - - :: - - openstack baremetal port create \ - --node $(openstack baremetal node list | grep ironic-test0 | awk '{print$2}') \ - --pxe-enabled true a4:bf:01:2b:3b:c8 - -#. Change node state to `manage`: - - :: - - openstack baremetal node manage ironic-test0 - -#. Make node available for deployment: - - :: - - openstack baremetal node provide ironic-test0 - -#. Wait for ironic-test0 provision-state: available: - - :: - - openstack baremetal node show ironic-test0 - ---------------------------------- -Deploy an instance on Ironic node ---------------------------------- - -All the commands in this section are for the OpenStack application, but this -time with *tenant* specific privileges. - -#. From a new shell as a root user, without sourcing ``/etc/platform/openrc``: - - :: - - mkdir -p /etc/openstack - - tee /etc/openstack/clouds.yaml << EOF - clouds: - openstack_helm: - region_name: RegionOne - identity_api_version: 3 - endpoint_type: internalURL - auth: - username: 'joeuser' - password: 'mypasswrd' - project_name: 'intel' - project_domain_name: 'default' - user_domain_name: 'default' - auth_url: 'http://keystone.openstack.svc.cluster.local/v3' - EOF - - export OS_CLOUD=openstack_helm - -#. Create flavor. - - Set resource CUSTOM_BM corresponding to **--resource-class bm**: - - :: - - openstack flavor create --ram 4096 --vcpus 4 --disk 400 \ - --property resources:CUSTOM_BM=1 \ - --property resources:VCPU=0 \ - --property resources:MEMORY_MB=0 \ - --property resources:DISK_GB=0 \ - --property capabilities:boot_option='local' \ - bm-flavor - - See `Adding scheduling information - `__ - and `Configure Nova flavors - `__ - for more information. - -#. Enable service - - List the compute services: - - :: - - openstack compute service list - - Set compute service properties: - - :: - - openstack compute service set --enable controller-0 nova-compute - -#. Create instance - - .. note:: - - The :command:`keypair create` command is optional. It is not required to - enable a bare metal instance. - - :: - - openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey - - - Create 2 new servers, one bare metal and one virtual: - - :: - - openstack server create --image centos --flavor bm-flavor \ - --network baremetal --key-name mykey bm - - openstack server create --image centos --flavor m1.small \ - --network baremetal --key-name mykey vm diff --git a/doc/source/deploy_install_guides/r2_release/desc_aio_duplex.txt b/doc/source/deploy_install_guides/r2_release/desc_aio_duplex.txt deleted file mode 100644 index 952f5836c..000000000 --- a/doc/source/deploy_install_guides/r2_release/desc_aio_duplex.txt +++ /dev/null @@ -1,23 +0,0 @@ -The All-in-one Duplex (AIO-DX) deployment option provides a pair of high -availability (HA) servers with each server providing all three cloud functions -(controller, compute, and storage). - -An AIO-DX configuration provides the following benefits: - -* Only a small amount of cloud processing and storage power is required -* Application consolidation using multiple virtual machines on a single pair of - physical servers -* High availability (HA) services run on the controller function across two - physical servers in either active/active or active/standby mode -* A storage back end solution using a two-node CEPH deployment across two servers -* Virtual machines scheduled on both compute functions -* Protection against overall server hardware fault, where - - * All controller HA services go active on the remaining healthy server - * All virtual machines are recovered on the remaining healthy server - -.. figure:: ../figures/starlingx-deployment-options-duplex.png - :scale: 50% - :alt: All-in-one Duplex deployment configuration - - *Figure 1: All-in-one Duplex deployment configuration* \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r2_release/desc_aio_simplex.txt b/doc/source/deploy_install_guides/r2_release/desc_aio_simplex.txt deleted file mode 100644 index b3bd342ef..000000000 --- a/doc/source/deploy_install_guides/r2_release/desc_aio_simplex.txt +++ /dev/null @@ -1,18 +0,0 @@ -The All-in-one Simplex (AIO-SX) deployment option provides all three cloud -functions (controller, compute, and storage) on a single server with the -following benefits: - -* Requires only a small amount of cloud processing and storage power -* Application consolidation using multiple virtual machines on a single pair of - physical servers -* A storage backend solution using a single-node CEPH deployment - -.. figure:: ../figures/starlingx-deployment-options-simplex.png - :scale: 50% - :alt: All-in-one Simplex deployment configuration - - *Figure 1: All-in-one Simplex deployment configuration* - -An AIO-SX deployment gives no protection against overall server hardware fault. -Hardware component protection can be enabled with, for example, a hardware RAID -or 2x Port LAG in the deployment. \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r2_release/desc_controller_storage.txt b/doc/source/deploy_install_guides/r2_release/desc_controller_storage.txt deleted file mode 100644 index cf53c35ad..000000000 --- a/doc/source/deploy_install_guides/r2_release/desc_controller_storage.txt +++ /dev/null @@ -1,22 +0,0 @@ -The Standard with Controller Storage deployment option provides two high -availability (HA) controller nodes and a pool of up to 10 compute nodes. - -A Standard with Controller Storage configuration provides the following benefits: - -* A pool of up to 10 compute nodes -* High availability (HA) services run across the controller nodes in either - active/active or active/standby mode -* A storage back end solution using a two-node CEPH deployment across two - controller servers -* Protection against overall controller and compute node failure, where - - * On overall controller node failure, all controller HA services go active on - the remaining healthy controller node - * On overall compute node failure, virtual machines and containers are - recovered on the remaining healthy compute nodes - -.. figure:: ../figures/starlingx-deployment-options-controller-storage.png - :scale: 50% - :alt: Standard with Controller Storage deployment configuration - - *Figure 1: Standard with Controller Storage deployment configuration* \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r2_release/desc_dedicated_storage.txt b/doc/source/deploy_install_guides/r2_release/desc_dedicated_storage.txt deleted file mode 100644 index ef41856fd..000000000 --- a/doc/source/deploy_install_guides/r2_release/desc_dedicated_storage.txt +++ /dev/null @@ -1,17 +0,0 @@ -The Standard with Dedicated Storage deployment option is a standard installation -with independent controller, compute, and storage nodes. - -A Standard with Dedicated Storage configuration provides the following benefits: - -* A pool of up to 100 compute nodes -* A 2x node high availability (HA) controller cluster with HA services running - across the controller nodes in either active/active or active/standby mode -* A storage back end solution using a two-to-9x node HA CEPH storage cluster - that supports a replication factor of two or three -* Up to four groups of 2x storage nodes, or up to three groups of 3x storage nodes - -.. figure:: ../figures/starlingx-deployment-options-dedicated-storage.png - :scale: 50% - :alt: Standard with Dedicated Storage deployment configuration - - *Figure 1: Standard with Dedicated Storage deployment configuration* \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r2_release/figures/starlingx-deployment-options-duplex.png b/doc/source/deploy_install_guides/r2_release/figures/starlingx-deployment-options-duplex.png deleted file mode 100644 index 1d7db9e7f..000000000 Binary files a/doc/source/deploy_install_guides/r2_release/figures/starlingx-deployment-options-duplex.png and /dev/null differ diff --git a/doc/source/deploy_install_guides/r2_release/index.rst b/doc/source/deploy_install_guides/r2_release/index.rst deleted file mode 100644 index 2dbf2c58e..000000000 --- a/doc/source/deploy_install_guides/r2_release/index.rst +++ /dev/null @@ -1,63 +0,0 @@ -=========================== -StarlingX R2.0 Installation -=========================== - -.. important:: - - Changes in the underlying StarlingX infrastructure have occurred - since the R2.0 release. Due to these changes, the R2.0 installation - instructions may not work as described. - - Installation of the current :ref:`latest_release` is recommended. - -StarlingX provides a pre-defined set of standard :doc:`deployment configurations -`. Most deployment options may be installed in a -virtual environment or on bare metal. - ------------------------------------------------------ -Install StarlingX Kubernetes in a virtual environment ------------------------------------------------------ - -.. toctree:: - :maxdepth: 1 - - virtual/aio_simplex - virtual/aio_duplex - virtual/controller_storage - virtual/dedicated_storage - ------------------------------------------- -Install StarlingX Kubernetes on bare metal ------------------------------------------- - -.. toctree:: - :maxdepth: 1 - - bare_metal/aio_simplex - bare_metal/aio_duplex - bare_metal/controller_storage - bare_metal/dedicated_storage - bare_metal/ironic - -.. toctree:: - :hidden: - - ansible_bootstrap_configs - ------------------ -Access Kubernetes ------------------ - -.. toctree:: - :maxdepth: 1 - - kubernetes_access - --------------------------- -Access StarlingX OpenStack --------------------------- - -.. toctree:: - :maxdepth: 1 - - openstack/index diff --git a/doc/source/deploy_install_guides/r2_release/kubernetes_access.rst b/doc/source/deploy_install_guides/r2_release/kubernetes_access.rst deleted file mode 100644 index 1231ef425..000000000 --- a/doc/source/deploy_install_guides/r2_release/kubernetes_access.rst +++ /dev/null @@ -1,181 +0,0 @@ -================================ -Access StarlingX Kubernetes R2.0 -================================ - -Use local/remote CLIs, GUIs, and/or REST APIs to access and manage StarlingX -Kubernetes and hosted containerized applications. - -.. contents:: - :local: - :depth: 1 - ----------- -Local CLIs ----------- - -In order to access the StarlingX and Kubernetes commands on controller-O, first -follow these steps: - -#. Log in to controller-0 via the console or SSH with a sysadmin/. - -#. Acquire Keystone admin and Kubernetes admin credentials: - - :: - - source /etc/platform/openrc - -********************************************* -StarlingX system and host management commands -********************************************* - -Access StarlingX system and host management commands using the :command:`system` -command. For example: - -:: - - system host-list - - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - +----+--------------+-------------+----------------+-------------+--------------+ - -Use the :command:`system help` command for the full list of options. - -*********************************** -StarlingX fault management commands -*********************************** - -Access StarlingX fault management commands using the :command:`fm` command, for example: - -:: - - fm alarm-list - -******************* -Kubernetes commands -******************* - -Access Kubernetes commands using the :command:`kubectl` command, for example: - -:: - - kubectl get nodes - - NAME STATUS ROLES AGE VERSION - controller-0 Ready master 5d19h v1.13.5 - -See https://kubernetes.io/docs/reference/kubectl/overview/ for details. - ------------ -Remote CLIs ------------ - -Documentation coming soon. - ---- -GUI ---- - -.. note:: - - For a virtual installation, run the browser on the host machine. - -********************* -StarlingX Horizon GUI -********************* - -Access the StarlingX Horizon GUI with the following steps: - -#. Enter the OAM floating IP address in your browser: - `\http://:8080` - - Discover your OAM floating IP address with the :command:`system oam-show` command. - -#. Log in to Horizon with an admin/. - -******************** -Kubernetes dashboard -******************** - -The Kubernetes dashboard is not installed by default. - -To install the Kubernetes dashboard, execute the following steps on controller-0: - -#. Use the kubernetes-dashboard helm chart from the stable helm repository with - the override values shown below: - - :: - - cat < dashboard-values.yaml - service: - type: NodePort - nodePort: 30000 - - rbac: - create: true - clusterAdminRole: true - - serviceAccount: - create: true - name: kubernetes-dashboard - EOF - - helm repo update - - helm install stable/kubernetes-dashboard --name dashboard -f dashboard-values.yaml - -#. Create an ``admin-user`` service account with ``cluster-admin`` privileges, and - display its token for logging into the Kubernetes dashboard. - - :: - - cat < admin-login.yaml - apiVersion: v1 - kind: ServiceAccount - metadata: - name: admin-user - namespace: kube-system - --- - apiVersion: rbac.authorization.k8s.io/v1 - kind: ClusterRoleBinding - metadata: - name: admin-user - roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: cluster-admin - subjects: - - kind: ServiceAccount - name: admin-user - namespace: kube-system - EOF - - kubectl apply -f admin-login.yaml - - kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}') - - -Access the Kubernetes dashboard GUI with the following steps: - -#. Enter the OAM floating IP address in your browser: - `\https://:30000`. - - Discover your OAM floating IP address with the :command:`system oam-show` command. - -#. Log in to the Kubernetes dashboard using the ``admin-user`` token. - ---------- -REST APIs ---------- - -List the StarlingX platform-related public REST API endpoints using the -following command: - -:: - - openstack endpoint list | grep public - -Use these URLs as the prefix for the URL target of StarlingX Platform Services' -REST API messages. diff --git a/doc/source/deploy_install_guides/r2_release/openstack/access.rst b/doc/source/deploy_install_guides/r2_release/openstack/access.rst deleted file mode 100644 index 19f6f91df..000000000 --- a/doc/source/deploy_install_guides/r2_release/openstack/access.rst +++ /dev/null @@ -1,273 +0,0 @@ -========================== -Access StarlingX OpenStack -========================== - -Use local/remote CLIs, GUIs and/or REST APIs to access and manage StarlingX -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= - -`` should be a fully qualified domain name that you own, such that -you can configure the DNS Server that owns `` with the OpenStack -service names underneath the domain. - -For example: -:: - - system service-parameter-add openstack helm endpoint_domain=my-starlingx-domain.my-company.com - system application-apply stx-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 - `: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 ---------- - -Access OpenStack using the local CLI with the following steps: - -#. Log in to controller-0 via the console or SSH with a sysadmin/. - *Do not use* source /etc/platform/openrc . - -#. Set the CLI context to the StarlingX OpenStack Cloud Application and set up - OpenStack admin credentials: - - :: - - sudo su - - mkdir -p /etc/openstack - tee /etc/openstack/clouds.yaml << EOF - clouds: - openstack_helm: - region_name: RegionOne - identity_api_version: 3 - endpoint_type: internalURL - auth: - username: 'admin' - password: '' - project_name: 'admin' - project_domain_name: 'default' - user_domain_name: 'default' - auth_url: 'http://keystone.openstack.svc.cluster.local/v3' - EOF - exit - - export OS_CLOUD=openstack_helm - -********************** -OpenStack CLI commands -********************** - -Access OpenStack CLI commands for the StarlingX OpenStack cloud application -using the :command:`openstack` command. For example: - -:: - - [sysadmin@controller-0 ~(keystone_admin)]$ openstack flavor list - [sysadmin@controller-0 ~(keystone_admin)]$ openstack image list - ----------- -Remote CLI ----------- - -Documentation coming soon. - ---- -GUI ---- - -Access the StarlingX containerized OpenStack Horizon GUI in your browser at the -following address: - -:: - - http://:31000 - -Log in to the Containerized OpenStack Horizon GUI with an admin/. - ---------- -REST APIs ---------- - -This section provides an overview of accessing REST APIs with examples of -`curl`-based REST API commands. - -**************** -Public endpoints -**************** - -Use the `Local CLI`_ to display OpenStack public REST API endpoints. For example: - -:: - - openstack endpoint list - -The public endpoints will look like: - -* `\http://keystone.openstack.svc.cluster.local:80/v3` -* `\http://nova.openstack.svc.cluster.local:80/v2.1/%(tenant_id)s` -* `\http://neutron.openstack.svc.cluster.local:80/` -* `etc.` - -If you have set a unique domain name, then the public endpoints will look like: - -* `\http://keystone.my-starlingx-domain.my-company.com:80/v3` -* `\http://nova.my-starlingx-domain.my-company.com:80/v2.1/%(tenant_id)s` -* `\http://neutron.my-starlingx-domain.my-company.com:80/` -* `etc.` - -Documentation for the OpenStack REST APIs is available at -`OpenStack API Documentation `_. - -*********** -Get a token -*********** - -The following command will request the Keystone token: - -:: - - curl -i -H "Content-Type: application/json" -d - '{ "auth": { - "identity": { - "methods": ["password"], - "password": { - "user": { - "name": "admin", - "domain": { "id": "default" }, - "password": "St8rlingX*" - } - } - }, - "scope": { - "project": { - "name": "admin", - "domain": { "id": "default" } - } - } - } - }' http://keystone.openstack.svc.cluster.local:80/v3/auth/tokens - -The token will be returned in the "X-Subject-Token" header field of the response: - -:: - - HTTP/1.1 201 CREATED - Date: Wed, 02 Oct 2019 18:27:38 GMT - Content-Type: application/json - Content-Length: 8128 - Connection: keep-alive - X-Subject-Token: gAAAAABdlOwafP71DXZjbyEf4gsNYA8ftso910S-RdJhg0fnqWuMGyMUhYUUJSossuUIitrvu2VXYXDNPbnaGzFveOoXxYTPlM6Fgo1aCl6wW85zzuXqT6AsxoCn95OMFhj_HHeYNPTkcyjbuW-HH_rJfhuUXt85iytZ_YAQQUfSXM7N3zAk7Pg - Vary: X-Auth-Token - x-openstack-request-id: req-d1bbe060-32f0-4cf1-ba1d-7b38c56b79fb - - {"token": {"is_domain": false, - - ... - -You can set an environment variable to hold the token value from the response. -For example: - -:: - - TOKEN=gAAAAABdlOwafP71DXZjbyEf4gsNYA8ftso910S - -***************** -List Nova flavors -***************** - -The following command will request a list of all Nova flavors: - -:: - - curl -i http://nova.openstack.svc.cluster.local:80/v2.1/flavors -X GET -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token:${TOKEN}" | tail -1 | python -m json.tool - -The list will be returned in the response. For example: - -:: - - % Total % Received % Xferd Average Speed Time Time Time Current - Dload Upload Total Spent Left Speed - 100 2529 100 2529 0 0 24187 0 --:--:-- --:--:-- --:--:-- 24317 - { - "flavors": [ - { - "id": "04cfe4e5-0d8c-49b3-ba94-54371e13ddce", - "links": [ - { - "href": "http://nova.openstack.svc.cluster.local/v2.1/flavors/04cfe4e5-0d8c-49b3-ba94-54371e13ddce", - "rel": "self" - }, - { - "href": "http://nova.openstack.svc.cluster.local/flavors/04cfe4e5-0d8c-49b3-ba94-54371e13ddce", - "rel": "bookmark" - } - ], - "name": "m1.tiny" - }, - { - "id": "14c725b1-1658-48ec-90e6-05048d269e89", - "links": [ - { - "href": "http://nova.openstack.svc.cluster.local/v2.1/flavors/14c725b1-1658-48ec-90e6-05048d269e89", - "rel": "self" - }, - { - "href": "http://nova.openstack.svc.cluster.local/flavors/14c725b1-1658-48ec-90e6-05048d269e89", - "rel": "bookmark" - } - ], - "name": "medium.dpdk" - }, - { - - ... - diff --git a/doc/source/deploy_install_guides/r2_release/openstack/install.rst b/doc/source/deploy_install_guides/r2_release/openstack/install.rst deleted file mode 100644 index 7f66478f4..000000000 --- a/doc/source/deploy_install_guides/r2_release/openstack/install.rst +++ /dev/null @@ -1,65 +0,0 @@ -=========================== -Install StarlingX OpenStack -=========================== - -These instructions assume that you have completed the following -OpenStack-specific configuration tasks that are required by the underlying -StarlingX Kubernetes platform: - -* All nodes have been labeled appropriately for their OpenStack role(s). -* The vSwitch type has been configured. -* The nova-local volume group has been configured on any node's host, if running - the compute function. - --------------------------------------------- -Install application manifest and helm-charts --------------------------------------------- - -#. Get the StarlingX OpenStack application (stx-openstack) manifest and helm-charts. - This can be from a private StarlingX build or, as shown below, from the public - Cengen StarlingX build off ``master`` branch: - - :: - - wget http://mirror.starlingx.cengn.ca/mirror/starlingx/release/2.0.0/centos/outputs/helm-charts/stx-openstack-1.0-17-centos-stable-latest.tgz - -#. Load the stx-openstack application's package into StarlingX. The tarball - package contains stx-openstack's Airship Armada manifest and stx-openstack's - set of helm charts: - - :: - - system application-upload stx-openstack-1.0-17-centos-stable-latest.tgz - - This will: - - * Load the Armada manifest and helm charts. - * Internally manage helm chart override values for each chart. - * Automatically generate system helm chart overrides for each chart based on - the current state of the underlying StarlingX Kubernetes platform and the - recommended StarlingX configuration of OpenStack services. - -#. Apply the stx-openstack application in order to bring StarlingX OpenStack into - service. - - :: - - system application-apply stx-openstack - -#. Wait for the activation of stx-openstack to complete. - - This can take 5-10 minutes depending on the performance of your host machine. - - Monitor progress with the command: - - :: - - watch -n 5 system application-list - ----------- -Next steps ----------- - -Your OpenStack cloud is now up and running. - -See :doc:`access` for details on how to access StarlingX OpenStack. diff --git a/doc/source/deploy_install_guides/r2_release/virtual/aio_duplex.rst b/doc/source/deploy_install_guides/r2_release/virtual/aio_duplex.rst deleted file mode 100644 index 74f1bab8f..000000000 --- a/doc/source/deploy_install_guides/r2_release/virtual/aio_duplex.rst +++ /dev/null @@ -1,21 +0,0 @@ -=========================================== -Virtual All-in-one Duplex Installation R2.0 -=========================================== - --------- -Overview --------- - -.. include:: ../desc_aio_duplex.txt - -.. include:: ../ipv6_note.txt - ------------- -Installation ------------- - -.. toctree:: - :maxdepth: 1 - - aio_duplex_environ - aio_duplex_install_kubernetes diff --git a/doc/source/deploy_install_guides/r2_release/virtual/aio_duplex_environ.rst b/doc/source/deploy_install_guides/r2_release/virtual/aio_duplex_environ.rst deleted file mode 100644 index 95b389425..000000000 --- a/doc/source/deploy_install_guides/r2_release/virtual/aio_duplex_environ.rst +++ /dev/null @@ -1,53 +0,0 @@ -============================ -Prepare Host and Environment -============================ - -This section describes how to prepare the physical host and virtual environment -for a **StarlingX R2.0 virtual All-in-one Duplex** deployment configuration. - -.. contents:: - :local: - :depth: 1 - ------------------------------------- -Physical host requirements and setup ------------------------------------- - -.. include:: physical_host_req.txt - ---------------------------------------- -Prepare virtual environment and servers ---------------------------------------- - -The following steps explain how to prepare the virtual environment and servers -on a physical host for a StarlingX R2.0 virtual All-in-one Duplex deployment -configuration. - -#. Prepare virtual environment. - - Set up the virtual platform networks for virtual deployment: - - :: - - bash setup_network.sh - -#. Prepare virtual servers. - - Create the XML definitions for the virtual servers required by this - configuration option. This will create the XML virtual server definition for: - - * duplex-controller-0 - * duplex-controller-1 - - The following command will start/virtually power on: - - * The 'duplex-controller-0' virtual server - * The X-based graphical virt-manager application - - :: - - bash setup_configuration.sh -c duplex -i ./bootimage.iso - - If there is no X-server present errors will occur and the X-based GUI for the - virt-manager application will not start. The virt-manager GUI is not absolutely - required and you can safely ignore errors and continue. \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r2_release/virtual/aio_duplex_install_kubernetes.rst b/doc/source/deploy_install_guides/r2_release/virtual/aio_duplex_install_kubernetes.rst deleted file mode 100644 index 920a9afa8..000000000 --- a/doc/source/deploy_install_guides/r2_release/virtual/aio_duplex_install_kubernetes.rst +++ /dev/null @@ -1,423 +0,0 @@ -============================================== -Install StarlingX Kubernetes on Virtual AIO-DX -============================================== - -This section describes the steps to install the StarlingX Kubernetes platform -on a **StarlingX R2.0 virtual All-in-one Duplex** deployment configuration. - -.. contents:: - :local: - :depth: 1 - --------------------------------- -Install software on controller-0 --------------------------------- - -In the last step of :doc:`aio_duplex_environ`, the controller-0 virtual server 'duplex-controller-0' was started by the :command:`setup_configuration.sh` command. - -On the host, attach to the console of virtual controller-0 and select the appropriate -installer menu options to start the non-interactive install of -StarlingX software on controller-0. - -.. note:: - - When entering the console, it is very easy to miss the first installer menu - selection. Use ESC to navigate to previous menus, to ensure you are at the - first installer menu. - -:: - - virsh console duplex-controller-0 - -Make the following menu selections in the installer: - -#. First menu: Select 'All-in-one Controller Configuration' -#. Second menu: Select 'Serial Console' -#. Third menu: Select 'Standard Security Profile' - -Wait for the non-interactive install of software to complete and for the server -to reboot. This can take 5-10 minutes, depending on the performance of the host -machine. - --------------------------------- -Bootstrap system on controller-0 --------------------------------- - -On virtual controller-0: - -#. Log in using the username / password of "sysadmin" / "sysadmin". - When logging in for the first time, you will be forced to change the password. - - :: - - Login: sysadmin - Password: - Changing password for sysadmin. - (current) UNIX Password: sysadmin - New Password: - (repeat) New Password: - -#. External connectivity is required to run the Ansible bootstrap playbook. - - :: - - export CONTROLLER0_OAM_CIDR=10.10.10.3/24 - export DEFAULT_OAM_GATEWAY=10.10.10.1 - sudo ip address add $CONTROLLER0_OAM_CIDR dev enp7s1 - sudo ip link set up dev enp7s1 - sudo ip route add default via $DEFAULT_OAM_GATEWAY dev enp7s1 - -#. Specify user configuration overrides for the Ansible bootstrap playbook. - - Ansible is used to bootstrap StarlingX on controller-0. Key files for Ansible - configuration are: - - ``/etc/ansible/hosts`` - The default Ansible inventory file. Contains a single host: localhost. - - ``/usr/share/ansible/stx-ansible/playbooks/bootstrap/bootstrap.yml`` - The Ansible bootstrap playbook. - - ``/usr/share/ansible/stx-ansible/playbooks/host_vars/bootstrap/default.yml`` - The default configuration values for the bootstrap playbook. - - sysadmin home directory ($HOME) - The default location where Ansible looks for and imports user - configuration override files for hosts. For example: ``$HOME/.yml``. - - - Specify the user configuration override file for the Ansible bootstrap - playbook using one of the following methods: - - * Copy the default.yml file listed above to ``$HOME/localhost.yml`` and edit - the configurable values as desired (use the commented instructions in - the file). - - or - - * Create the minimal user configuration override file as shown in the example - below: - - :: - - cd ~ - cat < localhost.yml - system_mode: duplex - - dns_servers: - - 8.8.8.8 - - 8.8.4.4 - - external_oam_subnet: 10.10.10.0/24 - external_oam_gateway_address: 10.10.10.1 - external_oam_floating_address: 10.10.10.2 - external_oam_node_0_address: 10.10.10.3 - external_oam_node_1_address: 10.10.10.4 - - admin_username: admin - admin_password: - ansible_become_pass: - EOF - - Refer to :doc:`/deploy_install_guides/r2_release/ansible_bootstrap_configs` - for information on additional Ansible bootstrap configurations for advanced - Ansible bootstrap scenarios. - -#. Run the Ansible bootstrap playbook: - - :: - - ansible-playbook /usr/share/ansible/stx-ansible/playbooks/bootstrap/bootstrap.yml - - Wait for Ansible bootstrap playbook to complete. - This can take 5-10 minutes, depending on the performance of the host machine. - ----------------------- -Configure controller-0 ----------------------- - -On virtual controller-0: - -#. Acquire admin credentials: - - :: - - source /etc/platform/openrc - -#. Configure the OAM and MGMT interfaces of controller-0 and specify the - attached networks: - - :: - - OAM_IF=enp7s1 - MGMT_IF=enp7s2 - system host-if-modify controller-0 lo -c none - IFNET_UUIDS=$(system interface-network-list controller-0 | awk '{if ($6=="lo") print $4;}') - for UUID in $IFNET_UUIDS; do - system interface-network-remove ${UUID} - done - system host-if-modify controller-0 $OAM_IF -c platform - system interface-network-assign controller-0 $OAM_IF oam - system host-if-modify controller-0 $MGMT_IF -c platform - system interface-network-assign controller-0 $MGMT_IF mgmt - system interface-network-assign controller-0 $MGMT_IF cluster-host - -#. Configure NTP Servers for network time synchronization: - - .. note:: - - In a virtual environment, this can sometimes cause Ceph clock skew alarms. - Also, the virtual instances clock is synchronized with the host clock, - so it is not absolutely required to configure NTP in this step. - - :: - - system ntp-modify ntpservers=0.pool.ntp.org,1.pool.ntp.org - -#. Configure data interfaces for controller-0. - - .. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - - 1G Huge Pages are not supported in the virtual environment and there is no - virtual NIC supporting SRIOV. For that reason, data interfaces are not - applicable in the virtual environment for the Kubernetes-only scenario. - - For OpenStack only: - - :: - - DATA0IF=eth1000 - DATA1IF=eth1001 - export COMPUTE=controller-0 - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - system host-port-list ${COMPUTE} --nowrap > ${SPL} - system host-if-list -a ${COMPUTE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - system host-if-modify -m 1500 -n data0 -c data ${COMPUTE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${COMPUTE} ${DATA1IFUUID} - system interface-datanetwork-assign ${COMPUTE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${COMPUTE} ${DATA1IFUUID} ${PHYSNET1} - -#. Add an OSD on controller-0 for Ceph: - - :: - - system host-disk-list controller-0 - system host-disk-list controller-0 | awk '/\/dev\/sdb/{print $2}' | xargs -i system host-stor-add controller-0 {} - system host-stor-list controller-0 - -************************************* -OpenStack-specific host configuration -************************************* - -.. include:: aio_simplex_install_kubernetes.rst - :start-after: incl-config-controller-0-openstack-specific-aio-simplex-start: - :end-before: incl-config-controller-0-openstack-specific-aio-simplex-end: - -------------------- -Unlock controller-0 -------------------- - -Unlock virtual controller-0 to bring it into service: - -:: - - system host-unlock controller-0 - -Controller-0 will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host machine. - -------------------------------------- -Install software on controller-1 node -------------------------------------- - -#. On the host, power on the controller-1 virtual server, 'duplex-controller-1'. It will - automatically attempt to network boot over the management network: - - :: - - virsh start duplex-controller-1 - -#. Attach to the console of virtual controller-1: - - :: - - virsh console duplex-controller-1 - - As controller-1 VM boots, a message appears on its console instructing you to - configure the personality of the node. - -#. On the console of virtual controller-0, list hosts to see the newly discovered - controller-1 host (hostname=None): - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. On virtual controller-0, using the host id, set the personality of this host - to 'controller': - - :: - - system host-update 2 personality=controller - -#. Wait for the software installation on controller-1 to complete, controller-1 to - reboot, and controller-1 to show as locked/disabled/online in 'system host-list'. - This can take 5-10 minutes, depending on the performance of the host machine. - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - ----------------------- -Configure controller-1 ----------------------- - -On virtual controller-0: - -#. Configure the OAM and MGMT interfaces of controller-1 and specify the - attached networks. Note that the MGMT interface is partially set up - automatically by the network install procedure. - - :: - - OAM_IF=enp7s1 - system host-if-modify controller-1 $OAM_IF -c platform - system interface-network-assign controller-1 $OAM_IF oam - system interface-network-assign controller-1 mgmt0 cluster-host - -#. Configure data interfaces for controller-1. - - .. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - - 1G Huge Pages are not supported in the virtual environment and there is no - virtual NIC supporting SRIOV. For that reason, data interfaces are not - applicable in the virtual environment for the Kubernetes-only scenario. - - For OpenStack only: - - :: - - DATA0IF=eth1000 - DATA1IF=eth1001 - export COMPUTE=controller-1 - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - system host-port-list ${COMPUTE} --nowrap > ${SPL} - system host-if-list -a ${COMPUTE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - system host-if-modify -m 1500 -n data0 -c data ${COMPUTE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${COMPUTE} ${DATA1IFUUID} - system interface-datanetwork-assign ${COMPUTE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${COMPUTE} ${DATA1IFUUID} ${PHYSNET1} - -#. Add an OSD on controller-1 for Ceph: - - :: - - echo ">>> Add OSDs to primary tier" - system host-disk-list controller-1 - system host-disk-list controller-1 | awk '/\/dev\/sdb/{print $2}' | xargs -i system host-stor-add controller-1 {} - system host-stor-list controller-1 - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to controller-1 in - support of installing the stx-openstack manifest/helm-charts later: - - :: - - system host-label-assign controller-1 openstack-control-plane=enabled - system host-label-assign controller-1 openstack-compute-node=enabled - system host-label-assign controller-1 openvswitch=enabled - system host-label-assign controller-1 sriov=enabled - -#. **For OpenStack only:** Set up disk partition for nova-local volume group, - which is needed for stx-openstack nova ephemeral disks: - - :: - - export COMPUTE=controller-1 - - echo ">>> Getting root disk info" - ROOT_DISK=$(system host-show ${COMPUTE} | grep rootfs | awk '{print $4}') - ROOT_DISK_UUID=$(system host-disk-list ${COMPUTE} --nowrap | grep ${ROOT_DISK} | awk '{print $2}') - echo "Root disk: $ROOT_DISK, UUID: $ROOT_DISK_UUID" - - echo ">>>> Configuring nova-local" - NOVA_SIZE=34 - NOVA_PARTITION=$(system host-disk-partition-add -t lvm_phys_vol ${COMPUTE} ${ROOT_DISK_UUID} ${NOVA_SIZE}) - NOVA_PARTITION_UUID=$(echo ${NOVA_PARTITION} | grep -ow "| uuid | [a-z0-9\-]* |" | awk '{print $4}') - system host-lvg-add ${COMPUTE} nova-local - system host-pv-add ${COMPUTE} nova-local ${NOVA_PARTITION_UUID} - -------------------- -Unlock controller-1 -------------------- - -Unlock virtual controller-1 in order to bring it into service: - -:: - - system host-unlock controller-1 - -Controller-1 will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host machine. - ----------- -Next steps ----------- - -.. include:: ../kubernetes_install_next.txt diff --git a/doc/source/deploy_install_guides/r2_release/virtual/aio_simplex.rst b/doc/source/deploy_install_guides/r2_release/virtual/aio_simplex.rst deleted file mode 100644 index a016b91d7..000000000 --- a/doc/source/deploy_install_guides/r2_release/virtual/aio_simplex.rst +++ /dev/null @@ -1,21 +0,0 @@ -============================================ -Virtual All-in-one Simplex Installation R2.0 -============================================ - --------- -Overview --------- - -.. include:: ../desc_aio_simplex.txt - -.. include:: ../ipv6_note.txt - ------------- -Installation ------------- - -.. toctree:: - :maxdepth: 1 - - aio_simplex_environ - aio_simplex_install_kubernetes diff --git a/doc/source/deploy_install_guides/r2_release/virtual/aio_simplex_environ.rst b/doc/source/deploy_install_guides/r2_release/virtual/aio_simplex_environ.rst deleted file mode 100644 index 49e7ad9e4..000000000 --- a/doc/source/deploy_install_guides/r2_release/virtual/aio_simplex_environ.rst +++ /dev/null @@ -1,52 +0,0 @@ -============================ -Prepare Host and Environment -============================ - -This section describes how to prepare the physical host and virtual environment -for a **StarlingX R2.0 virtual All-in-one Simplex** deployment configuration. - -.. contents:: - :local: - :depth: 1 - ------------------------------------- -Physical host requirements and setup ------------------------------------- - -.. include:: physical_host_req.txt - ---------------------------------------- -Prepare virtual environment and servers ---------------------------------------- - -The following steps explain how to prepare the virtual environment and servers -on a physical host for a StarlingX R2.0 virtual All-in-one Simplex deployment -configuration. - -#. Prepare virtual environment. - - Set up the virtual platform networks for virtual deployment: - - :: - - bash setup_network.sh - -#. Prepare virtual servers. - - Create the XML definitions for the virtual servers required by this - configuration option. This will create the XML virtual server definition for: - - * simplex-controller-0 - - The following command will start/virtually power on: - - * The 'simplex-controller-0' virtual server - * The X-based graphical virt-manager application - - :: - - bash setup_configuration.sh -c simplex -i ./bootimage.iso - - If there is no X-server present errors will occur and the X-based GUI for the - virt-manager application will not start. The virt-manager GUI is not absolutely - required and you can safely ignore errors and continue. diff --git a/doc/source/deploy_install_guides/r2_release/virtual/aio_simplex_install_kubernetes.rst b/doc/source/deploy_install_guides/r2_release/virtual/aio_simplex_install_kubernetes.rst deleted file mode 100644 index 977c11c00..000000000 --- a/doc/source/deploy_install_guides/r2_release/virtual/aio_simplex_install_kubernetes.rst +++ /dev/null @@ -1,284 +0,0 @@ -============================================== -Install StarlingX Kubernetes on Virtual AIO-SX -============================================== - -This section describes the steps to install the StarlingX Kubernetes platform -on a **StarlingX R2.0 virtual All-in-one Simplex** deployment configuration. - -.. contents:: - :local: - :depth: 1 - --------------------------------- -Install software on controller-0 --------------------------------- - -In the last step of :doc:`aio_simplex_environ`, the controller-0 virtual server 'simplex-controller-0' was started by the :command:`setup_configuration.sh` command. - -On the host, attach to the console of virtual controller-0 and select the -appropriate installer menu options to start the non-interactive install of -StarlingX software on controller-0. - -.. note:: - - When entering the console, it is very easy to miss the first installer menu - selection. Use ESC to navigate to previous menus, to ensure you are at the - first installer menu. - -:: - - virsh console simplex-controller-0 - -Make the following menu selections in the installer: - -#. First menu: Select 'All-in-one Controller Configuration' -#. Second menu: Select 'Serial Console' -#. Third menu: Select 'Standard Security Profile' - -Wait for the non-interactive install of software to complete and for the server -to reboot. This can take 5-10 minutes, depending on the performance of the host -machine. - --------------------------------- -Bootstrap system on controller-0 --------------------------------- - -On virtual controller-0: - -#. Log in using the username / password of "sysadmin" / "sysadmin". - When logging in for the first time, you will be forced to change the password. - - :: - - Login: sysadmin - Password: - Changing password for sysadmin. - (current) UNIX Password: sysadmin - New Password: - (repeat) New Password: - -#. External connectivity is required to run the Ansible bootstrap playbook. - - :: - - export CONTROLLER0_OAM_CIDR=10.10.10.3/24 - export DEFAULT_OAM_GATEWAY=10.10.10.1 - sudo ip address add $CONTROLLER0_OAM_CIDR dev enp7s1 - sudo ip link set up dev enp7s1 - sudo ip route add default via $DEFAULT_OAM_GATEWAY dev enp7s1 - -#. Specify user configuration overrides for the Ansible bootstrap playbook. - - Ansible is used to bootstrap StarlingX on controller-0. Key files for Ansible - configuration are: - - ``/etc/ansible/hosts`` - The default Ansible inventory file. Contains a single host: localhost. - - ``/usr/share/ansible/stx-ansible/playbooks/bootstrap/bootstrap.yml`` - The Ansible bootstrap playbook. - - ``/usr/share/ansible/stx-ansible/playbooks/host_vars/bootstrap/default.yml`` - The default configuration values for the bootstrap playbook. - - sysadmin home directory ($HOME) - The default location where Ansible looks for and imports user - configuration override files for hosts. For example: ``$HOME/.yml``. - - - Specify the user configuration override file for the Ansible bootstrap - playbook using one of the following methods: - - * Copy the default.yml file listed above to ``$HOME/localhost.yml`` and edit - the configurable values as desired (use the commented instructions in - the file). - - or - - * Create the minimal user configuration override file as shown in the example - below: - - :: - - cd ~ - cat < localhost.yml - system_mode: simplex - - dns_servers: - - 8.8.8.8 - - 8.8.4.4 - - external_oam_subnet: 10.10.10.0/24 - external_oam_gateway_address: 10.10.10.1 - external_oam_floating_address: 10.10.10.2 - - admin_username: admin - admin_password: - ansible_become_pass: - EOF - - Refer to :doc:`/deploy_install_guides/r2_release/ansible_bootstrap_configs` - for information on additional Ansible bootstrap configurations for advanced - Ansible bootstrap scenarios. - -#. Run the Ansible bootstrap playbook: - - :: - - ansible-playbook /usr/share/ansible/stx-ansible/playbooks/bootstrap/bootstrap.yml - - Wait for Ansible bootstrap playbook to complete. - This can take 5-10 minutes, depending on the performance of the host machine. - ----------------------- -Configure controller-0 ----------------------- - -On virtual controller-0: - -#. Acquire admin credentials: - - :: - - source /etc/platform/openrc - -#. Configure the OAM interface of controller-0 and specify the attached network - as "oam". Use the OAM port name, for example eth0, that is applicable to your - deployment environment: - - :: - - OAM_IF=enp7s1 - system host-if-modify controller-0 $OAM_IF -c platform - system interface-network-assign controller-0 $OAM_IF oam - -#. Configure NTP Servers for network time synchronization: - - .. note:: - - In a virtual environment, this can sometimes cause Ceph clock skew alarms. - Also, the virtual instances clock is synchronized with the host clock, - so it is not absolutely required to configure NTP in this step. - - :: - - system ntp-modify ntpservers=0.pool.ntp.org,1.pool.ntp.org - -#. Configure data interfaces for controller-0. - - .. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - - 1G Huge Pages are not supported in the virtual environment and there is no - virtual NIC supporting SRIOV. For that reason, data interfaces are not - applicable in the virtual environment for the Kubernetes-only scenario. - - For OpenStack only: - - :: - - DATA0IF=eth1000 - DATA1IF=eth1001 - export COMPUTE=controller-0 - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - system host-port-list ${COMPUTE} --nowrap > ${SPL} - system host-if-list -a ${COMPUTE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - system host-if-modify -m 1500 -n data0 -c data ${COMPUTE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${COMPUTE} ${DATA1IFUUID} - system interface-datanetwork-assign ${COMPUTE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${COMPUTE} ${DATA1IFUUID} ${PHYSNET1} - -#. Add an OSD on controller-0 for Ceph: - - :: - - system host-disk-list controller-0 - system host-disk-list controller-0 | awk '/\/dev\/sdb/{print $2}' | xargs -i system host-stor-add controller-0 {} - system host-stor-list controller-0 - -************************************* -OpenStack-specific host configuration -************************************* - -.. incl-config-controller-0-openstack-specific-aio-simplex-start: - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to controller-0 in - support of installing the stx-openstack manifest/helm-charts later. - - :: - - system host-label-assign controller-0 openstack-control-plane=enabled - system host-label-assign controller-0 openstack-compute-node=enabled - system host-label-assign controller-0 openvswitch=enabled - system host-label-assign controller-0 sriov=enabled - -#. **For OpenStack only:** A vSwitch is required. - - The default vSwitch is containerized OVS that is packaged with the - stx-openstack manifest/helm-charts. StarlingX provides the option to use - OVS-DPDK on the host, however, in the virtual environment OVS-DPDK is NOT - supported, only OVS is supported. Therefore, simply use the default OVS - vSwitch here. - -#. **For OpenStack Only:** Set up disk partition for nova-local volume group, - which is needed for stx-openstack nova ephemeral disks. - - :: - - export COMPUTE=controller-0 - - echo ">>> Getting root disk info" - ROOT_DISK=$(system host-show ${COMPUTE} | grep rootfs | awk '{print $4}') - ROOT_DISK_UUID=$(system host-disk-list ${COMPUTE} --nowrap | grep ${ROOT_DISK} | awk '{print $2}') - echo "Root disk: $ROOT_DISK, UUID: $ROOT_DISK_UUID" - - echo ">>>> Configuring nova-local" - NOVA_SIZE=34 - NOVA_PARTITION=$(system host-disk-partition-add -t lvm_phys_vol ${COMPUTE} ${ROOT_DISK_UUID} ${NOVA_SIZE}) - NOVA_PARTITION_UUID=$(echo ${NOVA_PARTITION} | grep -ow "| uuid | [a-z0-9\-]* |" | awk '{print $4}') - system host-lvg-add ${COMPUTE} nova-local - system host-pv-add ${COMPUTE} nova-local ${NOVA_PARTITION_UUID} - sleep 2 - -.. incl-config-controller-0-openstack-specific-aio-simplex-end: - -------------------- -Unlock controller-0 -------------------- - -Unlock virtual controller-0 to bring it into service: - -:: - - system host-unlock controller-0 - -Controller-0 will reboot to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host machine. - ----------- -Next steps ----------- - -.. include:: ../kubernetes_install_next.txt \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r2_release/virtual/controller_storage_environ.rst b/doc/source/deploy_install_guides/r2_release/virtual/controller_storage_environ.rst deleted file mode 100644 index 83d13c89e..000000000 --- a/doc/source/deploy_install_guides/r2_release/virtual/controller_storage_environ.rst +++ /dev/null @@ -1,56 +0,0 @@ -============================ -Prepare Host and Environment -============================ - -This section describes how to prepare the physical host and virtual environment -for a **StarlingX R2.0 virtual Standard with Controller Storage** deployment -configuration. - -.. contents:: - :local: - :depth: 1 - ------------------------------------- -Physical host requirements and setup ------------------------------------- - -.. include:: physical_host_req.txt - ---------------------------------------- -Prepare virtual environment and servers ---------------------------------------- - -The following steps explain how to prepare the virtual environment and servers -on a physical host for a StarlingX R2.0 virtual Standard with Controller Storage -deployment configuration. - -#. Prepare virtual environment. - - Set up virtual platform networks for virtual deployment: - - :: - - bash setup_network.sh - -#. Prepare virtual servers. - - Create the XML definitions for the virtual servers required by this - configuration option. This will create the XML virtual server definition for: - - * controllerstorage-controller-0 - * controllerstorage-controller-1 - * controllerstorage-worker-0 - * controllerstorage-worker-1 - - The following command will start/virtually power on: - - * The 'controllerstorage-controller-0' virtual server - * The X-based graphical virt-manager application - - :: - - bash setup_configuration.sh -c controllerstorage -i ./bootimage.iso - - If there is no X-server present errors will occur and the X-based GUI for the - virt-manager application will not start. The virt-manager GUI is not absolutely - required and you can safely ignore errors and continue. \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r2_release/virtual/controller_storage_install_kubernetes.rst b/doc/source/deploy_install_guides/r2_release/virtual/controller_storage_install_kubernetes.rst deleted file mode 100644 index 1e8f6d4ef..000000000 --- a/doc/source/deploy_install_guides/r2_release/virtual/controller_storage_install_kubernetes.rst +++ /dev/null @@ -1,550 +0,0 @@ -======================================================================== -Install StarlingX Kubernetes on Virtual Standard with Controller Storage -======================================================================== - -This section describes the steps to install the StarlingX Kubernetes platform -on a **StarlingX R2.0 virtual Standard with Controller Storage** deployment -configuration. - -.. contents:: - :local: - :depth: 1 - --------------------------------- -Install software on controller-0 --------------------------------- - -In the last step of :doc:`controller_storage_environ`, the controller-0 virtual -server 'controllerstorage-controller-0' was started by the -:command:`setup_configuration.sh` command. - -On the host, attach to the console of virtual controller-0 and select the appropriate -installer menu options to start the non-interactive install of -StarlingX software on controller-0. - -.. note:: - - When entering the console, it is very easy to miss the first installer menu - selection. Use ESC to navigate to previous menus, to ensure you are at the - first installer menu. - -:: - - virsh console controllerstorage-controller-0 - -Make the following menu selections in the installer: - -#. First menu: Select 'Standard Controller Configuration' -#. Second menu: Select 'Serial Console' -#. Third menu: Select 'Standard Security Profile' - -Wait for the non-interactive install of software to complete and for the server -to reboot. This can take 5-10 minutes depending on the performance of the host -machine. - --------------------------------- -Bootstrap system on controller-0 --------------------------------- - -.. incl-bootstrap-controller-0-virt-controller-storage-start: - -On virtual controller-0: - -#. Log in using the username / password of "sysadmin" / "sysadmin". - When logging in for the first time, you will be forced to change the password. - - :: - - Login: sysadmin - Password: - Changing password for sysadmin. - (current) UNIX Password: sysadmin - New Password: - (repeat) New Password: - -#. External connectivity is required to run the Ansible bootstrap playbook: - - :: - - export CONTROLLER0_OAM_CIDR=10.10.10.3/24 - export DEFAULT_OAM_GATEWAY=10.10.10.1 - sudo ip address add $CONTROLLER0_OAM_CIDR dev enp7s1 - sudo ip link set up dev enp7s1 - sudo ip route add default via $DEFAULT_OAM_GATEWAY dev enp7s1 - -#. Specify user configuration overrides for the Ansible bootstrap playbook. - - Ansible is used to bootstrap StarlingX on controller-0. Key files for Ansible - configuration are: - - ``/etc/ansible/hosts`` - The default Ansible inventory file. Contains a single host: localhost. - - ``/usr/share/ansible/stx-ansible/playbooks/bootstrap/bootstrap.yml`` - The Ansible bootstrap playbook. - - ``/usr/share/ansible/stx-ansible/playbooks/host_vars/bootstrap/default.yml`` - The default configuration values for the bootstrap playbook. - - sysadmin home directory ($HOME) - The default location where Ansible looks for and imports user - configuration override files for hosts. For example: ``$HOME/.yml``. - - - Specify the user configuration override file for the Ansible bootstrap - playbook using one of the following methods: - - * Copy the default.yml file listed above to ``$HOME/localhost.yml`` and edit - the configurable values as desired (use the commented instructions in - the file). - - or - - * Create the minimal user configuration override file as shown in the example - below: - - :: - - cd ~ - cat < localhost.yml - system_mode: duplex - - dns_servers: - - 8.8.8.8 - - 8.8.4.4 - - external_oam_subnet: 10.10.10.0/24 - external_oam_gateway_address: 10.10.10.1 - external_oam_floating_address: 10.10.10.2 - external_oam_node_0_address: 10.10.10.3 - external_oam_node_1_address: 10.10.10.4 - - admin_username: admin - admin_password: - ansible_become_pass: - EOF - - Refer to :doc:`/deploy_install_guides/r2_release/ansible_bootstrap_configs` - for information on additional Ansible bootstrap configurations for advanced - Ansible bootstrap scenarios. - -#. Run the Ansible bootstrap playbook: - - :: - - ansible-playbook /usr/share/ansible/stx-ansible/playbooks/bootstrap/bootstrap.yml - - Wait for Ansible bootstrap playbook to complete. - This can take 5-10 minutes, depending on the performance of the host machine. - -.. incl-bootstrap-controller-0-virt-controller-storage-end: - ----------------------- -Configure controller-0 ----------------------- - -.. incl-config-controller-0-virt-controller-storage-start: - -On virtual controller-0: - -#. Acquire admin credentials: - - :: - - source /etc/platform/openrc - -#. Configure the OAM and MGMT interfaces of controller-0 and specify the - attached networks: - - :: - - OAM_IF=enp7s1 - MGMT_IF=enp7s2 - system host-if-modify controller-0 lo -c none - IFNET_UUIDS=$(system interface-network-list controller-0 | awk '{if ($6=="lo") print $4;}') - for UUID in $IFNET_UUIDS; do - system interface-network-remove ${UUID} - done - system host-if-modify controller-0 $OAM_IF -c platform - system interface-network-assign controller-0 $OAM_IF oam - system host-if-modify controller-0 $MGMT_IF -c platform - system interface-network-assign controller-0 $MGMT_IF mgmt - system interface-network-assign controller-0 $MGMT_IF cluster-host - -#. Configure NTP Servers for network time synchronization: - - .. note:: - - In a virtual environment, this can sometimes cause Ceph clock skew alarms. - Also, the virtual instance clock is synchronized with the host clock, - so it is not absolutely required to configure NTP here. - - :: - - system ntp-modify ntpservers=0.pool.ntp.org,1.pool.ntp.org - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to controller-0 in - support of installing the stx-openstack manifest/helm-charts later: - - :: - - system host-label-assign controller-0 openstack-control-plane=enabled - -#. **For OpenStack only:** A vSwitch is required. - - The default vSwitch is containerized OVS that is packaged with the - stx-openstack manifest/helm-charts. StarlingX provides the option to use - OVS-DPDK on the host, however, in the virtual environment OVS-DPDK is NOT - supported, only OVS is supported. Therefore, simply use the default OVS - vSwitch here. - -.. incl-config-controller-0-virt-controller-storage-end: - -------------------- -Unlock controller-0 -------------------- - -Unlock virtual controller-0 in order to bring it into service: - -:: - - system host-unlock controller-0 - -Controller-0 will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host machine. - --------------------------------------------------- -Install software on controller-1 and compute nodes --------------------------------------------------- - -#. On the host, power on the controller-1 virtual server, - 'controllerstorage-controller-1'. It will automatically attempt to network - boot over the management network: - - :: - - virsh start controllerstorage-controller-1 - -#. Attach to the console of virtual controller-1: - - :: - - virsh console controllerstorage-controller-1 - - As controller-1 VM boots, a message appears on its console instructing you to - configure the personality of the node. - -#. On console of virtual controller-0, list hosts to see the newly discovered - controller-1 host (hostname=None): - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. On virtual controller-0, using the host id, set the personality of this host - to 'controller': - - :: - - system host-update 2 personality=controller - - This initiates the install of software on controller-1. - This can take 5-10 minutes, depending on the performance of the host machine. - -#. While waiting on the previous step to complete, start up and set the personality - for 'controllerstorage-worker-0' and 'controllerstorage-worker-1'. Set the - personality to 'worker' and assign a unique hostname for each. - - For example, start 'controllerstorage-worker-0' from the host: - - :: - - virsh start controllerstorage-worker-0 - - Wait for new host (hostname=None) to be discovered by checking - ‘system host-list’ on virtual controller-0: - - :: - - system host-update 3 personality=worker hostname=compute-0 - - Repeat for 'controllerstorage-worker-1'. On the host: - - :: - - virsh start controllerstorage-worker-1 - - And wait for new host (hostname=None) to be discovered by checking - ‘system host-list’ on virtual controller-0: - - :: - - system host-update 4 personality=worker hostname=compute-1 - -#. Wait for the software installation on controller-1, compute-0, and compute-1 to - complete, for all virtual servers to reboot, and for all to show as - locked/disabled/online in 'system host-list'. - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | locked | disabled | online | - | 3 | compute-0 | compute | locked | disabled | online | - | 4 | compute-1 | compute | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - ----------------------- -Configure controller-1 ----------------------- - -.. incl-config-controller-1-virt-controller-storage-start: - -Configure the OAM and MGMT interfaces of virtual controller-0 and specify the -attached networks. Note that the MGMT interface is partially set up by the -network install procedure. - -:: - - OAM_IF=enp7s1 - system host-if-modify controller-1 $OAM_IF -c platform - system interface-network-assign controller-1 $OAM_IF oam - system interface-network-assign controller-1 mgmt0 cluster-host - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -**For OpenStack only:** Assign OpenStack host labels to controller-1 in support -of installing the stx-openstack manifest/helm-charts later: - -:: - - system host-label-assign controller-1 openstack-control-plane=enabled - -.. incl-config-controller-1-virt-controller-storage-end: - -------------------- -Unlock controller-1 -------------------- - -.. incl-unlock-controller-1-virt-controller-storage-start: - -Unlock virtual controller-1 in order to bring it into service: - -:: - - system host-unlock controller-1 - -Controller-1 will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host machine. - -.. incl-unlock-controller-1-virt-controller-storage-end: - ------------------------ -Configure compute nodes ------------------------ - -On virtual controller-0: - -#. Add the third Ceph monitor to compute-0: - - (The first two Ceph monitors are automatically assigned to controller-0 and - controller-1.) - - :: - - system ceph-mon-add compute-0 - -#. Wait for the compute node monitor to complete configuration: - - :: - - system ceph-mon-list - +--------------------------------------+-------+--------------+------------+------+ - | uuid | ceph_ | hostname | state | task | - | | mon_g | | | | - | | ib | | | | - +--------------------------------------+-------+--------------+------------+------+ - | 64176b6c-e284-4485-bb2a-115dee215279 | 20 | controller-1 | configured | None | - | a9ca151b-7f2c-4551-8167-035d49e2df8c | 20 | controller-0 | configured | None | - | f76bc385-190c-4d9a-aa0f-107346a9907b | 20 | compute-0 | configured | None | - +--------------------------------------+-------+--------------+------------+------+ - -#. Assign the cluster-host network to the MGMT interface for the compute nodes. - - Note that the MGMT interfaces are partially set up automatically by the - network install procedure. - - :: - - for COMPUTE in compute-0 compute-1; do - system interface-network-assign $COMPUTE mgmt0 cluster-host - done - -#. Configure data interfaces for compute nodes. - - .. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - - 1G Huge Pages are not supported in the virtual environment and there is no - virtual NIC supporting SRIOV. For that reason, data interfaces are not - applicable in the virtual environment for the Kubernetes-only scenario. - - For OpenStack only: - - :: - - DATA0IF=eth1000 - DATA1IF=eth1001 - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - - # configure the datanetworks in sysinv, prior to referencing it - # in the ``system host-if-modify`` command'. - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - for COMPUTE in compute-0 compute-1; do - echo "Configuring interface for: $COMPUTE" - set -ex - system host-port-list ${COMPUTE} --nowrap > ${SPL} - system host-if-list -a ${COMPUTE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - system host-if-modify -m 1500 -n data0 -c data ${COMPUTE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${COMPUTE} ${DATA1IFUUID} - system interface-datanetwork-assign ${COMPUTE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${COMPUTE} ${DATA1IFUUID} ${PHYSNET1} - set +ex - done - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to the compute nodes in - support of installing the stx-openstack manifest/helm-charts later: - - :: - - for NODE in compute-0 compute-1; do - system host-label-assign $NODE openstack-compute-node=enabled - system host-label-assign $NODE openvswitch=enabled - system host-label-assign $NODE sriov=enabled - done - -#. **For OpenStack only:** Set up disk partition for nova-local volume group, - which is needed for stx-openstack nova ephemeral disks: - - :: - - for COMPUTE in compute-0 compute-1; do - echo "Configuring Nova local for: $COMPUTE" - ROOT_DISK=$(system host-show ${COMPUTE} | grep rootfs | awk '{print $4}') - ROOT_DISK_UUID=$(system host-disk-list ${COMPUTE} --nowrap | grep ${ROOT_DISK} | awk '{print $2}') - PARTITION_SIZE=10 - NOVA_PARTITION=$(system host-disk-partition-add -t lvm_phys_vol ${COMPUTE} ${ROOT_DISK_UUID} ${PARTITION_SIZE}) - NOVA_PARTITION_UUID=$(echo ${NOVA_PARTITION} | grep -ow "| uuid | [a-z0-9\-]* |" | awk '{print $4}') - system host-lvg-add ${COMPUTE} nova-local - system host-pv-add ${COMPUTE} nova-local ${NOVA_PARTITION_UUID} - done - --------------------- -Unlock compute nodes --------------------- - -.. incl-unlock-compute-nodes-virt-controller-storage-start: - -Unlock virtual compute nodes to bring them into service: - -:: - - for COMPUTE in compute-0 compute-1; do - system host-unlock $COMPUTE - done - -The compute nodes will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host machine. - -.. incl-unlock-compute-nodes-virt-controller-storage-end: - ----------------------------- -Add Ceph OSDs to controllers ----------------------------- - -On virtual controller-0: - -#. Add OSDs to controller-0: - - :: - - HOST=controller-0 - DISKS=$(system host-disk-list ${HOST}) - TIERS=$(system storage-tier-list ceph_cluster) - OSDs="/dev/sdb" - for OSD in $OSDs; do - system host-stor-add ${HOST} $(echo "$DISKS" | grep "$OSD" | awk '{print $2}') --tier-uuid $(echo "$TIERS" | grep storage | awk '{print $2}') - while true; do system host-stor-list ${HOST} | grep ${OSD} | grep configuring; if [ $? -ne 0 ]; then break; fi; sleep 1; done - done - - system host-stor-list $HOST - -#. Add OSDs to controller-1: - - :: - - HOST=controller-1 - DISKS=$(system host-disk-list ${HOST}) - TIERS=$(system storage-tier-list ceph_cluster) - OSDs="/dev/sdb" - for OSD in $OSDs; do - system host-stor-add ${HOST} $(echo "$DISKS" | grep "$OSD" | awk '{print $2}') --tier-uuid $(echo "$TIERS" | grep storage | awk '{print $2}') - while true; do system host-stor-list ${HOST} | grep ${OSD} | grep configuring; if [ $? -ne 0 ]; then break; fi; sleep 1; done - done - - system host-stor-list $HOST - ----------- -Next steps ----------- - -.. include:: ../kubernetes_install_next.txt diff --git a/doc/source/deploy_install_guides/r2_release/virtual/dedicated_storage_environ.rst b/doc/source/deploy_install_guides/r2_release/virtual/dedicated_storage_environ.rst deleted file mode 100644 index 6cc83f249..000000000 --- a/doc/source/deploy_install_guides/r2_release/virtual/dedicated_storage_environ.rst +++ /dev/null @@ -1,58 +0,0 @@ -============================ -Prepare Host and Environment -============================ - -This section describes how to prepare the physical host and virtual environment -for a **StarlingX R2.0 virtual Standard with Dedicated Storage** deployment -configuration. - -.. contents:: - :local: - :depth: 1 - ------------------------------------- -Physical host requirements and setup ------------------------------------- - -.. include:: physical_host_req.txt - ---------------------------------------- -Prepare virtual environment and servers ---------------------------------------- - -The following steps explain how to prepare the virtual environment and servers -on a physical host for a StarlingX R2.0 virtual Standard with Dedicated Storage -deployment configuration. - -#. Prepare virtual environment. - - Set up virtual platform networks for virtual deployment: - - :: - - bash setup_network.sh - -#. Prepare virtual servers. - - Create the XML definitions for the virtual servers required by this - configuration option. This will create the XML virtual server definition for: - - * dedicatedstorage-controller-0 - * dedicatedstorage-controller-1 - * dedicatedstorage-storage-0 - * dedicatedstorage-storage-1 - * dedicatedstorage-worker-0 - * dedicatedstorage-worker-1 - - The following command will start/virtually power on: - - * The 'dedicatedstorage-controller-0' virtual server - * The X-based graphical virt-manager application - - :: - - bash setup_configuration.sh -c dedicatedstorage -i ./bootimage.iso - - If there is no X-server present errors will occur and the X-based GUI for the - virt-manager application will not start. The virt-manager GUI is not absolutely - required and you can safely ignore errors and continue. diff --git a/doc/source/deploy_install_guides/r2_release/virtual/dedicated_storage_install_kubernetes.rst b/doc/source/deploy_install_guides/r2_release/virtual/dedicated_storage_install_kubernetes.rst deleted file mode 100644 index f69d75693..000000000 --- a/doc/source/deploy_install_guides/r2_release/virtual/dedicated_storage_install_kubernetes.rst +++ /dev/null @@ -1,390 +0,0 @@ -======================================================================= -Install StarlingX Kubernetes on Virtual Standard with Dedicated Storage -======================================================================= - -This section describes the steps to install the StarlingX Kubernetes platform -on a **StarlingX R2.0 virtual Standard with Dedicated Storage** deployment -configuration. - -.. contents:: - :local: - :depth: 1 - --------------------------------- -Install software on controller-0 --------------------------------- - -In the last step of :doc:`dedicated_storage_environ`, the controller-0 virtual -server 'dedicatedstorage-controller-0' was started by the -:command:`setup_configuration.sh` command. - -On the host, attach to the console of virtual controller-0 and select the appropriate -installer menu options to start the non-interactive install of -StarlingX software on controller-0. - -.. note:: - - When entering the console, it is very easy to miss the first installer menu - selection. Use ESC to navigate to previous menus, to ensure you are at the - first installer menu. - -:: - - virsh console dedicatedstorage-controller-0 - -Make the following menu selections in the installer: - -#. First menu: Select 'Standard Controller Configuration' -#. Second menu: Select 'Serial Console' -#. Third menu: Select 'Standard Security Profile' - -Wait for the non-interactive install of software to complete and for the server -to reboot. This can take 5-10 minutes depending on the performance of the host -machine. - --------------------------------- -Bootstrap system on controller-0 --------------------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-bootstrap-controller-0-virt-controller-storage-start: - :end-before: incl-bootstrap-controller-0-virt-controller-storage-end: - ----------------------- -Configure controller-0 ----------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-config-controller-0-virt-controller-storage-start: - :end-before: incl-config-controller-0-virt-controller-storage-end: - -------------------- -Unlock controller-0 -------------------- - -Unlock virtual controller-0 in order to bring it into service: - -:: - - system host-unlock controller-0 - -Controller-0 will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host machine. - ------------------------------------------------------------------- -Install software on controller-1, storage nodes, and compute nodes ------------------------------------------------------------------- - -#. On the host, power on the controller-1 virtual server, - 'dedicatedstorage-controller-1'. It will automatically attempt to network - boot over the management network: - - :: - - virsh start dedicatedstorage-controller-1 - -#. Attach to the console of virtual controller-1: - - :: - - virsh console dedicatedstorage-controller-1 - -#. As controller-1 VM boots, a message appears on its console instructing you to - configure the personality of the node. - -#. On the console of controller-0, list hosts to see newly discovered - controller-1 host (hostname=None): - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. Using the host id, set the personality of this host to 'controller': - - :: - - system host-update 2 personality=controller - - This initiates software installation on controller-1. - This can take 5-10 minutes, depending on the performance of the host machine. - -#. While waiting on the previous step to complete, start up and set the personality - for 'dedicatedstorage-storage-0' and 'dedicatedstorage-storage-1'. Set the - personality to 'storage' and assign a unique hostname for each. - - For example, start 'dedicatedstorage-storage-0' from the host: - - :: - - virsh start dedicatedstorage-storage-0 - - Wait for new host (hostname=None) to be discovered by checking - ‘system host-list’ on virtual controller-0: - - :: - - system host-update 3 personality=storage - - Repeat for 'dedicatedstorage-storage-1'. On the host: - - :: - - virsh start dedicatedstorage-storage-1 - - And wait for new host (hostname=None) to be discovered by checking - ‘system host-list’ on virtual controller-0: - - :: - - system host-update 4 personality=storage - - This initiates software installation on storage-0 and storage-1. - This can take 5-10 minutes, depending on the performance of the host machine. - -#. While waiting on the previous step to complete, start up and set the personality - for 'dedicatedstorage-worker-0' and 'dedicatedstorage-worker-1'. Set the - personality to 'worker' and assign a unique hostname for each. - - For example, start 'dedicatedstorage-worker-0' from the host: - - :: - - virsh start dedicatedstorage-worker-0 - - Wait for new host (hostname=None) to be discovered by checking - ‘system host-list’ on virtual controller-0: - - :: - - system host-update 5 personality=worker hostname=compute-0 - - Repeat for 'dedicatedstorage-worker-1'. On the host: - - :: - - virsh start dedicatedstorage-worker-1 - - And wait for new host (hostname=None) to be discovered by checking - ‘system host-list’ on virtual controller-0: - - :: - - system host-update 6 personality=worker hostname=compute-1 - - This initiates software installation on compute-0 and compute-1. - -#. Wait for the software installation on controller-1, storage-0, storage-1, - compute-0, and compute-1 to complete, for all virtual servers to reboot, and for all - to show as locked/disabled/online in 'system host-list'. - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | locked | disabled | online | - | 3 | storage-0 | storage | locked | disabled | online | - | 4 | storage-1 | storage | locked | disabled | online | - | 5 | compute-0 | compute | locked | disabled | online | - | 6 | compute-1 | compute | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - ----------------------- -Configure controller-1 ----------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-config-controller-1-virt-controller-storage-start: - :end-before: incl-config-controller-1-virt-controller-storage-end: - -------------------- -Unlock controller-1 -------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-unlock-controller-1-virt-controller-storage-start: - :end-before: incl-unlock-controller-1-virt-controller-storage-end: - ------------------------ -Configure storage nodes ------------------------ - -On virtual controller-0: - -#. Assign the cluster-host network to the MGMT interface for the storage nodes. - - Note that the MGMT interfaces are partially set up by the network install procedure. - - :: - - for COMPUTE in storage-0 storage-1; do - system interface-network-assign $COMPUTE mgmt0 cluster-host - done - -#. Add OSDs to storage-0: - - :: - - HOST=storage-0 - DISKS=$(system host-disk-list ${HOST}) - TIERS=$(system storage-tier-list ceph_cluster) - OSDs="/dev/sdb" - for OSD in $OSDs; do - system host-stor-add ${HOST} $(echo "$DISKS" | grep "$OSD" | awk '{print $2}') --tier-uuid $(echo "$TIERS" | grep storage | awk '{print $2}') - done - - system host-stor-list $HOST - -#. Add OSDs to storage-1: - - :: - - HOST=storage-1 - DISKS=$(system host-disk-list ${HOST}) - TIERS=$(system storage-tier-list ceph_cluster) - OSDs="/dev/sdb" - for OSD in $OSDs; do - system host-stor-add ${HOST} $(echo "$DISKS" | grep "$OSD" | awk '{print $2}') --tier-uuid $(echo "$TIERS" | grep storage | awk '{print $2}') - done - - system host-stor-list $HOST - --------------------- -Unlock storage nodes --------------------- - -Unlock virtual storage nodes in order to bring them into service: - -:: - - for STORAGE in storage-0 storage-1; do - system host-unlock $STORAGE - done - -The storage nodes will reboot in order to apply configuration changes and come -into service. This can take 5-10 minutes, depending on the performance of the host machine. - ------------------------ -Configure compute nodes ------------------------ - -On virtual controller-0: - -#. Assign the cluster-host network to the MGMT interface for the compute nodes. - - Note that the MGMT interfaces are partially set up automatically by the - network install procedure. - - :: - - for COMPUTE in compute-0 compute-1; do - system interface-network-assign $COMPUTE mgmt0 cluster-host - done - -#. Configure data interfaces for compute nodes. - - .. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - - 1G Huge Pages are not supported in the virtual environment and there is no - virtual NIC supporting SRIOV. For that reason, data interfaces are not - applicable in the virtual environment for the Kubernetes-only scenario. - - For OpenStack only: - - :: - - DATA0IF=eth1000 - DATA1IF=eth1001 - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - - Configure the datanetworks in sysinv, prior to referencing it in the - :command:`system host-if-modify` command. - - :: - - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - for COMPUTE in compute-0 compute-1; do - echo "Configuring interface for: $COMPUTE" - set -ex - system host-port-list ${COMPUTE} --nowrap > ${SPL} - system host-if-list -a ${COMPUTE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - system host-if-modify -m 1500 -n data0 -c data ${COMPUTE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${COMPUTE} ${DATA1IFUUID} - system interface-datanetwork-assign ${COMPUTE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${COMPUTE} ${DATA1IFUUID} ${PHYSNET1} - set +ex - done - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to the compute nodes in - support of installing the stx-openstack manifest/helm-charts later: - - :: - - for NODE in compute-0 compute-1; do - system host-label-assign $NODE openstack-compute-node=enabled - system host-label-assign $NODE openvswitch=enabled - system host-label-assign $NODE sriov=enabled - done - -#. **For OpenStack only:** Set up disk partition for nova-local volume group, - which is needed for stx-openstack nova ephemeral disks: - - :: - - for COMPUTE in compute-0 compute-1; do - echo "Configuring Nova local for: $COMPUTE" - ROOT_DISK=$(system host-show ${COMPUTE} | grep rootfs | awk '{print $4}') - ROOT_DISK_UUID=$(system host-disk-list ${COMPUTE} --nowrap | grep ${ROOT_DISK} | awk '{print $2}') - PARTITION_SIZE=10 - NOVA_PARTITION=$(system host-disk-partition-add -t lvm_phys_vol ${COMPUTE} ${ROOT_DISK_UUID} ${PARTITION_SIZE}) - NOVA_PARTITION_UUID=$(echo ${NOVA_PARTITION} | grep -ow "| uuid | [a-z0-9\-]* |" | awk '{print $4}') - system host-lvg-add ${COMPUTE} nova-local - system host-pv-add ${COMPUTE} nova-local ${NOVA_PARTITION_UUID} - done - --------------------- -Unlock compute nodes --------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-unlock-compute-nodes-virt-controller-storage-start: - :end-before: incl-unlock-compute-nodes-virt-controller-storage-end: - ----------- -Next steps ----------- - -.. include:: ../kubernetes_install_next.txt diff --git a/doc/source/deploy_install_guides/r2_release/virtual/physical_host_req.txt b/doc/source/deploy_install_guides/r2_release/virtual/physical_host_req.txt deleted file mode 100644 index 51a57eefe..000000000 --- a/doc/source/deploy_install_guides/r2_release/virtual/physical_host_req.txt +++ /dev/null @@ -1,78 +0,0 @@ -The following sections describe system requirements and host setup for a -workstation hosting virtual machine(s) where StarlingX will be deployed. - -********************* -Hardware requirements -********************* - -The host system should have at least: - -* **Processor:** x86_64 only supported architecture with BIOS enabled hardware - virtualization extensions - -* **Cores:** 8 - -* **Memory:** 32GB RAM - -* **Hard Disk:** 500GB HDD - -* **Network:** One network adapter with active Internet connection - -********************* -Software requirements -********************* - -The host system should have at least: - -* A workstation computer with Ubuntu 16.04 LTS 64-bit - -All other required packages will be installed by scripts in the StarlingX tools repository. - -********** -Host setup -********** - -Set up the host with the following steps: - -#. Update OS: - - :: - - apt-get update - -#. Clone the StarlingX tools repository: - - :: - - apt-get install -y git - cd $HOME - git clone https://opendev.org/starlingx/tools.git - -#. Install required packages: - - :: - - cd $HOME/tools/deployment/libvirt/ - bash install_packages.sh - apt install -y apparmor-profiles - apt-get install -y ufw - ufw disable - ufw status - - - .. note:: - - On Ubuntu 16.04, if apparmor-profile modules were installed as shown in - the example above, you must reboot the server to fully install the - apparmor-profile modules. - - -#. Get the StarlingX ISO. This can be from a private StarlingX build or from - the public `CENGN StarlingX mirror `_. - - For example, to get the ISO for the StarlingX R2.0 build, use the command - shown below: - - :: - - wget http://mirror.starlingx.cengn.ca/mirror/starlingx/release/2.0.0/centos/outputs/iso/bootimage.iso diff --git a/doc/source/deploy_install_guides/r3_release/ansible_bootstrap_configs.rst b/doc/source/deploy_install_guides/r3_release/ansible_bootstrap_configs.rst deleted file mode 100644 index 2a82d1c77..000000000 --- a/doc/source/deploy_install_guides/r3_release/ansible_bootstrap_configs.rst +++ /dev/null @@ -1,422 +0,0 @@ -================================ -Ansible Bootstrap Configurations -================================ - -This section describes Ansible bootstrap configuration options. - -.. contents:: - :local: - :depth: 1 - - -.. _install-time-only-params: - ----------------------------- -Install-time-only parameters ----------------------------- - -Some Ansible bootstrap parameters can not be changed or are very difficult to -change after installation is complete. - -Review the set of install-time-only parameters before installation and confirm -that your values for these parameters are correct for the desired installation. - -.. note:: - - If you notice an incorrect install-time-only parameter value *before you - unlock controller-0 for the first time*, you can re-run the Ansible bootstrap - playbook with updated override values and the updated values will take effect. - -**************************** -Install-time-only parameters -**************************** - -**System Properties** - -* ``system_mode`` -* ``distributed_cloud_role`` - -**Network Properties** - -* ``pxeboot_subnet`` -* ``pxeboot_start_address`` -* ``pxeboot_end_address`` -* ``management_subnet`` -* ``management_start_address`` -* ``management_end_address`` -* ``cluster_host_subnet`` -* ``cluster_host_start_address`` -* ``cluster_host_end_address`` -* ``cluster_pod_subnet`` -* ``cluster_pod_start_address`` -* ``cluster_pod_end_address`` -* ``cluster_service_subnet`` -* ``cluster_service_start_address`` -* ``cluster_service_end_address`` -* ``management_multicast_subnet`` -* ``management_multicast_start_address`` -* ``management_multicast_end_address`` - -**Docker Proxies** - -* ``docker_http_proxy`` -* ``docker_https_proxy`` -* ``docker_no_proxy`` - -**Docker Registry Overrides** - -* ``docker_registries`` - - * ``k8s.gcr.io`` - - * ``url`` - * ``username`` - * ``password`` - * ``secure`` - - * ``gcr.io`` - - * ``url`` - * ``username`` - * ``password`` - * ``secure`` - - * ``quay.io`` - - * ``url`` - * ``username`` - * ``password`` - * ``secure`` - - * ``docker.io`` - - * ``url`` - * ``username`` - * ``password`` - * ``secure`` - - * ``docker.elastic.co`` - - * ``url`` - * ``username`` - * ``password`` - * ``secure`` - - * ``defaults`` - - * ``url`` - * ``username`` - * ``password`` - * ``secure`` - -**Certificates** - -* ``k8s_root_ca_cert`` -* ``k8s_root_ca_key`` - -**Kubernetes Parameters** - -* ``apiserver_oidc`` - - * ``client_id`` - * ``issuer_id`` - * ``username_claim`` - ----- -IPv6 ----- - -If you are using IPv6, provide IPv6 configuration overrides for the Ansible -bootstrap playbook. Note that all addressing, except pxeboot_subnet, should be -updated to IPv6 addressing. - -Example IPv6 override values are shown below: - -:: - - dns_servers: - ‐ 2001:4860:4860::8888 - ‐ 2001:4860:4860::8844 - pxeboot_subnet: 169.254.202.0/24 - management_subnet: 2001:db8:2::/64 - cluster_host_subnet: 2001:db8:3::/64 - cluster_pod_subnet: 2001:db8:4::/64 - cluster_service_subnet: 2001:db8:4::/112 - external_oam_subnet: 2001:db8:1::/64 - external_oam_gateway_address: 2001:db8::1 - external_oam_floating_address: 2001:db8::2 - external_oam_node_0_address: 2001:db8::3 - external_oam_node_1_address: 2001:db8::4 - management_multicast_subnet: ff08::1:1:0/124 - -.. note:: - - The `external_oam_node_0_address`, and `external_oam_node_1_address` parameters - are not required for the AIO‐SX installation. - ----------------- -Private registry ----------------- - -To bootstrap StarlingX you must pull container images for multiple system -services. By default these container images are pulled from public registries: -k8s.gcr.io, gcr.io, quay.io, and docker.io. - -It may be required (or desired) to copy the container images to a private -registry and pull the images from the private registry (instead of the public -registries) as part of the StarlingX bootstrap. For example, a private registry -would be required if a StarlingX system was deployed in an air-gapped network -environment. - -Use the `docker_registries` structure in the bootstrap overrides file to specify -alternate registry(s) for the public registries from which container images are -pulled. These alternate registries are used during the bootstrapping of -controller-0, and on :command:`system application-apply` of application packages. - -The `docker_registries` structure is a map of public registries and the -alternate registry values for each public registry. For each public registry the -key is a fully scoped registry name of a public registry (for example "k8s.gcr.io") -and the alternate registry URL and username/password (if authenticated). - -url - The fully scoped registry name (and optionally namespace/) for the alternate - registry location where the images associated with this public registry - should now be pulled from. - - Valid formats for the `url` value are: - - * Domain. For example: - - :: - - example.domain - - * Domain with port. For example: - - :: - - example.domain:5000 - - * IPv4 address. For example: - - :: - - 1.2.3.4 - - * IPv4 address with port. For example: - - :: - - 1.2.3.4:5000 - - * IPv6 address. For example: - - :: - - FD01::0100 - - * IPv6 address with port. For example: - - :: - - [FD01::0100]:5000 - -username - The username for logging into the alternate registry, if authenticated. - -password - The password for logging into the alternate registry, if authenticated. - - -Additional configuration options in the `docker_registries` structure are: - -defaults - A special public registry key which defines common values to be applied to - all overrideable public registries. If only the `defaults` registry - is defined, it will apply `url`, `username`, and `password` for all - registries. - - If values under specific registries are defined, they will override the - values defined in the defaults registry. - - .. note:: - - The `defaults` key was formerly called `unified`. It was renamed - in StarlingX R3.0 and updated semantics were applied. - - This change affects anyone with a StarlingX installation prior to R3.0 that - specifies alternate Docker registries using the `unified` key. - -secure - Specifies whether the registry(s) supports HTTPS (secure) or HTTP (not secure). - Applies to all alternate registries. A boolean value. The default value is - True (secure, HTTPS). - -.. note:: - - The ``secure`` parameter was formerly called ``is_secure_registry``. It was - renamed in StarlingX R3.0. - -If an alternate registry is specified to be secure (using HTTPS), the certificate -used by the registry may not be signed by a well-known Certificate Authority (CA). -This results in the :command:`docker pull` of images from this registry to fail. -Use the `ssl_ca_cert` override to specify the public certificate of the CA that -signed the alternate registry’s certificate. This will add the CA as a trusted -CA to the StarlingX system. - -ssl_ca_cert - The `ssl_ca_cert` value is the absolute path of the certificate file. The - certificate must be in PEM format and the file may contain a single CA - certificate or multiple CA certificates in a bundle. - -The following example will apply `url`, `username`, and `password` to all -registries. - -:: - - docker_registries: - defaults: - url: my.registry.io - username: myreguser - password: myregP@ssw0rd - -The next example applies `username` and `password` from the defaults registry -to all public registries. `url` is different for each public registry. It -additionally specifies an alternate CA certificate. - -:: - - docker_registries: - k8s.gcr.io: - url: my.k8sregistry.io - gcr.io: - url: my.gcrregistry.io - quay.io: - url: my.quayregistry.io - docker.io: - url: my.dockerregistry.io - defaults: - url: my.registry.io - username: myreguser - password: myregP@ssw0rd - - ssl_ca_cert: /path/to/ssl_ca_cert_file - ------------- -Docker proxy ------------- - -If the StarlingX OAM interface or network is behind a http/https proxy, relative -to the Docker registries used by StarlingX or applications running on StarlingX, -then Docker within StarlingX must be configured to use these http/https proxies. - -Use the following configuration overrides to configure your Docker proxy settings. - -docker_http_proxy - Specify the HTTP proxy URL to use. For example: - - :: - - docker_http_proxy: http://my.proxy.com:1080 - -docker_https_proxy - Specify the HTTPS proxy URL to use. For example: - - :: - - docker_https_proxy: https://my.proxy.com:1443 - -docker_no_proxy - A no-proxy address list can be provided for registries not on the other side - of the proxies. This list will be added to the default no-proxy list derived - from localhost, loopback, management, and OAM floating addresses at run time. - Each address in the no-proxy list must neither contain a wildcard nor have - subnet format. For example: - - :: - - docker_no_proxy: - - 1.2.3.4 - - 5.6.7.8 - --------------------------------------- -Kubernetes root CA certificate and key --------------------------------------- - -By default the Kubernetes Root CA Certificate and Key are auto-generated and -result in the use of self-signed certificates for the Kubernetes API server. In -the case where self-signed certificates are not acceptable, use the bootstrap -override values `k8s_root_ca_cert` and `k8s_root_ca_key` to specify the -certificate and key for the Kubernetes root CA. - -k8s_root_ca_cert - Specifies the certificate for the Kubernetes root CA. The `k8s_root_ca_cert` - value is the absolute path of the certificate file. The certificate must be - in PEM format and the value must be provided as part of a pair with - `k8s_root_ca_key`. The playbook will not proceed if only one value is provided. - -k8s_root_ca_key - Specifies the key for the Kubernetes root CA. The `k8s_root_ca_key` - value is the absolute path of the certificate file. The certificate must be - in PEM format and the value must be provided as part of a pair with - `k8s_root_ca_cert`. The playbook will not proceed if only one value is provided. - -.. important:: - - The default length for the generated Kubernetes root CA certificate is 10 - years. Replacing the root CA certificate is an involved process so the custom - certificate expiry should be as long as possible. We recommend ensuring root - CA certificate has an expiry of at least 5-10 years. - -The administrator can also provide values to add to the Kubernetes API server -certificate Subject Alternative Name list using the 'apiserver_cert_sans` -override parameter. - -apiserver_cert_sans - Specifies a list of Subject Alternative Name entries that will be added to the - Kubernetes API server certificate. Each entry in the list must be an IP address - or domain name. For example: - - :: - - apiserver_cert_sans: - - hostname.domain - - 198.51.100.75 - -StarlingX automatically updates this parameter to include IP records for the OAM -floating IP and both OAM unit IP addresses. - ----------------------------------------------------- -OpenID Connect authentication for Kubernetes cluster ----------------------------------------------------- - -The Kubernetes cluster can be configured to use an external OpenID Connect -:abbr:`IDP (identity provider)`, such as Azure Active Directory, Salesforce, or -Google, for Kubernetes API authentication. - -By default, OpenID Connect authentication is disabled. To enable OpenID Connect, -use the following configuration values in the Ansible bootstrap overrides file -to specify the IDP for OpenID Connect: - -:: - - apiserver_oidc: - client_id: - issuer_url: - username_claim: - -When the three required fields of the `apiserver_oidc` parameter are defined, -OpenID Connect is considered active. The values will be used to configure the -Kubernetes cluster to use the specified external OpenID Connect IDP for -Kubernetes API authentication. - -In addition, you will need to configure the external OpenID Connect IDP and any -required OpenID client application according to the specific IDP's documentation. - -If not configuring OpenID Connect, all values should be absent from the -configuration file. - -.. note:: - - Default authentication via service account tokens is always supported, - even when OpenID Connect authentication is configured. \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r3_release/ansible_install_time_only.txt b/doc/source/deploy_install_guides/r3_release/ansible_install_time_only.txt deleted file mode 100644 index 962bf3fc2..000000000 --- a/doc/source/deploy_install_guides/r3_release/ansible_install_time_only.txt +++ /dev/null @@ -1,7 +0,0 @@ -.. important:: - - Some Ansible bootstrap parameters cannot be changed or are very difficult to change after installation is complete. - - Review the set of install-time-only parameters before installation and confirm that your values for these parameters are correct for the desired installation. - - Refer to :ref:`Ansible install-time-only parameters ` for details. \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/aio_duplex.rst b/doc/source/deploy_install_guides/r3_release/bare_metal/aio_duplex.rst deleted file mode 100644 index 103a933fa..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/aio_duplex.rst +++ /dev/null @@ -1,26 +0,0 @@ -============================================== -Bare metal All-in-one Duplex Installation R3.0 -============================================== - --------- -Overview --------- - -.. include:: ../desc_aio_duplex.txt - -The bare metal AIO-DX deployment configuration may be extended with up to four -worker nodes (not shown in the diagram). Installation instructions for -these additional nodes are described in :doc:`aio_duplex_extend`. - -.. include:: ../ipv6_note.txt - ------------- -Installation ------------- - -.. toctree:: - :maxdepth: 1 - - aio_duplex_hardware - aio_duplex_install_kubernetes - aio_duplex_extend \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/aio_duplex_extend.rst b/doc/source/deploy_install_guides/r3_release/bare_metal/aio_duplex_extend.rst deleted file mode 100644 index 754d674f8..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/aio_duplex_extend.rst +++ /dev/null @@ -1,192 +0,0 @@ -================================= -Extend Capacity with Worker Nodes -================================= - -This section describes the steps to extend capacity with worker nodes on a -**StarlingX R3.0 bare metal All-in-one Duplex** deployment configuration. - -.. contents:: - :local: - :depth: 1 - --------------------------------- -Install software on worker nodes --------------------------------- - -#. Power on the worker node servers and force them to network boot with the - appropriate BIOS boot options for your particular server. - -#. As the worker nodes boot, a message appears on their console instructing - you to configure the personality of the node. - -#. On the console of controller-0, list hosts to see newly discovered worker node - hosts (hostname=None): - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-0 | controller | unlocked | enabled | available | - | 3 | None | None | locked | disabled | offline | - | 4 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. Using the host id, set the personality of this host to 'worker': - - :: - - system host-update 3 personality=worker hostname=worker-0 - system host-update 4 personality=worker hostname=worker-1 - - This initiates the install of software on worker nodes. - This can take 5-10 minutes, depending on the performance of the host machine. - -#. Wait for the install of software on the worker nodes to complete, for the - worker nodes to reboot, and for both to show as locked/disabled/online in - 'system host-list'. - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | unlocked | enabled | available | - | 3 | worker-0 | worker | locked | disabled | online | - | 4 | worker-1 | worker | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - ----------------------- -Configure worker nodes ----------------------- - -#. Assign the cluster-host network to the MGMT interface for the worker nodes: - - (Note that the MGMT interfaces are partially set up automatically by the - network install procedure.) - - :: - - for NODE in worker-0 worker-1; do - system interface-network-assign $NODE mgmt0 cluster-host - done - -#. Configure data interfaces for worker nodes. Use the DATA port names, for - example eth0, that are applicable to your deployment environment. - - .. important:: - - This step is **required** for OpenStack. - - This step is optional for Kubernetes: Do this step if using SRIOV network - attachments in hosted application containers. - - For Kubernetes SRIOV network attachments: - - * Configure SRIOV device plug in: - - :: - - system host-label-assign controller-1 sriovdp=enabled - - * If planning on running DPDK in containers on this host, configure the number - of 1G Huge pages required on both NUMA nodes: - - :: - - system host-memory-modify controller-1 0 -1G 100 - system host-memory-modify controller-1 1 -1G 100 - - For both Kubernetes and OpenStack: - - :: - - DATA0IF= - DATA1IF= - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - - # configure the datanetworks in sysinv, prior to referencing it - # in the ``system host-if-modify`` command'. - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - for NODE in worker-0 worker-1; do - echo "Configuring interface for: $NODE" - set -ex - system host-port-list ${NODE} --nowrap > ${SPL} - system host-if-list -a ${NODE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - system host-if-modify -m 1500 -n data0 -c data ${NODE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${NODE} ${DATA1IFUUID} - system interface-datanetwork-assign ${NODE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${NODE} ${DATA1IFUUID} ${PHYSNET1} - set +ex - done - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to the worker nodes in - support of installing the stx-openstack manifest and helm-charts later. - - :: - - for NODE in worker-0 worker-1; do - system host-label-assign $NODE openstack-compute-node=enabled - system host-label-assign $NODE openvswitch=enabled - system host-label-assign $NODE sriov=enabled - done - -#. **For OpenStack only:** Setup disk partition for nova-local volume group, - needed for stx-openstack nova ephemeral disks. - - :: - - for NODE in worker-0 worker-1; do - echo "Configuring Nova local for: $NODE" - ROOT_DISK=$(system host-show ${NODE} | grep rootfs | awk '{print $4}') - ROOT_DISK_UUID=$(system host-disk-list ${NODE} --nowrap | grep ${ROOT_DISK} | awk '{print $2}') - PARTITION_SIZE=10 - NOVA_PARTITION=$(system host-disk-partition-add -t lvm_phys_vol ${NODE} ${ROOT_DISK_UUID} ${PARTITION_SIZE}) - NOVA_PARTITION_UUID=$(echo ${NOVA_PARTITION} | grep -ow "| uuid | [a-z0-9\-]* |" | awk '{print $4}') - system host-lvg-add ${NODE} nova-local - system host-pv-add ${NODE} nova-local ${NOVA_PARTITION_UUID} - done - - -------------------- -Unlock worker nodes -------------------- - -Unlock worker nodes in order to bring them into service: - -:: - - for NODE in worker-0 worker-1; do - system host-unlock $NODE - done - -The worker nodes will reboot to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host -machine. - diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/aio_duplex_hardware.rst b/doc/source/deploy_install_guides/r3_release/bare_metal/aio_duplex_hardware.rst deleted file mode 100644 index 722f1daa3..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/aio_duplex_hardware.rst +++ /dev/null @@ -1,58 +0,0 @@ -===================== -Hardware Requirements -===================== - -This section describes the hardware requirements and server preparation for a -**StarlingX R3.0 bare metal All-in-one Duplex** deployment configuration. - -.. contents:: - :local: - :depth: 1 - ------------------------------ -Minimum hardware requirements ------------------------------ - -The recommended minimum hardware requirements for bare metal servers for various -host types are: - -+-------------------------+-----------------------------------------------------------+ -| Minimum Requirement | All-in-one Controller Node | -+=========================+===========================================================+ -| Number of servers | 2 | -+-------------------------+-----------------------------------------------------------+ -| Minimum processor class | - Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) | -| | 8 cores/socket | -| | | -| | or | -| | | -| | - Single-CPU Intel® Xeon® D-15xx family, 8 cores | -| | (low-power/low-cost option) | -+-------------------------+-----------------------------------------------------------+ -| Minimum memory | 64 GB | -+-------------------------+-----------------------------------------------------------+ -| Primary disk | 500 GB SSD or NVMe (see :doc:`../../nvme_config`) | -+-------------------------+-----------------------------------------------------------+ -| Additional disks | - 1 or more 500 GB (min. 10K RPM) for Ceph OSD | -| | - Recommended, but not required: 1 or more SSDs or NVMe | -| | drives for Ceph journals (min. 1024 MiB per OSD journal)| -| | - For OpenStack, recommend 1 or more 500 GB (min. 10K RPM)| -| | for VM local ephemeral storage | -+-------------------------+-----------------------------------------------------------+ -| Minimum network ports | - Mgmt/Cluster: 1x10GE | -| | - OAM: 1x1GE | -| | - Data: 1 or more x 10GE | -+-------------------------+-----------------------------------------------------------+ -| BIOS settings | - Hyper-Threading technology enabled | -| | - Virtualization technology enabled | -| | - VT for directed I/O enabled | -| | - CPU power and performance policy set to performance | -| | - CPU C state control disabled | -| | - Plug & play BMC detection disabled | -+-------------------------+-----------------------------------------------------------+ - --------------------------- -Prepare bare metal servers --------------------------- - -.. include:: prep_servers.txt \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/aio_duplex_install_kubernetes.rst b/doc/source/deploy_install_guides/r3_release/bare_metal/aio_duplex_install_kubernetes.rst deleted file mode 100644 index 9ee67feab..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/aio_duplex_install_kubernetes.rst +++ /dev/null @@ -1,523 +0,0 @@ -================================================= -Install StarlingX Kubernetes on Bare Metal AIO-DX -================================================= - -This section describes the steps to install the StarlingX Kubernetes platform -on a **StarlingX R3.0 bare metal All-in-one Duplex** deployment configuration. - -.. contents:: - :local: - :depth: 1 - ---------------------- -Create a bootable USB ---------------------- - -Refer to :doc:`/deploy_install_guides/bootable_usb` for instructions on how to -create a bootable USB with the StarlingX ISO on your system. - --------------------------------- -Install software on controller-0 --------------------------------- - -.. include:: aio_simplex_install_kubernetes.rst - :start-after: incl-install-software-controller-0-aio-simplex-start: - :end-before: incl-install-software-controller-0-aio-simplex-end: - --------------------------------- -Bootstrap system on controller-0 --------------------------------- - -#. Login using the username / password of "sysadmin" / "sysadmin". - When logging in for the first time, you will be forced to change the password. - - :: - - Login: sysadmin - Password: - Changing password for sysadmin. - (current) UNIX Password: sysadmin - New Password: - (repeat) New Password: - -#. Verify and/or configure IP connectivity. - - External connectivity is required to run the Ansible bootstrap playbook. The - StarlingX boot image will DHCP out all interfaces so the server may have - obtained an IP address and have external IP connectivity if a DHCP server is - present in your environment. Verify this using the :command:`ip addr` and - :command:`ping 8.8.8.8` commands. - - Otherwise, manually configure an IP address and default IP route. Use the - PORT, IP-ADDRESS/SUBNET-LENGTH and GATEWAY-IP-ADDRESS applicable to your - deployment environment. - - :: - - sudo ip address add / dev - sudo ip link set up dev - sudo ip route add default via dev - ping 8.8.8.8 - -#. Specify user configuration overrides for the Ansible bootstrap playbook. - - Ansible is used to bootstrap StarlingX on controller-0. Key files for Ansible - configuration are: - - ``/etc/ansible/hosts`` - The default Ansible inventory file. Contains a single host: localhost. - - ``/usr/share/ansible/stx-ansible/playbooks/bootstrap.yml`` - The Ansible bootstrap playbook. - - ``/usr/share/ansible/stx-ansible/playbooks/host_vars/bootstrap/default.yml`` - The default configuration values for the bootstrap playbook. - - ``sysadmin home directory ($HOME)`` - The default location where Ansible looks for and imports user - configuration override files for hosts. For example: ``$HOME/.yml``. - - .. include:: ../ansible_install_time_only.txt - - Specify the user configuration override file for the Ansible bootstrap - playbook using one of the following methods: - - #. Use a copy of the default.yml file listed above to provide your overrides. - - The default.yml file lists all available parameters for bootstrap - configuration with a brief description for each parameter in the file comments. - - To use this method, copy the default.yml file listed above to - ``$HOME/localhost.yml`` and edit the configurable values as desired. - - #. Create a minimal user configuration override file. - - To use this method, create your override file at ``$HOME/localhost.yml`` - and provide the minimum required parameters for the deployment configuration - as shown in the example below. Use the OAM IP SUBNET and IP ADDRESSing - applicable to your deployment environment. - - :: - - cd ~ - cat < localhost.yml - system_mode: duplex - - dns_servers: - - 8.8.8.8 - - 8.8.4.4 - - external_oam_subnet: / - external_oam_gateway_address: - external_oam_floating_address: - external_oam_node_0_address: - external_oam_node_1_address: - - admin_username: admin - admin_password: - ansible_become_pass: - - # Add these lines to configure Docker to use a proxy server - # docker_http_proxy: http://my.proxy.com:1080 - # docker_https_proxy: https://my.proxy.com:1443 - # docker_no_proxy: - # - 1.2.3.4 - - EOF - - Refer to :doc:`/deploy_install_guides/r3_release/ansible_bootstrap_configs` - for information on additional Ansible bootstrap configurations for advanced - Ansible bootstrap scenarios, such as Docker proxies when deploying behind a - firewall, etc. Refer to :doc:`/../../configuration/docker_proxy_config` for - details about Docker proxy settings. - -#. Run the Ansible bootstrap playbook: - - :: - - ansible-playbook /usr/share/ansible/stx-ansible/playbooks/bootstrap.yml - - Wait for Ansible bootstrap playbook to complete. - This can take 5-10 minutes, depending on the performance of the host machine. - - The image below shows a typical successful run. - - .. figure:: ../figures/starlingx-release3-ansible-bootstrap-simplex.png - :alt: ansible bootstrap install screen - :width: 800 - - *Figure 3: StarlingX Ansible Bootstrap* - ----------------------- -Configure controller-0 ----------------------- - -#. Acquire admin credentials: - - :: - - source /etc/platform/openrc - -#. Configure the OAM and MGMT interfaces of controller-0 and specify the - attached networks. Use the OAM and MGMT port names, for example eth0, that are - applicable to your deployment environment. - - :: - - OAM_IF= - MGMT_IF= - system host-if-modify controller-0 lo -c none - IFNET_UUIDS=$(system interface-network-list controller-0 | awk '{if ($6=="lo") print $4;}') - for UUID in $IFNET_UUIDS; do - system interface-network-remove ${UUID} - done - system host-if-modify controller-0 $OAM_IF -c platform - system interface-network-assign controller-0 $OAM_IF oam - system host-if-modify controller-0 $MGMT_IF -c platform - system interface-network-assign controller-0 $MGMT_IF mgmt - system interface-network-assign controller-0 $MGMT_IF cluster-host - -#. Configure NTP Servers for network time synchronization: - - :: - - system ntp-modify ntpservers=0.pool.ntp.org,1.pool.ntp.org - -#. Configure data interfaces for controller-0. Use the DATA port names, for example - eth0, applicable to your deployment environment. - - .. important:: - - This step is **required** for OpenStack. - - This step is optional for Kubernetes: Do this step if using SRIOV network - attachments in hosted application containers. - - For Kubernetes SRIOV network attachments: - - * Configure the SRIOV device plugin - - :: - - system host-label-assign controller-0 sriovdp=enabled - - * If planning on running DPDK in containers on this host, configure the number - of 1G Huge pages required on both NUMA nodes. - - :: - - system host-memory-modify controller-0 0 -1G 100 - system host-memory-modify controller-0 1 -1G 100 - - For both Kubernetes and OpenStack: - - :: - - DATA0IF= - DATA1IF= - export NODE=controller-0 - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - system host-port-list ${NODE} --nowrap > ${SPL} - system host-if-list -a ${NODE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - system host-if-modify -m 1500 -n data0 -c data ${NODE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${NODE} ${DATA1IFUUID} - system interface-datanetwork-assign ${NODE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${NODE} ${DATA1IFUUID} ${PHYSNET1} - -#. Add an OSD on controller-0 for Ceph. The following example adds an OSD - to the `sdb` disk: - - :: - - echo ">>> Add OSDs to primary tier" - system host-disk-list controller-0 - system host-disk-list controller-0 | awk '/\/dev\/sdb/{print $2}' | xargs -i system host-stor-add controller-0 {} - system host-stor-list controller-0 - -#. If required, and not already done as part of bootstrap, configure Docker to - use a proxy server. - - #. List Docker proxy parameters: - - :: - - system service-parameter-list platform docker - - #. Refer to :doc:`/../../configuration/docker_proxy_config` for - details about Docker proxy settings. - - -************************************* -OpenStack-specific host configuration -************************************* - -.. include:: aio_simplex_install_kubernetes.rst - :start-after: incl-config-controller-0-openstack-specific-aio-simplex-start: - :end-before: incl-config-controller-0-openstack-specific-aio-simplex-end: - -------------------- -Unlock controller-0 -------------------- - -.. include:: aio_simplex_install_kubernetes.rst - :start-after: incl-unlock-controller-0-aio-simplex-start: - :end-before: incl-unlock-controller-0-aio-simplex-end: - -------------------------------------- -Install software on controller-1 node -------------------------------------- - -#. Power on the controller-1 server and force it to network boot with the - appropriate BIOS boot options for your particular server. - -#. As controller-1 boots, a message appears on its console instructing you to - configure the personality of the node. - -#. On the console of controller-0, list hosts to see newly discovered controller-1 - host (hostname=None): - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. Using the host id, set the personality of this host to 'controller': - - :: - - system host-update 2 personality=controller - -#. Wait for the software installation on controller-1 to complete, for controller-1 to - reboot, and for controller-1 to show as locked/disabled/online in 'system host-list'. - - This can take 5-10 minutes, depending on the performance of the host machine. - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - ----------------------- -Configure controller-1 ----------------------- - -#. Configure the OAM and MGMT interfaces of controller-1 and specify the - attached networks. Use the OAM and MGMT port names, for example eth0, that are - applicable to your deployment environment: - - (Note that the MGMT interface is partially set up automatically by the network - install procedure.) - - :: - - OAM_IF= - MGMT_IF= - system host-if-modify controller-1 $OAM_IF -c platform - system interface-network-assign controller-1 $OAM_IF oam - system interface-network-assign controller-1 mgmt0 cluster-host - -#. Configure data interfaces for controller-1. Use the DATA port names, for example - eth0, applicable to your deployment environment. - - .. important:: - - This step is **required** for OpenStack. - - This step is optional for Kubernetes: Do this step if using SRIOV network - attachments in hosted application containers. - - For Kubernetes SRIOV network attachments: - - * Configure the SRIOV device plugin: - - :: - - system host-label-assign controller-1 sriovdp=enabled - - * If planning on running DPDK in containers on this host, configure the number - of 1G Huge pages required on both NUMA nodes: - - :: - - system host-memory-modify controller-1 0 -1G 100 - system host-memory-modify controller-1 1 -1G 100 - - - For both Kubernetes and OpenStack: - - :: - - DATA0IF= - DATA1IF= - export NODE=controller-1 - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - system host-port-list ${NODE} --nowrap > ${SPL} - system host-if-list -a ${NODE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - system host-if-modify -m 1500 -n data0 -c data ${NODE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${NODE} ${DATA1IFUUID} - system interface-datanetwork-assign ${NODE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${NODE} ${DATA1IFUUID} ${PHYSNET1} - -#. Add an OSD on controller-1 for Ceph: - - :: - - echo ">>> Add OSDs to primary tier" - system host-disk-list controller-1 - system host-disk-list controller-1 | awk '/\/dev\/sdb/{print $2}' | xargs -i system host-stor-add controller-1 {} - system host-stor-list controller-1 - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to controller-1 in - support of installing the stx-openstack manifest and helm-charts later. - - :: - - system host-label-assign controller-1 openstack-control-plane=enabled - system host-label-assign controller-1 openstack-compute-node=enabled - system host-label-assign controller-1 openvswitch=enabled - system host-label-assign controller-1 sriov=enabled - -#. **For OpenStack only:** Set up disk partition for nova-local volume group, - which is needed for stx-openstack nova ephemeral disks. - - :: - - export NODE=controller-1 - - echo ">>> Getting root disk info" - ROOT_DISK=$(system host-show ${NODE} | grep rootfs | awk '{print $4}') - ROOT_DISK_UUID=$(system host-disk-list ${NODE} --nowrap | grep ${ROOT_DISK} | awk '{print $2}') - echo "Root disk: $ROOT_DISK, UUID: $ROOT_DISK_UUID" - - echo ">>>> Configuring nova-local" - NOVA_SIZE=34 - NOVA_PARTITION=$(system host-disk-partition-add -t lvm_phys_vol ${NODE} ${ROOT_DISK_UUID} ${NOVA_SIZE}) - NOVA_PARTITION_UUID=$(echo ${NOVA_PARTITION} | grep -ow "| uuid | [a-z0-9\-]* |" | awk '{print $4}') - system host-lvg-add ${NODE} nova-local - system host-pv-add ${NODE} nova-local ${NOVA_PARTITION_UUID} - sleep 2 - -------------------- -Unlock controller-1 -------------------- - -Unlock controller-1 in order to bring it into service: - -:: - - system host-unlock controller-1 - -Controller-1 will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host -machine. - -:: - - [sysadmin@controller-1 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | unlocked | enabled | available | - +----+--------------+-------------+----------------+-------------+--------------+ - - [sysadmin@controller-1 ~(keystone_admin)]$ system host-show controller-1 - +-----------------------+----------------------------------------------------------------------+ - | Property | Value | - +-----------------------+----------------------------------------------------------------------+ - | action | none | - | administrative | unlocked | - | availability | available | - | bm_ip | None | - | bm_type | none | - | bm_username | None | - | boot_device | /dev/sda | - | capabilities | {u'stor_function': u'monitor', u'Personality': u'Controller-Active'} | - | clock_synchronization | ntp | - | config_applied | 19e0dada-c2ac-4faf-a513-b713c07441af | - | config_status | None | - | config_target | 19e0dada-c2ac-4faf-a513-b713c07441af | - | console | ttyS0,115200 | - | created_at | 2020-04-22T02:42:06.956004+00:00 | - | hostname | controller-1 | - | id | 2 | - | install_output | text | - | install_state | completed | - | install_state_info | None | - | inv_state | inventoried | - | invprovision | provisioned | - | location | {} | - | mgmt_ip | 10.10.53.12 | - | mgmt_mac | a4:bf:01:55:03:bb | - | operational | enabled | - | personality | controller | - | reserved | False | - | rootfs_device | /dev/sda | - | serialid | None | - | software_load | 20.01 | - | subfunction_avail | available | - | subfunction_oper | enabled | - | subfunctions | controller,worker | - | task | | - | tboot | false | - | ttys_dcd | None | - | updated_at | 2020-04-22T12:20:25.248838+00:00 | - | uptime | 10587 | - | uuid | 41296fac-5b16-4c52-9296-5b720100f8b5 | - | vim_progress_status | services-enabled | - +-----------------------+----------------------------------------------------------------------+ - ----------- -Next steps ----------- - -.. include:: ../kubernetes_install_next.txt diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/aio_simplex.rst b/doc/source/deploy_install_guides/r3_release/bare_metal/aio_simplex.rst deleted file mode 100644 index c2ac9b6a5..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/aio_simplex.rst +++ /dev/null @@ -1,21 +0,0 @@ -=============================================== -Bare metal All-in-one Simplex Installation R3.0 -=============================================== - --------- -Overview --------- - -.. include:: ../desc_aio_simplex.txt - -.. include:: ../ipv6_note.txt - ------------- -Installation ------------- - -.. toctree:: - :maxdepth: 1 - - aio_simplex_hardware - aio_simplex_install_kubernetes diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/aio_simplex_install_kubernetes.rst b/doc/source/deploy_install_guides/r3_release/bare_metal/aio_simplex_install_kubernetes.rst deleted file mode 100644 index ddd0e489f..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/aio_simplex_install_kubernetes.rst +++ /dev/null @@ -1,510 +0,0 @@ -================================================= -Install StarlingX Kubernetes on Bare Metal AIO-SX -================================================= - -This section describes the steps to install the StarlingX Kubernetes platform -on a **StarlingX R3.0 bare metal All-in-one Simplex** deployment configuration. - -.. contents:: - :local: - :depth: 1 - ---------------------- -Create a bootable USB ---------------------- - -Refer to :doc:`/deploy_install_guides/bootable_usb` for instructions on how to -create a bootable USB with the StarlingX ISO on your system. - --------------------------------- -Install software on controller-0 --------------------------------- - -.. incl-install-software-controller-0-aio-simplex-start: - -#. Insert the bootable USB into a bootable USB port on the host you are - configuring as controller-0. - -#. Power on the host. - -#. Attach to a console, ensure the host boots from the USB, and wait for the - StarlingX Installer Menus. - -#. Make the following menu selections in the installer: - - #. First menu: Select 'All-in-one Controller Configuration'. - #. Second menu: Select 'Graphical Console' or 'Serial Console' depending on - your terminal access to the console port. - - .. figure:: ../figures/starlingx-aio-controller-configuration.png - :alt: starlingx-controller-configuration - - *Figure 1: StarlingX Controller Configuration* - - - .. figure:: ../figures/starlingx-aio-serial-console.png - :alt: starlingx-serial-console - - *Figure 2: StarlingX Serial Console* - -Wait for non-interactive install of software to complete and server to reboot. -This can take 5-10 minutes, depending on the performance of the server. - -.. incl-install-software-controller-0-aio-simplex-end: - --------------------------------- -Bootstrap system on controller-0 --------------------------------- - -#. Login using the username / password of "sysadmin" / "sysadmin". - When logging in for the first time, you will be forced to change the password. - - :: - - Login: sysadmin - Password: - Changing password for sysadmin. - (current) UNIX Password: sysadmin - New Password: - (repeat) New Password: - -#. Verify and/or configure IP connectivity. - - External connectivity is required to run the Ansible bootstrap playbook. The - StarlingX boot image will DHCP out all interfaces so the server may have - obtained an IP address and have external IP connectivity if a DHCP server is - present in your environment. Verify this using the :command:`ip addr` and - :command:`ping 8.8.8.8` commands. - - Otherwise, manually configure an IP address and default IP route. Use the - PORT, IP-ADDRESS/SUBNET-LENGTH and GATEWAY-IP-ADDRESS applicable to your - deployment environment. - - :: - - sudo ip address add / dev - sudo ip link set up dev - sudo ip route add default via dev - ping 8.8.8.8 - -#. Specify user configuration overrides for the Ansible bootstrap playbook. - - Ansible is used to bootstrap StarlingX on controller-0. Key files for Ansible - configuration are: - - ``/etc/ansible/hosts`` - The default Ansible inventory file. Contains a single host: localhost. - - ``/usr/share/ansible/stx-ansible/playbooks/bootstrap.yml`` - The Ansible bootstrap playbook. - - ``/usr/share/ansible/stx-ansible/playbooks/host_vars/bootstrap/default.yml`` - The default configuration values for the bootstrap playbook. - - ``sysadmin home directory ($HOME)`` - The default location where Ansible looks for and imports user - configuration override files for hosts. For example: ``$HOME/.yml``. - - .. include:: ../ansible_install_time_only.txt - - Specify the user configuration override file for the Ansible bootstrap - playbook using one of the following methods: - - #. Use a copy of the default.yml file listed above to provide your overrides. - - The default.yml file lists all available parameters for bootstrap - configuration with a brief description for each parameter in the file comments. - - To use this method, copy the default.yml file listed above to - ``$HOME/localhost.yml`` and edit the configurable values as desired. - - #. Create a minimal user configuration override file. - - To use this method, create your override file at ``$HOME/localhost.yml`` - and provide the minimum required parameters for the deployment configuration - as shown in the example below. Use the OAM IP SUBNET and IP ADDRESSing - applicable to your deployment environment. - - :: - - cd ~ - cat < localhost.yml - system_mode: simplex - - dns_servers: - - 8.8.8.8 - - 8.8.4.4 - - external_oam_subnet: / - external_oam_gateway_address: - external_oam_floating_address: - - admin_username: admin - admin_password: - ansible_become_pass: - - # Add these lines to configure Docker to use a proxy server - # docker_http_proxy: http://my.proxy.com:1080 - # docker_https_proxy: https://my.proxy.com:1443 - # docker_no_proxy: - # - 1.2.3.4 - - EOF - - Refer to :doc:`/deploy_install_guides/r3_release/ansible_bootstrap_configs` - for information on additional Ansible bootstrap configurations for advanced - Ansible bootstrap scenarios, such as Docker proxies when deploying behind a - firewall, etc. Refer to :doc:`/../../configuration/docker_proxy_config` for - details about Docker proxy settings. - -#. Run the Ansible bootstrap playbook: - - :: - - ansible-playbook /usr/share/ansible/stx-ansible/playbooks/bootstrap.yml - - Wait for Ansible bootstrap playbook to complete. - This can take 5-10 minutes, depending on the performance of the host machine. - - The image below shows a typical successful run. - - .. figure:: ../figures/starlingx-release3-ansible-bootstrap-simplex.png - :alt: ansible bootstarp install screen - :width: 800 - - *Figure 3: StarlingX Ansible Bootstrap* - ----------------------- -Configure controller-0 ----------------------- - -#. Acquire admin credentials: - - :: - - source /etc/platform/openrc - -#. At this stage, you can see the controller status, it will be in the locked state. - - :: - - [sysadmin@localhost ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. Configure the OAM interface of controller-0 and specify the attached network - as "oam". Use the OAM port name that is applicable to your deployment - environment, for example eth0: - - :: - - OAM_IF= - system host-if-modify controller-0 $OAM_IF -c platform - system interface-network-assign controller-0 $OAM_IF oam - -#. If the system is a subcloud in a distributed cloud environment, then the mgmt - network and cluster-host networks must be configured on an actual interface - and not left on the loopback interface. - - .. important:: - - Complete this step only if the system is a subcloud in a distributed cloud - environment! - - For example: - - :: - - MGMT_IF= - system host-if-modify controller-0 lo -c none - IFNET_UUIDS=$(system interface-network-list controller-0 | awk '{if ($6=="lo") print $4;}') - for UUID in $IFNET_UUIDS; do - system interface-network-remove ${UUID} - done - system host-if-modify controller-0 $MGMT_IF -c platform - system interface-network-assign controller-0 $MGMT_IF mgmt - system interface-network-assign controller-0 $MGMT_IF cluster-host - -#. Configure NTP Servers for network time synchronization: - - :: - - system ntp-modify ntpservers=0.pool.ntp.org,1.pool.ntp.org - -#. Configure data interfaces for controller-0. Use the DATA port names, for example - eth0, applicable to your deployment environment. - - .. important:: - - This step is **required** for OpenStack. - - This step is optional for Kubernetes: Do this step if using SRIOV network - attachments in hosted application containers. - - For Kubernetes SRIOV network attachments: - - * Configure the SRIOV device plugin - - :: - - system host-label-assign controller-0 sriovdp=enabled - - * If planning on running DPDK in containers on this host, configure the number - of 1G Huge pages required on both NUMA nodes. - - :: - - system host-memory-modify controller-0 0 -1G 100 - system host-memory-modify controller-0 1 -1G 100 - - For both Kubernetes and OpenStack: - - :: - - DATA0IF= - DATA1IF= - export NODE=controller-0 - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - system host-port-list ${NODE} --nowrap > ${SPL} - system host-if-list -a ${NODE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - system host-if-modify -m 1500 -n data0 -c data ${NODE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${NODE} ${DATA1IFUUID} - system interface-datanetwork-assign ${NODE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${NODE} ${DATA1IFUUID} ${PHYSNET1} - -#. Add an OSD on controller-0 for Ceph. The following example adds an OSD - to the `sdb` disk: - - :: - - echo ">>> Add OSDs to primary tier" - system host-disk-list controller-0 - system host-disk-list controller-0 | awk '/\/dev\/sdb/{print $2}' | xargs -i system host-stor-add controller-0 {} - system host-stor-list controller-0 - -#. If required, and not already done as part of bootstrap, configure Docker to - use a proxy server. - - #. List Docker proxy parameters: - - :: - - system service-parameter-list platform docker - - #. Refer to :doc:`/../../configuration/docker_proxy_config` for - details about Docker proxy settings. - -************************************* -OpenStack-specific host configuration -************************************* - -.. incl-config-controller-0-openstack-specific-aio-simplex-start: - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to controller-0 in - support of installing the stx-openstack manifest and helm-charts later. - - :: - - system host-label-assign controller-0 openstack-control-plane=enabled - system host-label-assign controller-0 openstack-compute-node=enabled - system host-label-assign controller-0 openvswitch=enabled - system host-label-assign controller-0 sriov=enabled - -#. **For OpenStack only:** Configure the system setting for the vSwitch. - - StarlingX has OVS (kernel-based) vSwitch configured as default: - - * Runs in a container; defined within the helm charts of stx-openstack - manifest. - * Shares the core(s) assigned to the platform. - - If you require better performance, OVS-DPDK (OVS with the Data Plane - Development Kit, which is supported only on bare metal hardware) should be - used: - - * Runs directly on the host (it is not containerized). - * Requires that at least 1 core be assigned/dedicated to the vSwitch function. - - To deploy the default containerized OVS: - - :: - - system modify --vswitch_type none - - Do not run any vSwitch directly on the host, instead, use the containerized - OVS defined in the helm charts of stx-openstack manifest. - - To deploy OVS-DPDK, run the following command: - - :: - - system modify --vswitch_type ovs-dpdk - system host-cpu-modify -f vswitch -p0 1 controller-0 - - Once vswitch_type is set to OVS-DPDK, any subsequent nodes created will - default to automatically assigning 1 vSwitch core for AIO controllers and 2 - vSwitch cores for compute-labeled worker nodes. - - When using OVS-DPDK, configure vSwitch memory per NUMA node with the following - command: - - :: - - system host-memory-modify -f -1G <1G hugepages number> - - For example: - - :: - - system host-memory-modify -f vswitch -1G 1 worker-0 0 - - VMs created in an OVS-DPDK environment must be configured to use huge pages - to enable networking and must use a flavor with property: hw:mem_page_size=large - - Configure the huge pages for VMs in an OVS-DPDK environment with the command: - - :: - - system host-memory-modify -1G <1G hugepages number> - - For example: - - :: - - system host-memory-modify worker-0 0 -1G 10 - - .. note:: - - After controller-0 is unlocked, changing vswitch_type requires - locking and unlocking all compute-labeled worker nodes (and/or AIO - controllers) to apply the change. - -#. **For OpenStack only:** Set up disk partition for nova-local volume group, - which is needed for stx-openstack nova ephemeral disks. - - :: - - export NODE=controller-0 - - echo ">>> Getting root disk info" - ROOT_DISK=$(system host-show ${NODE} | grep rootfs | awk '{print $4}') - ROOT_DISK_UUID=$(system host-disk-list ${NODE} --nowrap | grep ${ROOT_DISK} | awk '{print $2}') - echo "Root disk: $ROOT_DISK, UUID: $ROOT_DISK_UUID" - - echo ">>>> Configuring nova-local" - NOVA_SIZE=34 - NOVA_PARTITION=$(system host-disk-partition-add -t lvm_phys_vol ${NODE} ${ROOT_DISK_UUID} ${NOVA_SIZE}) - NOVA_PARTITION_UUID=$(echo ${NOVA_PARTITION} | grep -ow "| uuid | [a-z0-9\-]* |" | awk '{print $4}') - system host-lvg-add ${NODE} nova-local - system host-pv-add ${NODE} nova-local ${NOVA_PARTITION_UUID} - sleep 2 - -.. incl-config-controller-0-openstack-specific-aio-simplex-end: - -------------------- -Unlock controller-0 -------------------- - -.. incl-unlock-controller-0-aio-simplex-start: - -Unlock controller-0 in order to bring it into service: - -:: - - system host-unlock controller-0 - -Controller-0 will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host machine. - -.. note:: - - Once the controller comes back up, check the status of controller-0. It should - now show "unlocked", "enabled", "available" and "provisioned". - -:: - - [sysadmin@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - +----+--------------+-------------+----------------+-------------+--------------+ - [sysadmin@controller-0 ~(keystone_admin)]$ - - =============================================== - [sysadmin@controller-0 ~(keystone_admin)]$ system host-show controller-0 - +-----------------------+------------------------------------------------------------ ----------+ - | Property | Value | - +-----------------------+------------------------------------------------------------ ----------+ - | action | none | - | administrative | unlocked | - | availability | available | - | bm_ip | None | - | bm_type | none | - | bm_username | None - | boot_device | /dev/disk/by-path/pci-0000:00:1f.2-ata-1.0 | - | capabilities | {u'stor_function': u'monitor', u'Personality': u'Controller-Active'} | - | clock_synchronization | ntp | - | config_applied | 03e22d8b-1b1f-4c52-9500-96afad295d9a | - | config_status | None | - | config_target | 03e22d8b-1b1f-4c52-9500-96afad295d9a | - | console | ttyS0,115200 | - | created_at | 2020-03-09T12:34:34.866469+00:00 | - | hostname | controller-0 | - | id | 1 | - | install_output | text | - | install_state | None | - | install_state_info | None | - | inv_state | inventoried | - | invprovision | provisioned | - | location | {} | - | mgmt_ip | 192.168.204.2 | - | mgmt_mac | 00:00:00:00:00:00 | - | operational | enabled | - | personality | controller | - | reserved | False | - | rootfs_device | /dev/disk/by-path/pci-0000:00:1f.2-ata-1.0 | - | serialid | None | - | software_load | 19.12 | - | subfunction_avail | available | - | subfunction_oper | enabled | - | subfunctions | controller,worker | - | task | | - | tboot | false | - | ttys_dcd | None | - | updated_at | 2020-03-09T14:10:42.362846+00:00 | - | uptime | 991 | - | uuid | 66aa842e-84a2-4041-b93e-f0275cde8784 | - | vim_progress_status | services-enabled | - +-----------------------+------------------------------------------------------------ ----------+ - -.. incl-unlock-controller-0-aio-simplex-end: - ----------- -Next steps ----------- - -.. include:: ../kubernetes_install_next.txt diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/controller_storage.rst b/doc/source/deploy_install_guides/r3_release/bare_metal/controller_storage.rst deleted file mode 100644 index 3478944cc..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/controller_storage.rst +++ /dev/null @@ -1,22 +0,0 @@ -============================================================= -Bare metal Standard with Controller Storage Installation R3.0 -============================================================= - --------- -Overview --------- - -.. include:: ../desc_controller_storage.txt - -.. include:: ../ipv6_note.txt - - ------------- -Installation ------------- - -.. toctree:: - :maxdepth: 1 - - controller_storage_hardware - controller_storage_install_kubernetes diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/controller_storage_hardware.rst b/doc/source/deploy_install_guides/r3_release/bare_metal/controller_storage_hardware.rst deleted file mode 100644 index 06567788b..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/controller_storage_hardware.rst +++ /dev/null @@ -1,56 +0,0 @@ -===================== -Hardware Requirements -===================== - -This section describes the hardware requirements and server preparation for a -**StarlingX R3.0 bare metal Standard with Controller Storage** deployment -configuration. - -.. contents:: - :local: - :depth: 1 - ------------------------------ -Minimum hardware requirements ------------------------------ - -The recommended minimum hardware requirements for bare metal servers for various -host types are: - -+-------------------------+-----------------------------+-----------------------------+ -| Minimum Requirement | Controller Node | Worker Node | -+=========================+=============================+=============================+ -| Number of servers | 2 | 2-10 | -+-------------------------+-----------------------------+-----------------------------+ -| Minimum processor class | - Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) | -| | 8 cores/socket | -+-------------------------+-----------------------------+-----------------------------+ -| Minimum memory | 64 GB | 32 GB | -+-------------------------+-----------------------------+-----------------------------+ -| Primary disk | 500 GB SSD or NVMe (see | 120 GB (Minimum 10k RPM) | -| | :doc:`../../nvme_config`) | | -+-------------------------+-----------------------------+-----------------------------+ -| Additional disks | - 1 or more 500 GB (min. | - For OpenStack, recommend | -| | 10K RPM) for Ceph OSD | 1 or more 500 GB (min. | -| | - Recommended, but not | 10K RPM) for VM local | -| | required: 1 or more SSDs | ephemeral storage | -| | or NVMe drives for Ceph | | -| | journals (min. 1024 MiB | | -| | per OSD journal) | | -+-------------------------+-----------------------------+-----------------------------+ -| Minimum network ports | - Mgmt/Cluster: 1x10GE | - Mgmt/Cluster: 1x10GE | -| | - OAM: 1x1GE | - Data: 1 or more x 10GE | -+-------------------------+-----------------------------+-----------------------------+ -| BIOS settings | - Hyper-Threading technology enabled | -| | - Virtualization technology enabled | -| | - VT for directed I/O enabled | -| | - CPU power and performance policy set to performance | -| | - CPU C state control disabled | -| | - Plug & play BMC detection disabled | -+-------------------------+-----------------------------+-----------------------------+ - --------------------------- -Prepare bare metal servers --------------------------- - -.. include:: prep_servers.txt \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/controller_storage_install_kubernetes.rst b/doc/source/deploy_install_guides/r3_release/bare_metal/controller_storage_install_kubernetes.rst deleted file mode 100644 index 31a8dfde5..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/controller_storage_install_kubernetes.rst +++ /dev/null @@ -1,773 +0,0 @@ -=========================================================================== -Install StarlingX Kubernetes on Bare Metal Standard with Controller Storage -=========================================================================== - -This section describes the steps to install the StarlingX Kubernetes platform -on a **StarlingX R3.0 bare metal Standard with Controller Storage** deployment -configuration. - -.. contents:: - :local: - :depth: 1 - -------------------- -Create bootable USB -------------------- - -Refer to :doc:`/deploy_install_guides/bootable_usb` for instructions on how to -create a bootable USB with the StarlingX ISO on your system. - --------------------------------- -Install software on controller-0 --------------------------------- - -.. incl-install-software-controller-0-standard-start: - -#. Insert the bootable USB into a bootable USB port on the host you are - configuring as controller-0. - -#. Power on the host. - -#. Attach to a console, ensure the host boots from the USB, and wait for the - StarlingX Installer Menus. - -#. Make the following menu selections in the installer: - - #. First menu: Select 'Standard Controller Configuration'. - #. Second menu: Select 'Graphical Console' or 'Serial Console' depending on - your terminal access to the console port. - - .. figure:: ../figures/starlingx-standard-controller-configuration.png - :scale: 47% - :alt: starlingx-controller-configuration - - *Figure 1: StarlingX Controller Configuration* - - - .. figure:: ../figures/starlingx-aio-serial-console.png - :alt: starlingx--serial-console - - *Figure 2: StarlingX Serial Console* - - Wait for non-interactive install of software to complete and server to reboot. - This can take 5-10 minutes, depending on the performance of the server. - -.. incl-install-software-controller-0-standard-end: - --------------------------------- -Bootstrap system on controller-0 --------------------------------- - -.. incl-bootstrap-sys-controller-0-standard-start: - -#. Login using the username / password of "sysadmin" / "sysadmin". - - When logging in for the first time, you will be forced to change the password. - - :: - - Login: sysadmin - Password: - Changing password for sysadmin. - (current) UNIX Password: sysadmin - New Password: - (repeat) New Password: - -#. Verify and/or configure IP connectivity. - - External connectivity is required to run the Ansible bootstrap playbook. The - StarlingX boot image will DHCP out all interfaces so the server may have - obtained an IP address and have external IP connectivity if a DHCP server is - present in your environment. Verify this using the :command:`ip addr` and - :command:`ping 8.8.8.8` commands. - - Otherwise, manually configure an IP address and default IP route. Use the - PORT, IP-ADDRESS/SUBNET-LENGTH and GATEWAY-IP-ADDRESS applicable to your - deployment environment. - - :: - - sudo ip address add / dev - sudo ip link set up dev - sudo ip route add default via dev - ping 8.8.8.8 - -#. Specify user configuration overrides for the Ansible bootstrap playbook. - - Ansible is used to bootstrap StarlingX on controller-0. Key files for Ansible - configuration are: - - ``/etc/ansible/hosts`` - The default Ansible inventory file. Contains a single host: localhost. - - ``/usr/share/ansible/stx-ansible/playbooks/bootstrap.yml`` - The Ansible bootstrap playbook. - - ``/usr/share/ansible/stx-ansible/playbooks/host_vars/bootstrap/default.yml`` - The default configuration values for the bootstrap playbook. - - ``sysadmin home directory ($HOME)`` - The default location where Ansible looks for and imports user - configuration override files for hosts. For example: ``$HOME/.yml``. - - .. include:: ../ansible_install_time_only.txt - - Specify the user configuration override file for the Ansible bootstrap - playbook using one of the following methods: - - #. Use a copy of the default.yml file listed above to provide your overrides. - - The default.yml file lists all available parameters for bootstrap - configuration with a brief description for each parameter in the file comments. - - To use this method, copy the default.yml file listed above to - ``$HOME/localhost.yml`` and edit the configurable values as desired. - - #. Create a minimal user configuration override file. - - To use this method, create your override file at ``$HOME/localhost.yml`` - and provide the minimum required parameters for the deployment configuration - as shown in the example below. Use the OAM IP SUBNET and IP ADDRESSing - applicable to your deployment environment. - - :: - - cd ~ - cat < localhost.yml - system_mode: duplex - - dns_servers: - - 8.8.8.8 - - 8.8.4.4 - - external_oam_subnet: / - external_oam_gateway_address: - external_oam_floating_address: - external_oam_node_0_address: - external_oam_node_1_address: - - admin_username: admin - admin_password: - ansible_become_pass: - - # Add these lines to configure Docker to use a proxy server - # docker_http_proxy: http://my.proxy.com:1080 - # docker_https_proxy: https://my.proxy.com:1443 - # docker_no_proxy: - # - 1.2.3.4 - - EOF - - Refer to :doc:`/deploy_install_guides/r3_release/ansible_bootstrap_configs` - for information on additional Ansible bootstrap configurations for advanced - Ansible bootstrap scenarios, such as Docker proxies when deploying behind a - firewall, etc. Refer to :doc:`/../../configuration/docker_proxy_config` for - details about Docker proxy settings. - -#. Run the Ansible bootstrap playbook: - - :: - - ansible-playbook /usr/share/ansible/stx-ansible/playbooks/bootstrap.yml - - Wait for Ansible bootstrap playbook to complete. - This can take 5-10 minutes, depending on the performance of the host machine. - - The image below shows a typical successful run. - - .. figure:: ../figures/starlingx-release3-ansible-bootstrap-simplex.png - :alt: ansible bootstrap install screen - :width: 800 - - *Figure 3: StarlingX Ansible Bootstrap* - -.. incl-bootstrap-sys-controller-0-standard-end: - - ----------------------- -Configure controller-0 ----------------------- - -.. incl-config-controller-0-storage-start: - -#. Acquire admin credentials: - - :: - - source /etc/platform/openrc - -#. Configure the OAM and MGMT interfaces of controller-0 and specify the - attached networks. Use the OAM and MGMT port names, for example eth0, that are - applicable to your deployment environment. - - :: - - OAM_IF= - MGMT_IF= - system host-if-modify controller-0 lo -c none - IFNET_UUIDS=$(system interface-network-list controller-0 | awk '{if ($6=="lo") print $4;}') - for UUID in $IFNET_UUIDS; do - system interface-network-remove ${UUID} - done - system host-if-modify controller-0 $OAM_IF -c platform - system interface-network-assign controller-0 $OAM_IF oam - system host-if-modify controller-0 $MGMT_IF -c platform - system interface-network-assign controller-0 $MGMT_IF mgmt - system interface-network-assign controller-0 $MGMT_IF cluster-host - -#. Configure NTP Servers for network time synchronization: - - :: - - system ntp-modify ntpservers=0.pool.ntp.org,1.pool.ntp.org - -#. If required, and not already done as part of bootstrap, configure Docker to - use a proxy server. - - #. List Docker proxy parameters: - - :: - - system service-parameter-list platform docker - - #. Refer to :doc:`/../../configuration/docker_proxy_config` for - details about Docker proxy settings. - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to controller-0 in - support of installing the stx-openstack manifest and helm-charts later. - - :: - - system host-label-assign controller-0 openstack-control-plane=enabled - -#. **For OpenStack only:** Configure the system setting for the vSwitch. - - StarlingX has OVS (kernel-based) vSwitch configured as default: - - * Runs in a container; defined within the helm charts of stx-openstack - manifest. - * Shares the core(s) assigned to the platform. - - If you require better performance, OVS-DPDK (OVS with the Data Plane - Development Kit, which is supported only on bare metal hardware) should be - used: - - * Runs directly on the host (it is not containerized). - * Requires that at least 1 core be assigned/dedicated to the vSwitch function. - - To deploy the default containerized OVS: - - :: - - system modify --vswitch_type none - - Do not run any vSwitch directly on the host, instead, use the containerized - OVS defined in the helm charts of stx-openstack manifest. - - To deploy OVS-DPDK, run the following command: - - :: - - system modify --vswitch_type ovs-dpdk - system host-cpu-modify -f vswitch -p0 1 controller-0 - - Once vswitch_type is set to OVS-DPDK, any subsequent nodes created will - default to automatically assigning 1 vSwitch core for AIO controllers and 2 - vSwitch cores for compute-labeled worker nodes. - - When using OVS-DPDK, configure vSwitch memory per NUMA node with the following - command: - - :: - - system host-memory-modify -f -1G <1G hugepages number> - - For example: - - :: - - system host-memory-modify -f vswitch -1G 1 worker-0 0 - - VMs created in an OVS-DPDK environment must be configured to use huge pages - to enable networking and must use a flavor with property: hw:mem_page_size=large - - Configure the huge pages for VMs in an OVS-DPDK environment with the command: - - :: - - system host-memory-modify -1G <1G hugepages number> - - For example: - - :: - - system host-memory-modify worker-0 0 -1G 10 - - .. note:: - - After controller-0 is unlocked, changing vswitch_type requires - locking and unlocking all compute-labeled worker nodes (and/or AIO - controllers) to apply the change. - -.. incl-config-controller-0-storage-end: - -------------------- -Unlock controller-0 -------------------- - -.. incl-unlock-controller-0-storage-start: - -Unlock controller-0 in order to bring it into service: - -:: - - system host-unlock controller-0 - -Controller-0 will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host machine. - -.. note:: - - Once the controller comes back up, check the status of controller-0. It should - now show "unlocked", "enabled", "available" and "provisioned". - -:: - - [sysadmin@controller-0 ~(keystone_admin)]$ system host-show controller-0 - +-----------------------+----------------------------------------------------------------------+ - | Property | Value | - +-----------------------+----------------------------------------------------------------------+ - | action | none | - | administrative | unlocked | - | availability | available | - | bm_ip | None | - | bm_type | none | - | bm_username | None | - | boot_device | /dev/disk/by-path/pci-0000:00:17.0-ata-1.0 | - | capabilities | {u'stor_function': u'monitor', u'Personality': u'Controller-Active'} | - | clock_synchronization | ntp | - | config_applied | 4bb28c10-7546-49be-8cf9-afc82fccf6fb | - | config_status | None | - | config_target | 4bb28c10-7546-49be-8cf9-afc82fccf6fb | - | console | ttyS0,115200 | - | created_at | 2020-04-22T06:03:45.823265+00:00 | - | hostname | controller-0 | - | id | 1 | - | install_output | text | - | install_state | None | - | install_state_info | None | - | inv_state | inventoried | - | invprovision | provisioned | - | location | {} | - | mgmt_ip | 10.10.54.11 | - | mgmt_mac | a4:bf:01:54:97:96 | - | operational | enabled | - | personality | controller | - | reserved | False | - | rootfs_device | /dev/disk/by-path/pci-0000:00:17.0-ata-1.0 | - | serialid | None | - | software_load | 20.01 | - | task | | - | tboot | false | - | ttys_dcd | None | - | updated_at | 2020-04-22T10:36:37.034403+00:00 | - | uptime | 15224 | - | uuid | 770f6596-f631-489b-83c0-e64099748243 | - | vim_progress_status | services-enabled | - +-----------------------+----------------------------------------------------------------------+ - -.. incl-unlock-controller-0-storage-end: - -------------------------------------------------- -Install software on controller-1 and worker nodes -------------------------------------------------- - -#. Power on the controller-1 server and force it to network boot with the - appropriate BIOS boot options for your particular server. - -#. As controller-1 boots, a message appears on its console instructing you to - configure the personality of the node. - -#. On the console of controller-0, list hosts to see newly discovered controller-1 - host (hostname=None): - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. Using the host id, set the personality of this host to 'controller': - - :: - - system host-update 2 personality=controller - - This initiates the install of software on controller-1. - This can take 5-10 minutes, depending on the performance of the host machine. - -#. While waiting for the previous step to complete, power on the worker nodes. - Set the personality to 'worker' and assign a unique hostname for each. - - For example, power on worker-0 and wait for the new host (hostname=None) to - be discovered by checking 'system host-list': - - :: - - system host-update 3 personality=worker hostname=worker-0 - - Repeat for worker-1. Power on worker-1 and wait for the new host (hostname=None) to - be discovered by checking 'system host-list': - - :: - - system host-update 4 personality=worker hostname=worker-1 - -#. Wait for the software installation on controller-1, worker-0, and worker-1 to - complete, for all servers to reboot, and for all to show as locked/disabled/online in - 'system host-list'. - - :: - - system host-list - - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | locked | disabled | online | - | 3 | worker-0 | worker | locked | disabled | online | - | 4 | worker-1 | worker | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - ----------------------- -Configure controller-1 ----------------------- - -.. incl-config-controller-1-start: - -Configure the OAM and MGMT interfaces of controller-1 and specify the attached -networks. Use the OAM and MGMT port names, for example eth0, that are applicable -to your deployment environment. - -(Note that the MGMT interface is partially set up automatically by the network -install procedure.) - -:: - - OAM_IF= - MGMT_IF= - system host-if-modify controller-1 $OAM_IF -c platform - system interface-network-assign controller-1 $OAM_IF oam - system interface-network-assign controller-1 $MGMT_IF cluster-host - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -**For OpenStack only:** Assign OpenStack host labels to controller-1 in support -of installing the stx-openstack manifest and helm-charts later. - -:: - - system host-label-assign controller-1 openstack-control-plane=enabled - -.. incl-config-controller-1-end: - -------------------- -Unlock controller-1 -------------------- - -.. incl-unlock-controller-1-start: - -Unlock controller-1 in order to bring it into service: - -:: - - system host-unlock controller-1 - -Controller-1 will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host -machine. - -:: - - [sysadmin@controller-0 ~(keystone_admin)]$ system host-show controller-1 - +-----------------------+-----------------------------------------------------------------------+ - | Property | Value | - +-----------------------+-----------------------------------------------------------------------+ - | action | none | - | administrative | unlocked | - | availability | available | - | bm_ip | None | - | bm_type | none | - | bm_username | None | - | boot_device | /dev/sda | - | capabilities | {u'stor_function': u'monitor', u'Personality': u'Controller-Standby'} | - | clock_synchronization | ntp | - | config_applied | 4bb28c10-7546-49be-8cf9-afc82fccf6fb | - | config_status | None | - | config_target | 4bb28c10-7546-49be-8cf9-afc82fccf6fb | - | console | ttyS0,115200 | - | created_at | 2020-04-22T06:45:14.914066+00:00 | - | hostname | controller-1 | - | id | 4 | - | install_output | text | - | install_state | completed | - | install_state_info | None | - | inv_state | inventoried | - | invprovision | provisioned | - | location | {} | - | mgmt_ip | 10.10.54.12 | - | mgmt_mac | a4:bf:01:55:05:eb | - | operational | enabled | - | personality | controller | - | reserved | False | - | rootfs_device | /dev/sda | - | serialid | None | - | software_load | 20.01 | - | task | | - | tboot | false | - | ttys_dcd | None | - | updated_at | 2020-04-22T10:37:11.563565+00:00 | - | uptime | 1611 | - | uuid | c296480a-3303-4e1a-a131-178a0d7d5a6d | - | vim_progress_status | services-enabled | - +-----------------------+-----------------------------------------------------------------------+ - -.. incl-unlock-controller-1-end: - ----------------------- -Configure worker nodes ----------------------- - -#. Add the third Ceph monitor to a worker node: - - (The first two Ceph monitors are automatically assigned to controller-0 and - controller-1.) - - :: - - system ceph-mon-add worker-0 - -#. Wait for the worker node monitor to complete configuration: - - :: - - system ceph-mon-list - +--------------------------------------+-------+--------------+------------+------+ - | uuid | ceph_ | hostname | state | task | - | | mon_g | | | | - | | ib | | | | - +--------------------------------------+-------+--------------+------------+------+ - | 64176b6c-e284-4485-bb2a-115dee215279 | 20 | controller-1 | configured | None | - | a9ca151b-7f2c-4551-8167-035d49e2df8c | 20 | controller-0 | configured | None | - | f76bc385-190c-4d9a-aa0f-107346a9907b | 20 | worker-0 | configured | None | - +--------------------------------------+-------+--------------+------------+------+ - -#. Assign the cluster-host network to the MGMT interface for the worker nodes: - - (Note that the MGMT interfaces are partially set up automatically by the - network install procedure.) - - :: - - for NODE in worker-0 worker-1; do - system interface-network-assign $NODE mgmt0 cluster-host - done - -#. Configure data interfaces for worker nodes. Use the DATA port names, for - example eth0, that are applicable to your deployment environment. - - .. important:: - - This step is **required** for OpenStack. - - This step is optional for Kubernetes: Do this step if using SRIOV network - attachments in hosted application containers. - - For Kubernetes SRIOV network attachments: - - * Configure SRIOV device plug in: - - :: - - for NODE in worker-0 worker-1; do - system host-label-assign ${NODE} sriovdp=enabled - done - - * If planning on running DPDK in containers on this host, configure the number - of 1G Huge pages required on both NUMA nodes: - - :: - - for NODE in worker-0 worker-1; do - system host-memory-modify ${NODE} 0 -1G 100 - system host-memory-modify ${NODE} 1 -1G 100 - done - - For both Kubernetes and OpenStack: - - :: - - DATA0IF= - DATA1IF= - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - - # configure the datanetworks in sysinv, prior to referencing it - # in the ``system host-if-modify`` command'. - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - for NODE in worker-0 worker-1; do - echo "Configuring interface for: $NODE" - set -ex - system host-port-list ${NODE} --nowrap > ${SPL} - system host-if-list -a ${NODE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - system host-if-modify -m 1500 -n data0 -c data ${NODE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${NODE} ${DATA1IFUUID} - system interface-datanetwork-assign ${NODE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${NODE} ${DATA1IFUUID} ${PHYSNET1} - set +ex - done - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to the worker nodes in - support of installing the stx-openstack manifest and helm-charts later. - - :: - - for NODE in worker-0 worker-1; do - system host-label-assign $NODE openstack-compute-node=enabled - system host-label-assign $NODE openvswitch=enabled - system host-label-assign $NODE sriov=enabled - done - -#. **For OpenStack only:** Set up disk partition for nova-local volume group, - which is needed for stx-openstack nova ephemeral disks. - - :: - - for NODE in worker-0 worker-1; do - echo "Configuring Nova local for: $NODE" - ROOT_DISK=$(system host-show ${NODE} | grep rootfs | awk '{print $4}') - ROOT_DISK_UUID=$(system host-disk-list ${NODE} --nowrap | grep ${ROOT_DISK} | awk '{print $2}') - PARTITION_SIZE=10 - NOVA_PARTITION=$(system host-disk-partition-add -t lvm_phys_vol ${NODE} ${ROOT_DISK_UUID} ${PARTITION_SIZE}) - NOVA_PARTITION_UUID=$(echo ${NOVA_PARTITION} | grep -ow "| uuid | [a-z0-9\-]* |" | awk '{print $4}') - system host-lvg-add ${NODE} nova-local - system host-pv-add ${NODE} nova-local ${NOVA_PARTITION_UUID} - done - --------------------- -Unlock worker nodes --------------------- - -.. incl-unlock-worker-baremetal-start: - -Unlock worker nodes in order to bring them into service: - -:: - - for NODE in worker-0 worker-1; do - system host-unlock $NODE - done - -The worker nodes will reboot in order to apply configuration changes and come into -service. This can take 5-10 minutes, depending on the performance of the host machine. - -.. incl-unlock-worker-baremetal-end: - ----------------------------- -Add Ceph OSDs to controllers ----------------------------- - -#. Add OSDs to controller-0. The following example adds OSDs to the `sdb` disk: - - :: - - HOST=controller-0 - DISKS=$(system host-disk-list ${HOST}) - TIERS=$(system storage-tier-list ceph_cluster) - OSDs="/dev/sdb" - for OSD in $OSDs; do - system host-stor-add ${HOST} $(echo "$DISKS" | grep "$OSD" | awk '{print $2}') --tier-uuid $(echo "$TIERS" | grep storage | awk '{print $2}') - while true; do system host-stor-list ${HOST} | grep ${OSD} | grep configuring; if [ $? -ne 0 ]; then break; fi; sleep 1; done - done - - system host-stor-list $HOST - -#. Add OSDs to controller-1. The following example adds OSDs to the `sdb` disk: - - :: - - HOST=controller-1 - DISKS=$(system host-disk-list ${HOST}) - TIERS=$(system storage-tier-list ceph_cluster) - OSDs="/dev/sdb" - for OSD in $OSDs; do - system host-stor-add ${HOST} $(echo "$DISKS" | grep "$OSD" | awk '{print $2}') --tier-uuid $(echo "$TIERS" | grep storage | awk '{print $2}') - while true; do system host-stor-list ${HOST} | grep ${OSD} | grep configuring; if [ $? -ne 0 ]; then break; fi; sleep 1; done - done - - system host-stor-list $HOST - -.. note:: - - Check the status of the controller and worker nodes. It should - now show "unlocked", "enabled" and "available". - -:: - - [sysadmin@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | compute-0 | worker | unlocked | enabled | available | - | 3 | compute-1 | worker | unlocked | enabled | available | - | 4 | controller-1 | controller | unlocked | enabled | available | - +----+--------------+-------------+----------------+-------------+--------------+ - ----------- -Next steps ----------- - -.. include:: ../kubernetes_install_next.txt diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/dedicated_storage.rst b/doc/source/deploy_install_guides/r3_release/bare_metal/dedicated_storage.rst deleted file mode 100644 index 5a68c592b..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/dedicated_storage.rst +++ /dev/null @@ -1,22 +0,0 @@ - -============================================================ -Bare metal Standard with Dedicated Storage Installation R3.0 -============================================================ - --------- -Overview --------- - -.. include:: ../desc_dedicated_storage.txt - -.. include:: ../ipv6_note.txt - ------------- -Installation ------------- - -.. toctree:: - :maxdepth: 1 - - dedicated_storage_hardware - dedicated_storage_install_kubernetes diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/dedicated_storage_hardware.rst b/doc/source/deploy_install_guides/r3_release/bare_metal/dedicated_storage_hardware.rst deleted file mode 100644 index 22280ecc1..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/dedicated_storage_hardware.rst +++ /dev/null @@ -1,61 +0,0 @@ -===================== -Hardware Requirements -===================== - -This section describes the hardware requirements and server preparation for a -**StarlingX R3.0 bare metal Standard with Dedicated Storage** deployment -configuration. - -.. contents:: - :local: - :depth: 1 - ------------------------------ -Minimum hardware requirements ------------------------------ - -The recommended minimum hardware requirements for bare metal servers for various -host types are: - -+---------------------+---------------------------+-----------------------+-----------------------+ -| Minimum Requirement | Controller Node | Storage Node | Worker Node | -+=====================+===========================+=======================+=======================+ -| Number of servers | 2 | 2-9 | 2-100 | -+---------------------+---------------------------+-----------------------+-----------------------+ -| Minimum processor | Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) 8 cores/socket | -| class | | -+---------------------+---------------------------+-----------------------+-----------------------+ -| Minimum memory | 64 GB | 64 GB | 32 GB | -+---------------------+---------------------------+-----------------------+-----------------------+ -| Primary disk | 500 GB SSD or NVMe (see | 120 GB (min. 10k RPM) | 120 GB (min. 10k RPM) | -| | :doc:`../../nvme_config`) | | | -+---------------------+---------------------------+-----------------------+-----------------------+ -| Additional disks | None | - 1 or more 500 GB | - For OpenStack, | -| | | (min. 10K RPM) for | recommend 1 or more | -| | | Ceph OSD | 500 GB (min. 10K | -| | | - Recommended, but | RPM) for VM | -| | | not required: 1 or | ephemeral storage | -| | | more SSDs or NVMe | | -| | | drives for Ceph | | -| | | journals (min. 1024 | | -| | | MiB per OSD | | -| | | journal) | | -+---------------------+---------------------------+-----------------------+-----------------------+ -| Minimum network | - Mgmt/Cluster: | - Mgmt/Cluster: | - Mgmt/Cluster: | -| ports | 1x10GE | 1x10GE | 1x10GE | -| | - OAM: 1x1GE | | - Data: 1 or more | -| | | | x 10GE | -+---------------------+---------------------------+-----------------------+-----------------------+ -| BIOS settings | - Hyper-Threading technology enabled | -| | - Virtualization technology enabled | -| | - VT for directed I/O enabled | -| | - CPU power and performance policy set to performance | -| | - CPU C state control disabled | -| | - Plug & play BMC detection disabled | -+---------------------+---------------------------+-----------------------+-----------------------+ - --------------------------- -Prepare bare metal servers --------------------------- - -.. include:: prep_servers.txt \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/dedicated_storage_install_kubernetes.rst b/doc/source/deploy_install_guides/r3_release/bare_metal/dedicated_storage_install_kubernetes.rst deleted file mode 100644 index 7ea0bdbcd..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/dedicated_storage_install_kubernetes.rst +++ /dev/null @@ -1,367 +0,0 @@ -========================================================================== -Install StarlingX Kubernetes on Bare Metal Standard with Dedicated Storage -========================================================================== - -This section describes the steps to install the StarlingX Kubernetes platform -on a **StarlingX R3.0 bare metal Standard with Dedicated Storage** deployment -configuration. - -.. contents:: - :local: - :depth: 1 - -------------------- -Create bootable USB -------------------- - -Refer to :doc:`/deploy_install_guides/bootable_usb` for instructions on how to -create a bootable USB with the StarlingX ISO on your system. - --------------------------------- -Install software on controller-0 --------------------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-install-software-controller-0-standard-start: - :end-before: incl-install-software-controller-0-standard-end: - --------------------------------- -Bootstrap system on controller-0 --------------------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-bootstrap-sys-controller-0-standard-start: - :end-before: incl-bootstrap-sys-controller-0-standard-end: - ----------------------- -Configure controller-0 ----------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-config-controller-0-storage-start: - :end-before: incl-config-controller-0-storage-end: - -------------------- -Unlock controller-0 -------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-unlock-controller-0-storage-start: - :end-before: incl-unlock-controller-0-storage-end: - ------------------------------------------------------------------ -Install software on controller-1, storage nodes, and worker nodes ------------------------------------------------------------------ - -#. Power on the controller-1 server and force it to network boot with the - appropriate BIOS boot options for your particular server. - -#. As controller-1 boots, a message appears on its console instructing you to - configure the personality of the node. - -#. On the console of controller-0, list hosts to see newly discovered - controller-1 host (hostname=None): - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | None | None | locked | disabled | offline | - +----+--------------+-------------+----------------+-------------+--------------+ - -#. Using the host id, set the personality of this host to 'controller': - - :: - - system host-update 2 personality=controller - - This initiates the install of software on controller-1. - This can take 5-10 minutes, depending on the performance of the host machine. - -#. While waiting for the previous step to complete, power on the storage-0 and - storage-1 servers. Set the personality to 'storage' and assign a unique - hostname for each. - - For example, power on storage-0 and wait for the new host (hostname=None) to - be discovered by checking 'system host-list': - - :: - - system host-update 3 personality=storage - - Repeat for storage-1. Power on storage-1 and wait for the new host - (hostname=None) to be discovered by checking 'system host-list': - - :: - - system host-update 4 personality=storage - - This initiates the software installation on storage-0 and storage-1. - This can take 5-10 minutes, depending on the performance of the host machine. - -#. While waiting for the previous step to complete, power on the worker nodes. - Set the personality to 'worker' and assign a unique hostname for each. - - For example, power on worker-0 and wait for the new host (hostname=None) to - be discovered by checking 'system host-list': - - :: - - system host-update 5 personality=worker hostname=worker-0 - - Repeat for worker-1. Power on worker-1 and wait for the new host - (hostname=None) to be discovered by checking 'system host-list': - - :: - - system host-update 6 personality=worker hostname=worker-1 - - This initiates the install of software on worker-0 and worker-1. - -#. Wait for the software installation on controller-1, storage-0, storage-1, - worker-0, and worker-1 to complete, for all servers to reboot, and for all to - show as locked/disabled/online in 'system host-list'. - - :: - - system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | locked | disabled | online | - | 3 | storage-0 | storage | locked | disabled | online | - | 4 | storage-1 | storage | locked | disabled | online | - | 5 | worker-0 | worker | locked | disabled | online | - | 6 | worker-1 | worker | locked | disabled | online | - +----+--------------+-------------+----------------+-------------+--------------+ - ----------------------- -Configure controller-1 ----------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-config-controller-1-start: - :end-before: incl-config-controller-1-end: - -------------------- -Unlock controller-1 -------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-unlock-controller-1-start: - :end-before: incl-unlock-controller-1-end: - ------------------------ -Configure storage nodes ------------------------ - -#. Assign the cluster-host network to the MGMT interface for the storage nodes: - - (Note that the MGMT interfaces are partially set up automatically by the - network install procedure.) - - :: - - for NODE in storage-0 storage-1; do - system interface-network-assign $NODE mgmt0 cluster-host - done - -#. Add OSDs to storage-0. The following example adds OSDs to the `sdb` disk: - - :: - - HOST=storage-0 - DISKS=$(system host-disk-list ${HOST}) - TIERS=$(system storage-tier-list ceph_cluster) - OSDs="/dev/sdb" - for OSD in $OSDs; do - system host-stor-add ${HOST} $(echo "$DISKS" | grep "$OSD" | awk '{print $2}') --tier-uuid $(echo "$TIERS" | grep storage | awk '{print $2}') - while true; do system host-stor-list ${HOST} | grep ${OSD} | grep configuring; if [ $? -ne 0 ]; then break; fi; sleep 1; done - done - - system host-stor-list $HOST - -#. Add OSDs to storage-1. The following example adds OSDs to the `sdb` disk: - - :: - - HOST=storage-1 - DISKS=$(system host-disk-list ${HOST}) - TIERS=$(system storage-tier-list ceph_cluster) - OSDs="/dev/sdb" - for OSD in $OSDs; do - system host-stor-add ${HOST} $(echo "$DISKS" | grep "$OSD" | awk '{print $2}') --tier-uuid $(echo "$TIERS" | grep storage | awk '{print $2}') - while true; do system host-stor-list ${HOST} | grep ${OSD} | grep configuring; if [ $? -ne 0 ]; then break; fi; sleep 1; done - done - - system host-stor-list $HOST - --------------------- -Unlock storage nodes --------------------- - -Unlock storage nodes in order to bring them into service: - -:: - - for STORAGE in storage-0 storage-1; do - system host-unlock $STORAGE - done - -The storage nodes will reboot in order to apply configuration changes and come -into service. This can take 5-10 minutes, depending on the performance of the -host machine. - ----------------------- -Configure worker nodes ----------------------- - -#. Assign the cluster-host network to the MGMT interface for the worker nodes: - - (Note that the MGMT interfaces are partially set up automatically by the - network install procedure.) - - :: - - for NODE in worker-0 worker-1; do - system interface-network-assign $NODE mgmt0 cluster-host - done - -#. Configure data interfaces for worker nodes. Use the DATA port names, for - example eth0, that are applicable to your deployment environment. - - .. important:: - - This step is **required** for OpenStack. - - This step is optional for Kubernetes: Do this step if using SRIOV network - attachments in hosted application containers. - - For Kubernetes SRIOV network attachments: - - * Configure SRIOV device plug in: - - :: - - for NODE in worker-0 worker-1; do - system host-label-assign ${NODE} sriovdp=enabled - done - - * If planning on running DPDK in containers on this host, configure the - number of 1G Huge pages required on both NUMA nodes: - - :: - - for NODE in worker-0 worker-1; do - system host-memory-modify ${NODE} 0 -1G 100 - system host-memory-modify ${NODE} 1 -1G 100 - done - - For both Kubernetes and OpenStack: - - :: - - DATA0IF= - DATA1IF= - PHYSNET0='physnet0' - PHYSNET1='physnet1' - SPL=/tmp/tmp-system-port-list - SPIL=/tmp/tmp-system-host-if-list - - # configure the datanetworks in sysinv, prior to referencing it - # in the ``system host-if-modify`` command'. - system datanetwork-add ${PHYSNET0} vlan - system datanetwork-add ${PHYSNET1} vlan - - for NODE in worker-0 worker-1; do - echo "Configuring interface for: $NODE" - set -ex - system host-port-list ${NODE} --nowrap > ${SPL} - system host-if-list -a ${NODE} --nowrap > ${SPIL} - DATA0PCIADDR=$(cat $SPL | grep $DATA0IF |awk '{print $8}') - DATA1PCIADDR=$(cat $SPL | grep $DATA1IF |awk '{print $8}') - DATA0PORTUUID=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $2}') - DATA1PORTUUID=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $2}') - DATA0PORTNAME=$(cat $SPL | grep ${DATA0PCIADDR} | awk '{print $4}') - DATA1PORTNAME=$(cat $SPL | grep ${DATA1PCIADDR} | awk '{print $4}') - DATA0IFUUID=$(cat $SPIL | awk -v DATA0PORTNAME=$DATA0PORTNAME '($12 ~ DATA0PORTNAME) {print $2}') - DATA1IFUUID=$(cat $SPIL | awk -v DATA1PORTNAME=$DATA1PORTNAME '($12 ~ DATA1PORTNAME) {print $2}') - system host-if-modify -m 1500 -n data0 -c data ${NODE} ${DATA0IFUUID} - system host-if-modify -m 1500 -n data1 -c data ${NODE} ${DATA1IFUUID} - system interface-datanetwork-assign ${NODE} ${DATA0IFUUID} ${PHYSNET0} - system interface-datanetwork-assign ${NODE} ${DATA1IFUUID} ${PHYSNET1} - set +ex - done - -************************************* -OpenStack-specific host configuration -************************************* - -.. important:: - - **This step is required only if the StarlingX OpenStack application - (stx-openstack) will be installed.** - -#. **For OpenStack only:** Assign OpenStack host labels to the worker nodes in - support of installing the stx-openstack manifest and helm-charts later. - - :: - - for NODE in worker-0 worker-1; do - system host-label-assign $NODE openstack-compute-node=enabled - system host-label-assign $NODE openvswitch=enabled - system host-label-assign $NODE sriov=enabled - done - -#. **For OpenStack only:** Set up disk partition for nova-local volume group, - which is needed for stx-openstack nova ephemeral disks. - - :: - - for NODE in worker-0 worker-1; do - echo "Configuring Nova local for: $NODE" - ROOT_DISK=$(system host-show ${NODE} | grep rootfs | awk '{print $4}') - ROOT_DISK_UUID=$(system host-disk-list ${NODE} --nowrap | grep ${ROOT_DISK} | awk '{print $2}') - PARTITION_SIZE=10 - NOVA_PARTITION=$(system host-disk-partition-add -t lvm_phys_vol ${NODE} ${ROOT_DISK_UUID} ${PARTITION_SIZE}) - NOVA_PARTITION_UUID=$(echo ${NOVA_PARTITION} | grep -ow "| uuid | [a-z0-9\-]* |" | awk '{print $4}') - system host-lvg-add ${NODE} nova-local - system host-pv-add ${NODE} nova-local ${NOVA_PARTITION_UUID} - done - -------------------- -Unlock worker nodes -------------------- - -.. include:: controller_storage_install_kubernetes.rst - :start-after: incl-unlock-worker-baremetal-start: - :end-before: incl-unlock-worker-baremetal-end: - -.. note:: - - Check the status of the controller, worker and storage nodes. It should - now show "unlocked", "enabled" and "available". - -:: - - [sysadmin@controller-0 ~(keystone_admin)]$ system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | compute-0 | worker | unlocked | enabled | available | - | 3 | compute-1 | worker | unlocked | enabled | available | - | 4 | controller-1 | controller | unlocked | enabled | available | - | 5 | storage-0 | storage | unlocked | enabled | available | - | 6 | storage-1 | storage | unlocked | enabled | available | - +----+--------------+-------------+----------------+-------------+--------------+ - ----------- -Next steps ----------- - -.. include:: ../kubernetes_install_next.txt diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/ironic_hardware.rst b/doc/source/deploy_install_guides/r3_release/bare_metal/ironic_hardware.rst deleted file mode 100644 index 5021666cb..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/ironic_hardware.rst +++ /dev/null @@ -1,51 +0,0 @@ -===================== -Hardware Requirements -===================== - -This section describes the hardware requirements and server preparation for a -**StarlingX R3.0 bare metal Ironic** deployment configuration. - -.. contents:: - :local: - :depth: 1 - ------------------------------ -Minimum hardware requirements ------------------------------ - -* One or more bare metal hosts as Ironic nodes as well as tenant instance node. - -* BMC support on bare metal host and controller node connectivity to the BMC IP - address of bare metal hosts. - -For controller nodes: - -* Additional NIC port on both controller nodes for connecting to the - ironic-provisioning-net. - -For worker nodes: - -* If using a flat data network for the Ironic provisioning network, an additional - NIC port on one of the worker nodes is required. - -* Alternatively, use a VLAN data network for the Ironic provisioning network and - simply add the new data network to an existing interface on the worker node. - -* Additional switch ports / configuration for new ports on controller, worker, - and Ironic nodes, for connectivity to the Ironic provisioning network. - ------------------------------------ -BMC configuration of Ironic node(s) ------------------------------------ - -Enable BMC and allocate a static IP, username, and password in the BIOS settings. -For example, set: - -IP address - 10.10.10.126 - -username - root - -password - test123 diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/ironic_install.rst b/doc/source/deploy_install_guides/r3_release/bare_metal/ironic_install.rst deleted file mode 100644 index e9385f30f..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/ironic_install.rst +++ /dev/null @@ -1,392 +0,0 @@ -================================ -Install Ironic on StarlingX R3.0 -================================ - -This section describes the steps to install Ironic on a standard configuration, -either: - -* **StarlingX R3.0 bare metal Standard with Controller Storage** deployment - configuration - -* **StarlingX R3.0 bare metal Standard with Dedicated Storage** deployment - configuration - -.. contents:: - :local: - :depth: 1 - ---------------------- -Enable Ironic service ---------------------- - -This section describes the pre-configuration required to enable the Ironic service. -All the commands in this section are for the StarlingX platform. - -First acquire administrative privileges: - -:: - - source /etc/platform/openrc - -******************************** -Download Ironic deployment image -******************************** - -The Ironic service requires a deployment image (kernel and ramdisk) which is -used to clean Ironic nodes and install the end-user's image. The cleaning done -by the deployment image wipes the disks and tests connectivity to the Ironic -conductor on the controller nodes via the Ironic Python Agent (IPA). - -The Ironic deployment Stein image (**Ironic-kernel** and **Ironic-ramdisk**) -can be found here: - -* `Ironic-kernel coreos_production_pxe-stable-stein.vmlinuz - `__ -* `Ironic-ramdisk coreos_production_pxe_image-oem-stable-stein.cpio.gz - `__ - - -******************************************************* -Configure Ironic network on deployed standard StarlingX -******************************************************* - -#. Add an address pool for the Ironic network. This example uses `ironic-pool`: - - :: - - system addrpool-add --ranges 10.10.20.1-10.10.20.100 ironic-pool 10.10.20.0 24 - -#. Add the Ironic platform network. This example uses `ironic-net`: - - :: - - system addrpool-list | grep ironic-pool | awk '{print$2}' | xargs system network-add ironic-net ironic false - -#. Add the Ironic tenant network. This example uses `ironic-data`: - - .. note:: - - The tenant network is not the same as the platform network described in - the previous step. You can specify any name for the tenant network other - than ‘ironic’. If the name 'ironic' is used, a user override must be - generated to indicate the tenant network name. - - Refer to section `Generate user Helm overrides`_ for details. - - :: - - system datanetwork-add ironic-data flat - -#. Configure the new interfaces (for Ironic) on controller nodes and assign - them to the platform network. Host must be locked. This example uses the - platform network `ironic-net` that was named in a previous step. - - These new interfaces to the controllers are used to connect to the Ironic - provisioning network: - - **controller-0** - - :: - - system interface-network-assign controller-0 enp2s0 ironic-net - system host-if-modify -n ironic -c platform \ - --ipv4-mode static --ipv4-pool ironic-pool controller-0 enp2s0 - - # Apply the OpenStack Ironic node labels - system host-label-assign controller-0 openstack-ironic=enabled - - # Unlock the node to apply changes - system host-unlock controller-0 - - - **controller-1** - - :: - - system interface-network-assign controller-1 enp2s0 ironic-net - system host-if-modify -n ironic -c platform \ - --ipv4-mode static --ipv4-pool ironic-pool controller-1 enp2s0 - - # Apply the OpenStack Ironic node labels - system host-label-assign controller-1 openstack-ironic=enabled - - # Unlock the node to apply changes - system host-unlock controller-1 - -#. Configure the new interface (for Ironic) on one of the compute-labeled worker - nodes and assign it to the Ironic data network. This example uses the data - network `ironic-data` that was named in a previous step. - - :: - - system interface-datanetwork-assign worker-0 eno1 ironic-data - system host-if-modify -n ironicdata -c data worker-0 eno1 - -**************************** -Generate user Helm overrides -**************************** - -Ironic Helm Charts are included in the stx-openstack application. By default, -Ironic is disabled. - -To enable Ironic, update the following Ironic Helm Chart attributes: - -:: - - system helm-override-update stx-openstack ironic openstack \ - --set network.pxe.neutron_subnet_alloc_start=10.10.20.10 \ - --set network.pxe.neutron_subnet_gateway=10.10.20.1 \ - --set network.pxe.neutron_provider_network=ironic-data - -:command:`network.pxe.neutron_subnet_alloc_start` sets the DHCP start IP to -Neutron for Ironic node provision, and reserves several IPs for the platform. - -If the data network name for Ironic is changed, modify -:command:`network.pxe.neutron_provider_network` to the command above: - -:: - - --set network.pxe.neutron_provider_network=ironic-data - -******************************* -Apply stx-openstack application -******************************* - -Re-apply the stx-openstack application to apply the changes to Ironic: - -:: - - system helm-chart-attribute-modify stx-openstack ironic openstack \ - --enabled true - - system application-apply stx-openstack - --------------------- -Start an Ironic node --------------------- - -All the commands in this section are for the OpenStack application with -administrative privileges. - -From a new shell as a root user, without sourcing ``/etc/platform/openrc``: - -:: - - mkdir -p /etc/openstack - - tee /etc/openstack/clouds.yaml << EOF - clouds: - openstack_helm: - region_name: RegionOne - identity_api_version: 3 - endpoint_type: internalURL - auth: - username: 'admin' - password: 'Li69nux*' - project_name: 'admin' - project_domain_name: 'default' - user_domain_name: 'default' - auth_url: 'http://keystone.openstack.svc.cluster.local/v3' - EOF - - export OS_CLOUD=openstack_helm - -******************** -Create Glance images -******************** - -#. Create the **ironic-kernel** image: - - :: - - openstack image create \ - --file ~/coreos_production_pxe-stable-stein.vmlinuz \ - --disk-format aki \ - --container-format aki \ - --public \ - ironic-kernel - -#. Create the **ironic-ramdisk** image: - - :: - - openstack image create \ - --file ~/coreos_production_pxe_image-oem-stable-stein.cpio.gz \ - --disk-format ari \ - --container-format ari \ - --public \ - ironic-ramdisk - -#. Create the end user application image (for example, CentOS): - - :: - - openstack image create \ - --file ~/CentOS-7-x86_64-GenericCloud-root.qcow2 \ - --public --disk-format \ - qcow2 --container-format bare centos - -********************* -Create an Ironic node -********************* - -#. Create a node: - - :: - - openstack baremetal node create --driver ipmi --name ironic-test0 - -#. Add IPMI information: - - :: - - openstack baremetal node set \ - --driver-info ipmi_address=10.10.10.126 \ - --driver-info ipmi_username=root \ - --driver-info ipmi_password=test123 \ - --driver-info ipmi_terminal_port=623 ironic-test0 - -#. Set `ironic-kernel` and `ironic-ramdisk` images driver information, - on this bare metal node: - - :: - - openstack baremetal node set \ - --driver-info deploy_kernel=$(openstack image list | grep ironic-kernel | awk '{print$2}') \ - --driver-info deploy_ramdisk=$(openstack image list | grep ironic-ramdisk | awk '{print$2}') \ - ironic-test0 - -#. Set resource properties on this bare metal node based on actual Ironic node - capacities: - - :: - - openstack baremetal node set \ - --property cpus=4 \ - --property cpu_arch=x86_64\ - --property capabilities="boot_option:local" \ - --property memory_mb=65536 \ - --property local_gb=400 \ - --resource-class bm ironic-test0 - -#. Add pxe_template location: - - :: - - openstack baremetal node set --driver-info \ - pxe_template='/var/lib/openstack/lib64/python2.7/site-packages/ironic/drivers/modules/ipxe_config.template' \ - ironic-test0 - -#. Create a port to identify the specific port used by the Ironic node. - Substitute **a4:bf:01:2b:3b:c8** with the MAC address for the Ironic node - port which connects to the Ironic network: - - :: - - openstack baremetal port create \ - --node $(openstack baremetal node list | grep ironic-test0 | awk '{print$2}') \ - --pxe-enabled true a4:bf:01:2b:3b:c8 - -#. Change node state to `manage`: - - :: - - openstack baremetal node manage ironic-test0 - -#. Make node available for deployment: - - :: - - openstack baremetal node provide ironic-test0 - -#. Wait for ironic-test0 provision-state: available: - - :: - - openstack baremetal node show ironic-test0 - ---------------------------------- -Deploy an instance on Ironic node ---------------------------------- - -All the commands in this section are for the OpenStack application, but this -time with *tenant* specific privileges. - -#. From a new shell as a root user, without sourcing ``/etc/platform/openrc``: - - :: - - mkdir -p /etc/openstack - - tee /etc/openstack/clouds.yaml << EOF - clouds: - openstack_helm: - region_name: RegionOne - identity_api_version: 3 - endpoint_type: internalURL - auth: - username: 'joeuser' - password: 'mypasswrd' - project_name: 'intel' - project_domain_name: 'default' - user_domain_name: 'default' - auth_url: 'http://keystone.openstack.svc.cluster.local/v3' - EOF - - export OS_CLOUD=openstack_helm - -#. Create flavor. - - Set resource CUSTOM_BM corresponding to **--resource-class bm**: - - :: - - openstack flavor create --ram 4096 --vcpus 4 --disk 400 \ - --property resources:CUSTOM_BM=1 \ - --property resources:VCPU=0 \ - --property resources:MEMORY_MB=0 \ - --property resources:DISK_GB=0 \ - --property capabilities:boot_option='local' \ - bm-flavor - - See `Adding scheduling information - `__ - and `Configure Nova flavors - `__ - for more information. - -#. Enable service - - List the compute services: - - :: - - openstack compute service list - - Set compute service properties: - - :: - - openstack compute service set --enable controller-0 nova-compute - -#. Create instance - - .. note:: - - The :command:`keypair create` command is optional. It is not required to - enable a bare metal instance. - - :: - - openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey - - - Create 2 new servers, one bare metal and one virtual: - - :: - - openstack server create --image centos --flavor bm-flavor \ - --network baremetal --key-name mykey bm - - openstack server create --image centos --flavor m1.small \ - --network baremetal --key-name mykey vm diff --git a/doc/source/deploy_install_guides/r3_release/bare_metal/prep_servers.txt b/doc/source/deploy_install_guides/r3_release/bare_metal/prep_servers.txt deleted file mode 100644 index 61a686201..000000000 --- a/doc/source/deploy_install_guides/r3_release/bare_metal/prep_servers.txt +++ /dev/null @@ -1,17 +0,0 @@ -Prior to starting the StarlingX installation, the bare metal servers must be in -the following condition: - -* Physically installed - -* Cabled for power - -* Cabled for networking - - * Far-end switch ports should be properly configured to realize the networking - shown in Figure 1. - -* All disks wiped - - * Ensures that servers will boot from either the network or USB storage (if present) - -* Powered off \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r3_release/desc_dedicated_storage.txt b/doc/source/deploy_install_guides/r3_release/desc_dedicated_storage.txt deleted file mode 100644 index 371940210..000000000 --- a/doc/source/deploy_install_guides/r3_release/desc_dedicated_storage.txt +++ /dev/null @@ -1,23 +0,0 @@ -The Standard with Dedicated Storage deployment option is a standard installation -with independent controller, worker, and storage nodes. - -A Standard with Dedicated Storage configuration provides the following benefits: - -* A pool of up to 100 worker nodes -* A 2x node high availability (HA) controller cluster with HA services running - across the controller nodes in either active/active or active/standby mode -* A storage back end solution using a two-to-9x node HA CEPH storage cluster - that supports a replication factor of two or three -* Up to four groups of 2x storage nodes, or up to three groups of 3x storage nodes - -.. note:: - - If you are behind a corporate firewall or proxy, you need to set proxy - settings. Refer to :doc:`/../../configuration/docker_proxy_config` for - details. - -.. figure:: ../figures/starlingx-deployment-options-dedicated-storage.png - :scale: 50% - :alt: Standard with Dedicated Storage deployment configuration - - *Figure 1: Standard with Dedicated Storage deployment configuration* \ No newline at end of file diff --git a/doc/source/deploy_install_guides/r3_release/distributed_cloud/index.rst b/doc/source/deploy_install_guides/r3_release/distributed_cloud/index.rst deleted file mode 100644 index 1b7e1b0fc..000000000 --- a/doc/source/deploy_install_guides/r3_release/distributed_cloud/index.rst +++ /dev/null @@ -1,310 +0,0 @@ -=================================== -Distributed Cloud Installation R3.0 -=================================== - -This section describes how to install and configure the StarlingX distributed -cloud deployment. - -.. contents:: - :local: - :depth: 1 - --------- -Overview --------- - -Distributed cloud configuration supports an edge computing solution by -providing central management and orchestration for a geographically -distributed network of StarlingX Kubernetes edge systems/clusters. - -The StarlingX distributed cloud implements the OpenStack Edge Computing -Groups's MVP `Edge Reference Architecture -`_, -specifically the "Distributed Control Plane" scenario. - -The StarlingX distributed cloud deployment is designed to meet the needs of -edge-based data centers with centralized orchestration and independent control -planes, and in which Network Function Cloudification (NFC) worker resources -are localized for maximum responsiveness. The architecture features: - -- Centralized orchestration of edge cloud control planes. -- Full synchronized control planes at edge clouds (that is, Kubernetes cluster - master and nodes), with greater benefits for local services, such as: - - - Reduced network latency. - - Operational availability, even if northbound connectivity - to the central cloud is lost. - -The system supports a scalable number of StarlingX Kubernetes edge -systems/clusters, which are centrally managed and synchronized over L3 -networks from a central cloud. Each edge system is also highly scalable, from -a single node StarlingX Kubernetes deployment to a full standard cloud -configuration with controller, worker and storage nodes. - ------------------------------- -Distributed cloud architecture ------------------------------- - -A distributed cloud system consists of a central cloud, and one or more -subclouds connected to the System Controller region central cloud over L3 -networks, as shown in Figure 1. - -- **Central cloud** - - The central cloud provides a *RegionOne* region for managing the physical - platform of the central cloud and the *SystemController* region for managing - and orchestrating over the subclouds. - - - **RegionOne** - - In the Horizon GUI, RegionOne is the name of the access mode, or region, - used to manage the nodes in the central cloud. - - - **SystemController** - - In the Horizon GUI, SystemController is the name of the access mode, or - region, used to manage the subclouds. - - You can use the System Controller to add subclouds, synchronize select - configuration data across all subclouds and monitor subcloud operations - and alarms. System software updates for the subclouds are also centrally - managed and applied from the System Controller. - - DNS, NTP, and other select configuration settings are centrally managed - at the System Controller and pushed to the subclouds in parallel to - maintain synchronization across the distributed cloud. - -- **Subclouds** - - The subclouds are StarlingX Kubernetes edge systems/clusters used to host - containerized applications. Any type of StarlingX Kubernetes configuration, - (including simplex, duplex, or standard with or without storage nodes), can - be used for a subcloud. The two edge clouds shown in Figure 1 are subclouds. - - Alarms raised at the subclouds are sent to the System Controller for - central reporting. - -.. figure:: ../figures/starlingx-deployment-options-distributed-cloud.png - :scale: 45% - :alt: Distributed cloud deployment configuration - - *Figure 1: Distributed cloud deployment configuration* - - --------------------- -Network requirements --------------------- - -Subclouds are connected to the System Controller through both the OAM and the -Management interfaces. Because each subcloud is on a separate L3 subnet, the -OAM, Management and PXE boot L2 networks are local to the subclouds. They are -not connected via L2 to the central cloud, they are only connected via L3 -routing. The settings required to connect a subcloud to the System Controller -are specified when a subcloud is defined. A gateway router is required to -complete the L3 connections, which will provide IP routing between the -subcloud Management and OAM IP subnet and the System Controller Management and -OAM IP subnet, respectively. The System Controller bootstraps the subclouds via -the OAM network, and manages them via the management network. For more -information, see the `Install a Subcloud`_ section later in this guide. - -.. note:: - - All messaging between System Controllers and Subclouds uses the ``admin`` - REST API service endpoints which, in this distributed cloud environment, - are all configured for secure HTTPS. Certificates for these HTTPS - connections are managed internally by StarlingX. - ---------------------------------------- -Install and provision the central cloud ---------------------------------------- - -Installing the central cloud is similar to installing a standard -StarlingX Kubernetes system. The central cloud supports either an AIO-duplex -deployment configuration or a standard with dedicated storage nodes deployment -configuration. - -To configure controller-0 as a distributed cloud central controller, you must -set certain system parameters during the initial bootstrapping of -controller-0. Set the system parameter *distributed_cloud_role* to -*systemcontroller* in the Ansible bootstrap override file. Also, set the -management network IP address range to exclude IP addresses reserved for -gateway routers providing routing to the subclouds' management subnets. - -Procedure: - -- Follow the StarlingX R3.0 installation procedures with the extra step noted below: - - - AIO-duplex: - `Bare metal All-in-one Duplex Installation R3.0 `_ - - - Standard with dedicated storage nodes: - `Bare metal Standard with Dedicated Storage Installation R3.0 `_ - -- For the step "Bootstrap system on controller-0", add the following - parameters to the Ansible bootstrap override file. - - .. code:: yaml - - distributed_cloud_role: systemcontroller - management_start_address: - management_end_address: - ------------------- -Install a subcloud ------------------- - -At the subcloud location: - -1. Physically install and cable all subcloud servers. -2. Physically install the top of rack switch and configure it for the - required networks. -3. Physically install the gateway routers which will provide IP routing - between the subcloud OAM and Management subnets and the System Controller - OAM and management subnets. -4. On the server designated for controller-0, install the StarlingX - Kubernetes software from USB or a PXE Boot server. - -5. Establish an L3 connection to the System Controller by enabling the OAM - interface (with OAM IP/subnet) on the subcloud controller using the - ``config_management`` script. This step is for subcloud ansible bootstrap - preparation. - - .. note:: This step should **not** use an interface that uses the MGMT - IP/subnet because the MGMT IP subnet will get moved to the loopback - address by the Ansible bootstrap playbook during installation. - - Be prepared to provide the following information: - - - Subcloud OAM interface name (for example, enp0s3). - - Subcloud OAM interface address, in CIDR format (for example, 10.10.10.12/24). - - .. note:: This must match the *external_oam_floating_address* supplied in - the subcloud's ansible bootstrap override file. - - - Subcloud gateway address on the OAM network - (for example, 10.10.10.1). A default value is shown. - - System Controller OAM subnet (for example, 10,10.10.0/24). - - .. note:: To exit without completing the script, use ``CTRL+C``. Allow a few minutes for - the script to finish. - - .. note:: The `config_management` in the code snippet configures the OAM - interface/address/gateway. - - .. code:: sh - - $ sudo config_management - Enabling interfaces... DONE - Waiting 120 seconds for LLDP neighbor discovery... Retrieving neighbor details... DONE - Available interfaces: - local interface remote port - --------------- ---------- - enp0s3 08:00:27:c4:6c:7a - enp0s8 08:00:27:86:7a:13 - enp0s9 unknown - - Enter management interface name: enp0s3 - Enter management address CIDR: 10.10.10.12/24 - Enter management gateway address [10.10.10.1]: - Enter System Controller subnet: 10.10.10.0/24 - Disabling non-management interfaces... DONE - Configuring management interface... DONE - RTNETLINK answers: File exists - Adding route to System Controller... DONE - -At the System Controller: - -1. Create a ``bootstrap-values.yml`` override file for the subcloud. For - example: - - .. code:: yaml - - system_mode: duplex - name: "subcloud1" - description: "Ottawa Site" - location: "YOW" - - management_subnet: 192.168.101.0/24 - management_start_address: 192.168.101.2 - management_end_address: 192.168.101.50 - management_gateway_address: 192.168.101.1 - - external_oam_subnet: 10.10.10.0/24 - external_oam_gateway_address: 10.10.10.1 - external_oam_floating_address: 10.10.10.12 - - systemcontroller_gateway_address: 192.168.204.101 - - .. important:: The `management_*` entries in the override file are required - for all installation types, including AIO-Simplex. - - .. important:: The `management_subnet` must not overlap with any other subclouds. - - .. note:: The `systemcontroller_gateway_address` is the address of central - cloud management network gateway. - -2. Add the subcloud using the CLI command below: - - .. code:: sh - - dcmanager subcloud add --bootstrap-address - --bootstrap-values - - Where: - - - ** is the OAM interface address set earlier on the subcloud. - - ** is the Ansible override configuration file, ``bootstrap-values.yml``, - created earlier in step 1. - - You will be prompted for the Linux password of the subcloud. This command - will take 5- 10 minutes to complete. You can monitor the progress of the - subcloud bootstrap through logs: - - .. code:: sh - - tail –f /var/log/dcmanager/_bootstrap_