Ensure that the following BIOS and IPMI settings are applied to each bare-metal server:

☐	Item
	Choose either UEFI or Legacy BIOS in the BIOS settings
	Verify the Date and Time settings in the BIOS. Note SUSE OpenStack Cloud installs and runs with UTC, not local time.
	Ensure that Wake-on-LAN is disabled in the BIOS
	Ensure that the NIC port to be used for PXE installation has PXE enabled in the BIOS
	Ensure that all other NIC ports have PXE disabled in the BIOS
	Ensure all hardware in the server not directly used by SUSE OpenStack Cloud is disabled

Before installing SUSE OpenStack Cloud, the following networks must be provisioned and tested. The networks are not installed or managed by the Cloud. You must install and manage the networks as documented in Book “Planning an Installation with Cloud Lifecycle Manager”, Chapter 9 “Example Configurations”.

Note that if you want a pluggable IPAM driver, it must be specified at install time. Only with a clean install of SUSE OpenStack Cloud 8 can you specify a different IPAM driver. If upgrading, you must use the default driver. More information can be found in Book “Operations Guide”, Chapter 9 “Managing Networking”, Section 9.3 “Networking Service Overview”, Section 9.3.7 “Using IPAM Drivers in the Networking Service”.

Use these checklists to confirm and record your network configuration information.

Router

The IP router used with SUSE OpenStack Cloud must support the updated of its ARP table through gratuitous ARP packets.

PXE Installation Network

When provisioning the IP range, allocate sufficient IP addresses to cover both the current number of servers and any planned expansion. Use the following table to help calculate the requirements:

Management Network

The management network is the backbone used for the majority of SUSE OpenStack Cloud management communications. Control messages are exchanged between the Controllers, Compute hosts, and Cinder backends through this network. In addition to the control flows, the management network is also used to transport Swift and iSCSI based Cinder block storage traffic between servers.

When provisioning the IP Range, allocate sufficient IP addresses to cover both the current number of servers and any planned expansion. Use the following table to help calculate the requirements:

IPMI Network

The IPMI network is used to connect the IPMI interfaces on the servers that are assigned for use with implementing the cloud. This network is used by Cobbler to control the state of the servers during baremetal deployments.

External API Network

The External network is used to connect OpenStack endpoints to an external public network such as a company’s intranet or the public internet in the case of a public cloud provider.

When provisioning the IP Range, allocate sufficient IP addresses to cover both the current number of servers and any planned expansion. Use the following table to help calculate the requirements.

External VM Network

The External VM network is used to connect cloud instances to an external public network such as a company’s intranet or the public internet in the case of a public cloud provider. The external network has a predefined range of Floating IPs which are assigned to individual instances to enable communications to and from the instance to the assigned corporate intranet/internet. There should be a route between the External VM and External API networks so that instances provisioned in the cloud, may access the Cloud API endpoints, using the instance floating IPs.

This server contains the SUSE OpenStack Cloud installer, which is based on Git, Ansible, and Cobbler.

Log on to each type of physical server you have and issue platform-appropriate commands to identify the bus-address and port-num values that may be required. For example, run the following command:

sudo lspci -D | grep -i net

and enter this information in the space below. Use this information for the bus-address value in your nic_mappings.yml file.

To find the port-num use:

cat /sys/class/net/<device name>/dev_port

where the 'device-name' is the name of the device currently mapped to this address, not necessarily the name of the device to be mapped. Enter the information for your system in the space below.

The Control Plane consists of at least three servers in a highly available cluster that host the core SUSE OpenStack Cloud services including Nova, Keystone, Glance, Cinder, Heat, Neutron, Swift, Ceilometer, and Horizon. Additional services include mariadb, ip-cluster, apache2, rabbitmq, memcached, zookeeper, kafka, storm, monasca, logging, and cmc.

Note

To mitigate the “split-brain” situation described in Book “Operations Guide”, Chapter 15 “Troubleshooting Issues”, Section 15.4 “Network Service Troubleshooting” it is recommended that you have HA network configuration with Multi-Chassis Link Aggregation (MLAG) and NIC bonding configured for all the controllers to deliver system-level redundancy as well network-level resiliency. Also reducing the ARP timeout on the TOR switches will help.

One or more KVM Compute servers will be used as the compute host targets for instances.

Table to record your Compute host details:

Three or more servers with local disk volumes to provide Cinder block storage resources.

Note

The cluster created from block storage nodes must allow for quorum. In other words, the node count of the cluster must be 3, 5, 7, or another odd number.

Table to record your block storage host details:

This section is for any additional information that you deem necessary.

Registering SUSE Linux Enterprise Server 12 SP3 during the installation process is required for getting product updates and for installing the SUSE OpenStack Cloud extension. Refer to https://documentation.suse.com/sles/12-SP5/single-html/SLES-deployment/#sec-i-yast2-conf-manual-cc for further instructions.

After a successful registration you will be asked whether to add the update repositories. If you agree, the latest updates will automatically be installed, ensuring that your system is on the latest patch level after the initial installation. We strongly recommend adding the update repositories immediately. If you choose to skip this step you need to perform an online update later, before starting the installation.

Note: SUSE Login Required

To register a product, you need to have a SUSE login. If you do not have such a login, create it at http://www.suse.com/.

Important

Installing SUSE Linux Enterprise Server for SUSE OpenStack Cloud requires the following steps, which are different from the default SUSE Linux Enterprise Server installation process.

Note

For an overview of a default SUSE Linux Enterprise Server installation, refer to https://documentation.suse.com/sles/12-SP5/single-html/SLES-installquick/#art-sle-installquick.

Start the installation by booting into the SUSE Linux Enterprise Server 12 SP3 installation system.

Create a custom partition setup using the Expert Partitioner. The following setup is required:

Setting up Cloud Lifecycle Manager requires a regular user which you can set up during the installation. You are free to choose any available user name except for ardana, because the ardana user is reserved by SUSE OpenStack Cloud.

With Installation Settings, you need to adjust the software selection for your Cloud Lifecycle Manager setup. For more information refer to the https://documentation.suse.com/sles/12-SP5/single-html/SLES-deployment/#sec-i-yast2-proposal.

Important: Additional Installation Settings

The default firewall must be disabled, as SUSE OpenStack Cloud enables its own firewall during deployment.

SSH must be enabled.

Set text as the Default systemd target.

3.5.1 Software Selection #

  

Installing a minimal base system is sufficient to set up the Administration Server. The following patterns are the minimum required:

• Base System

• Minimal System (Appliances)

• Meta Package for Pattern cloud-ardana (in case you have chosen to install the SUSE OpenStack Cloud Extension)

• Subscription Management Tool (optional, also see Tip: Installing a Local SMT Server (Optional))

• YaST2 configuration packages

Tip: Installing a Local SMT Server (Optional)

If you do not have a SUSE Manager or SMT server in your organization, or are planning to manually update the repositories required for deployment of the SUSE OpenStack Cloud nodes, you need to set up an SMT server on the Administration Server. Choose the pattern Subscription Management Tool in addition to the patterns listed above to install the SMT server software.

If you have not installed the SMT server during the initial Cloud Lifecycle Manager server installation as suggested in Section 3.5.1, “Software Selection”, run the following command to install it:

sudo zypper in -t pattern smt

No matter whether the SMT server was installed during the initial installation or in the running system, it needs to be configured with the following steps.

Note: Prerequisites

To configure the SMT server, a SUSE account is required. If you do not have such an account, register at http://www.suse.com/. All products and extensions for which you want to mirror updates with the SMT server should be registered at the SUSE Customer Center (http://scc.suse.com/).

If you did not register with the SUSE Customer Center during installation, then at this point you will need to register in order to proceed. Ensure that the Cloud Lifecycle Manager has external network access and then run the following command:

tux > sudo SUSEConnect -r
     SLES_REGISTRATION_CODE

The final step in setting up the SMT server is configuring it to mirror the repositories needed for SUSE OpenStack Cloud. The SMT server mirrors the repositories from the SUSE Customer Center. Make sure to have the appropriate subscriptions registered in SUSE Customer Center with the same e-mail address you specified when configuring SMT.

for REPO in SLES12-SP3-{Pool,Updates} SUSE-OpenStack-Cloud-8-{Pool,Updates}; do
  smt-repos $REPO sle-12-x86_64 -e
done

smt-mirror -L /var/log/smt/smt-mirror.log

For detailed information about SMT refer to the Subscription Management Tool manual at https://documentation.suse.com/sles/12-SP5/single-html/SLES-smt/.

The files in the product repositories for SUSE OpenStack Cloud do not change, therefore they do not need to be synchronized with a remote source. If you have installed the product media from a downloaded ISO image, the product repositories will automatically be made available to the client nodes and these steps can be skipped. These steps can also be skipped if you prefer to install from the Pool repositories provided by SUSE Customer Center. Otherwise, it is sufficient to either copy the data (from a remote host or the installation media), to mount the product repository from a remote server via NFS, or to loop mount a copy of the installation images.

If you choose to install from the product media rather than from the SUSE Customer Center repositories, the following product media needs to reside in the specified directories:

The data can be copied by a variety of methods:

Update and Pool Repositories are required on the Cloud Lifecycle Manager server to set up and maintain the SUSE OpenStack Cloud nodes. They are provided by SUSE Customer Center and contain all software packages needed to install SUSE Linux Enterprise Server 12 SP3 and the extensions (pool repositories). In addition, they contain all updates and patches (update repositories).

The repositories can be made available on the Cloud Lifecycle Manager server using one or more of the following methods:

The following tables show the locations of all repositories that can be used for SUSE OpenStack Cloud.

The following table shows the required repository locations to use when manually copying, synchronizing, or mounting the repositories.

For information about supported hardware for multipathing, see Book “Planning an Installation with Cloud Lifecycle Manager”, Chapter 2 “Hardware and Software Support Matrix”, Section 2.2 “Supported Hardware Configurations”.

Important

When exporting a LUN to a node for boot from SAN, you should ensure that LUN 0 is assigned to the LUN and configure any setup dialog that is necessary in the firmware to consume this LUN 0 for OS boot.

Important

Any hosts that are connected to 3PAR storage must have a host persona of 2-generic-alua set on the 3PAR. Refer to the 3PAR documentation for the steps necessary to check this and change if necessary.

iSCSI boot from SAN is not supported. For more information on the use of Cinder with multipath, see Section 22.1.3, “Multipath Support”.

To allow SUSE OpenStack Cloud 8 to use volumes from a SAN, you have to specify configuration options for both the installation and the OS configuration phase. In all cases, the devices that are utilized are devices for which multipath is configured.

For FC connected nodes and for FCoE nodes where the network processor used is from the Emulex family such as for the 650FLB, the following changes need to be made.

Instead of using Cobbler, you need to provision a baremetal node manually using the following procedure.

If you are using network cards such as Qlogic Flex Fabric 536 and 630 series, there are additional OS configuration steps to support the importation of LUNs as well as some restrictions on supported configurations.

The restrictions are:

In addition to the configuration options above, you also need to specify the FCoE interfaces for install and for os configuration. There are 3 places where you need to add additional configuration options for fcoe-support:

Since NIC mapping is not used to guarantee order of the networks across the system the installer will remap the network interfaces in a deterministic fashion as part of the install. As part of the installer dialogue, if DHCP is not configured for the interface, it is necessary to confirm that the appropriate interface is assigned the ip address. The network interfaces may not be at the names expected when installing via an ISO. When you are asked to apply an IP address to an interface, press Alt–F2 and in the console window, run the command ip a to examine the interfaces and their associated MAC addresses. Make a note of the interface name with the expected MAC address and use this in the subsequent dialog. Press Alt–F1 to return to the installation screen. You should note that the names of the interfaces may have changed after the installation completes. These names are used consistently in any subsequent operations.

Therefore, even if FCoE is not used for boot from SAN (for example for cinder), then it is recommended that fcoe-interfaces be specified as part of install (without the multipath or disk detect options). Alternatively, you need to run osconfig-fcoe-reorder.yml before site.yml or osconfig-run.yml is invoked to reorder the networks in a similar manner to the installer. In this case, the nodes will need to be manually rebooted for the network reorder to take effect. Run osconfig-fcoe-reorder.yml in the following scenarios:

To run the command:

cd ~/scratch/ansible/next/ardana/ansible
ansible-playbook -i hosts/verb_hosts osconfig-fcoe-reorder.yml

If you do not run osconfig-fcoe-reorder.yml, you will encounter a failure in osconfig-run.yml.

If you are booting from a local disk, the LUNs that will be imported over FCoE will not be visible before site.yml or osconfig-run.yml has been run. However, if you need to import the LUNs before this, for instance, in scenarios where you need to run wipe_disks.yml (run this only after first running bm-reimage.yml), then you can run the fcoe-enable playbook across the nodes in question. This will configure FCoE and import the LUNs presented to the nodes.

cd ~/openstack/ardana/ansible
ansible-playbook -i hosts/verb_hosts fcoe-enable.yml

The Cloud Lifecycle Manager can be installed on a Control Plane or on a stand-alone server.

Each method is suited for particular needs. The best choice depends on your situation.

Stand-alone Deployer

Control Plane Deployer

Summary

If you do not intend to install a stand-alone deployer, proceed to installing the Cloud Lifecycle Manager on a Control Plane.

Before you launch the Install UI to install your cloud, do the following:

In SUSE OpenStack Cloud 8, a local git repository is used to track configuration changes; the Configuration Processor (CP) uses this repository. Use of a git workflow means that your configuration history is maintained, making rollbacks easier and keeping a record of previous configuration settings. The git repository also provides a way for you to merge changes that you pull down as “upstream” updates (that is, updates from SUSE). It also allows you to manage your own configuration changes.

The git repository is installed by the Cloud Lifecycle Manager on the Cloud Lifecycle Manager node.

Using the Install UI does not require the use of the git repository. After the installation, it may be useful to know more about Chapter 10, Using Git for Configuration Management.

Before beginning the installation, you can create a CSV file with your server information to import directly into the Install UI to avoid entering it manually on the Assign Servers page.

The following table shows the fields needed for your CSV file.

The aliases are all the valid names that can be used in the CSV file for the column header for a given field. Field names are not case sensitive. You can use either (space) or - (hyphen) in place of underscore for a field name.

An example CSV file could be:

id,ip-addr,mac-address,server-group,nic-mapping,server-role,ipmi-ip,ipmi-user
controller1,192.168.110.3,b2:72:8d:ac:7c:6f,RACK1,HP-DL360-4PORT,CONTROLLER-ROLE,192.168.109.3,admin
myserver4,10.2.10.24,00:14:22:01:23:44,AZ1,,,,

If you intend to use SUSE Manager or HPE OneView to add servers, certificates for those services must be accessible to the Install UI.

Use the following steps to import a SUSE Manager certificate.

Use the following steps to import an HPE OneView certificate.

Important

The Install UI must run continuously without stopping for authentication at any step. When using the Install UI it is required to launch the Cloud Lifecycle Manager with the following command:

ARDANA_INIT_AUTO=1 /usr/bin/ardana-init

Deploying the cloud to your servers will reconfigure networking and firewall rules on your cloud servers. To avoid problems with these networking changes when using the Install UI, we recommend you run a browser directly on your Cloud Lifecycle Manager node and point it to http://localhost:3000.

If you cannot run a browser on the Cloud Lifecycle Manager node to perform the install, you can run a browser from a Linux-based computer in your MANAGEMENT network. However, firewall rules applied during cloud deployment will block access to the Install UI. To avoid blocking the connection, you can use the Install UI via an SSH tunnel to the Cloud Lifecycle Manager server. This will allow SSH connections through the MANAGEMENT network when you reach the "Review Configuration Files" step of the install process.

To open an SSH tunnel from your Linux-based computer in your MANAGEMENT network to the Cloud Lifecycle Manager:

Important

If you use an SSH tunnel to connect to the Install UI, there is an important note in the "Review Configuration Files" step about modifying firewall_rules.yml to allow SSH connections on the MANAGEMENT network.

The first page of the Install UI shows the general installation process and a reminder to gather some information before beginning. Clicking the Next button brings up the Model Selection page.

The input model choices are displayed on this page. Details of each model can be seen on the right by clicking the model name on the left. If you have already decided some aspects of your cloud environment, models can be filtered using the dropdown selections. Narrowing a parameter affects the range of choices of models and changes other dropdown choices to only those that are compatible.

Selecting a model will determine the base template from which the cloud will be deployed. Models can be adjusted later in the process, though selecting the closest match to your requirements reduces the effort required to deploy your cloud.

Warning

If you select any ESX model, extra manual steps are required to avoid configuration failures. While installing an ESX model with the Install UI, you will be asked for interfaces related to ESX and OVSvApp. Those interfaces must be defined before being entered in the Install UI. Instructions are available at Section 15.3, “Overview of ESXi and OVSvApp”.

Note

Installing a Stand-alone Deployer

If you are using the Install UI to install a stand-alone deployer, select that model, which was created previously in Chapter 8, Preparing for Stand-Alone Deployment.

Continue with the remaining Install UI steps to finish installing the stand-alone deployer.

Based on the cloud example selected on the previous page, more detail is shown about that cloud configuration and the components that will be deployed. If you go back and select a different model, the deployment process restarts from the beginning. Any configuration changes you have made will be deleted.

The number of nodes (servers) dedicated to each server role can be adjusted. Most input models are designed to support High Availability and to distribute OpenStack services appropriately.

This page provides more detail about the number and assignment of each type of node based on the information from the previous page (any changes must be made there).

Components that do not meet the required parameters will be shown in red in the accordion bar. Missing required fields and duplicate server names will also be red, as will the accordion bar. The Next button will be disabled.

Servers may be discovered using SUSE Manager, HPE OneView, or both. Ensure that the certificates are accessible, as described in Section 9.4, “Optional: Importing Certificates for SUSE Manager and HPE OneView”. Clicking the Discover button will prompt for access credentials to the system management software to be used for discovery. Certificates can be verified by checking Verify SSL certificate. After validating credentials, Discovery will retrieve a list of known servers from SUSE Manager and/or HPE OneView and allow access to server details on those management platforms.

You can drag and drop to move servers from the left to the right in order to assign server roles, from right to left, or up and down in the accordion bar.

Server information may also be entered manually or imported via CSV in the Manual Entry tab. The format for CSV entry is described in Section 9.3, “Optional: Creating a CSV File to Import Server Data”. The server assignment list includes placeholder server details that can be edited to reflect real hardware, or can be removed and replaced with discovered or manually added systems.

For more information about server roles, see Book “Planning an Installation with Cloud Lifecycle Manager”, Chapter 5 “Input Model”, Section 5.2 “Concepts”, Section 5.2.4 “Server Roles”.

Subnet and netmask values should be set on this page as they may impact the IP addresses being assigned to various servers.

If an OS has not previously been installed on the servers that make up the cloud configuration, the OS installation page allows for Cobbler to deploy SLES on servers in the cloud configuration. Enter password, select servers and click Install to deploy SLES to these servers. An installation log and progress indicators will be displayed.

When the OS installation is complete, a Server and Server Role Summary page is displayed. It shows which servers have been assigned to each role, and provides an opportunity to edit the server configurations. Various cloud components can be configured by clicking on the Manage Cloud Settings button. Incorrect information will be shown in red.

Below is the list of what can be changed within the Install UI, followed by a list of customizations that can only be changed by directly editing the files on the Review Configuration Files page. Anything changed directly in the files themselves during the Install UI process will be overwritten by values you have entered with the Install UI.

Changes to the following items can be made:

Changes to the following items can only be made by manually editing the associated .yml files on the Review Configuration page of the Install UI:

Important

Directly changing files may cause the configuration to fail validation. During the process of installing with the Install UI, any changes should be made with the tools provided within the Install UI.

Advanced editing of the cloud configuration can be done on the Review Configuration Files page. Individual .yml and .j2 files can be edited directly with the embedded editor in the Model and Templates and Services tabs. The Deployment tab contains the items Wipe Data Disks, Encryption Key and Verbosity Level.

Important

If you are using an SSH tunnel to connect to the Install UI, you will need to make an extra modification here to allow SSH connections through the firewall:

1. While on the Review Configuration Files page, click on the Model tab.

2. Click Firewall Rules.

3. Uncomment the SSH section (remove the # at the beginning of the line for the - name: SSH section).

4. If you do not have such a - name: SSH section, manually add the following under the firewall-rules: section:

   name: SSH
   network-groups:
   - MANAGEMENT
   rules:
   - type: allow
     remote-ip-prefix: 0.0.0.0/0
     port-range-min: 22
     port-range-max: 22
     protocol: tcp

Important

Manual edits to your configuration files outside of the Install UI may not be reflected in the Install UI. If you make changes to any files directly, refresh the browser to make sure changes are seen by the Install UI.

Before performing the deployment, the configuration must be validated by clicking the Validate button below the list of configuration files on the Model tab. This ensures the configuration will be successful before the actual configuration process runs and possibly fails. The Validate button also commits any changes. If there are issues with the validation, the configuration processor will provide detailed information about the causes. When validation completes successfully, a message will be displayed that the model is valid. If either validation or commit fail, the Next button is disabled.

Clicking the Deploy button starts the actual deployment process.

General progress steps are shown on the left. Detailed activity is shown on the right.

To start the deployment process, the Install UI runs scripts and playbooks based on the actual final configuration. Completed operations are green, black means in process, gray items are not started yet.

The log stream on the right shows finished states. If there are any failures, the log stream will show the errors and the Next button will be disabled. The Back and Next buttons are disabled during the deployment process.

The log files in ~/ardana/.ansible/ansible.log and /var/cache/ardana_installer/ have debugging information.

When the deployment process is complete, all items on the left will be green. Some deployments will not include all steps shown if they do not apply to the selected input model. In such a situation, those unneeded steps will remain gray.

The Next button will be enabled when deployment is successful.

Clicking Next will display the Cloud Deployment Successful page with information about the deployment, including the chosen input model and links to cloud management tools.

After installation is complete, shutdown the Install UI by logging into the Cloud Lifecycle Manager and running the following commands:

cd ~/openstack/ardana/ansible
ansible-playbook -i hosts/localhost installui-stop.yml

After deployment, continue to Chapter 26, Cloud Verification and Chapter 32, Other Common Post-Installation Tasks.

To understand cloud configuration more thoroughly and to learn how to make changes later, see:

On a system new to SUSE OpenStack Cloud 8, the Cloud Lifecycle Manager will prepare a git repository under ~/openstack. The Cloud Lifecycle Manager provisioning runs the ardana-init-deployer script automatically. This calls ansible-playbook -i hosts/localhost git-00-initialise.yml.

As a result, the ~/openstack directory is initialized as a git repo (if it is empty). It is initialized with four empty branches:

Two temporary branches are created and populated at run time:

Note

The information above provides insight into the workings of the configuration processor and the git repository. However, in practice you can simply follow the steps below to make configuration changes.

When you need to make updates to a configuration you must:

When you make changes, SUSE OpenStack Cloud attempts to incorporate new or updated configuration information on top of your existing environment. However, with some changes to your environment, SUSE OpenStack Cloud cannot automatically determine whether to keep your changes or drop them in favor of the new or updated configurations. This will result in merge conflicts, and it will be up to you to manually resolve the conflicts before you can proceed. This is common, but it can be confusing. Git provides a way to resolve these situations.

This section gives an overview of how to approach the issue of merge conflicts, showing general procedures for determining where the conflict is occurring, alternative methods for resolution, and a fallback procedure for the case where the resolution goes wrong and you need to start changes from the beginning.

For a general overview of how SUSE OpenStack Cloud uses Git, see the introductory article Chapter 10, Using Git for Configuration Management. In particular, note how the site branch is the one most used by the end-user, while the ardana branch contains the "upstream" source code corresponding to the contents of the ~/openstack directory on a pristine fresh installation.

Auto-merging ardana/ansible/roles/nova-compute-esx/defaults/main.yml
Auto-merging ardana/ansible/roles/nova-common/templates/nova.conf.j2
CONFLICT (content): Merge conflict in ardana/ansible/roles/nova-common/templates/nova.conf.j2
Auto-merging ardana/ansible/roles/nova-cli/tasks/availability_zones.yml
Auto-merging ardana/ansible/roles/nova-api/templates/api-paste.ini.j2

...
        new file:   tech-preview/entry-scale-kvm-mml/data/swift/rings.yml
        modified:   tech-preview/mid-scale/README.md
        modified:   tech-preview/mid-scale/data/control_plane.yml

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)

        both modified:   ardana/ansible/roles/nova-common/templates/nova.conf.j2

[neutron]
admin_auth_url = {{ neutron_admin_auth_url }}
admin_password = {{ neutron_admin_password }}
admin_tenant_name = {{ neutron_admin_tenant_name }}
admin_username = {{ neutron_admin_username }}
<<<<<<<HEAD
metadata_proxy_shared_secret = top_secret_password111
=======
metadata_proxy_shared_secret = {{ neutron_metadata_proxy_shared_secret }}
>>>>>>> ardana
neutron_auth_strategy = keystone
neutron_ca_certificates_file = /etc/ssl/certs/ca-certificates.crt
service_metadata_proxy = True

tux > git merge-base ardana site
2eda1df48e2822533c50f80f5bfd7a9d788bdf73

tux > git log ardana --
commit 22cfa83f3526baf30b3697e971a712930f86f611
Author: Openstack git user <openstack@example.com>
Date:   Mon Jan 18 00:30:33 2018 +0000

    New drop

commit 2eda1df48e2822533c50f80f5bfd7a9d788bdf73
Author: Openstack git user <openstack@example.com>
Date:   Sun Jan 17 19:14:01 2018 +0000

    New drop

tux > git diff ardana^1 HEAD -- ardana/ansible/roles/nova-common/templates/nova.conf.j2

tux > diff --git a/ardana/ansible/roles/nova-common/templates/nova.conf.j2 b/ardana/ansible/roles/nova-common/templates/nova.conf.j2
index 597a982..05cb07c 100644
--- a/ardana/ansible/roles/nova-common/templates/nova.conf.j2
+++ b/ardana/ansible/roles/nova-common/templates/nova.conf.j2
@@ -132,7 +132,7 @@ admin_auth_url = {{ neutron_admin_auth_url }}
 admin_password = {{ neutron_admin_password }}
 admin_tenant_name = {{ neutron_admin_tenant_name }}
 admin_username = {{ neutron_admin_username }}
-metadata_proxy_shared_secret = unset
+metadata_proxy_shared_secret = top_secret_password111
 neutron_auth_strategy = keystone
 neutron_ca_certificates_file = /etc/ssl/certs/ca-certificates.crt
 service_metadata_proxy = True

tux > git diff HEAD ardana -- ardana/ansible/roles/nova-common/templates/nova.conf.j2

..
 admin_username = {{ neutron_admin_username }}
-metadata_proxy_shared_secret = top_secret_password111
+metadata_proxy_shared_secret = {{ neutron_metadata_proxy_shared_secret }}
 neutron_auth_strategy = keystone
 neutron_ca_certificates_file = /etc/ssl/certs/ca-certificates.crt

tux > git diff $(git merge-base ardana HEAD) ardana -- ardana/ansible/roles/nova-common/templates/nova.conf.j2

 admin_password = {{ neutron_admin_password }}
 admin_tenant_name = {{ neutron_admin_tenant_name }}
 admin_username = {{ neutron_admin_username }}
-metadata_proxy_shared_secret = unset
+metadata_proxy_shared_secret = {{ neutron_metadata_proxy_shared_secret }}
 neutron_auth_strategy = keystone
 neutron_ca_certificates_file = /etc/ssl/certs/ca-certificates.crt

tux > git show :1:ardana/ansible/roles/nova-common/templates/nova.conf.j2

...
admin_username = {{ neutron_admin_username }}
metadata_proxy_shared_secret = unset
neutron_auth_strategy = keystone
neutron_ca_certificates_file = /etc/ssl/certs/ca-certificates.crt
...

tux > git show :2:ardana/ansible/roles/nova-common/templates/nova.conf.j2

...
admin_username = {{ neutron_admin_username }}
metadata_proxy_shared_secret = top_secret_password111
neutron_auth_strategy = keystone
neutron_ca_certificates_file = /etc/ssl/certs/ca-certificates.crt
...

tux > git show :3:ardana/ansible/roles/nova-common/templates/nova.conf.j2

...
admin_username = {{ neutron_admin_username }}
metadata_proxy_shared_secret = {{ neutron_metadata_proxy_shared_secret }}
neutron_auth_strategy = keystone
neutron_ca_certificates_file = /etc/ssl/certs/ca-certificates.crt
...

[neutron]
admin_auth_url = {{ neutron_admin_auth_url }}
admin_password = {{ neutron_admin_password }}
admin_tenant_name = {{ neutron_admin_tenant_name }}
admin_username = {{ neutron_admin_username }}
<<<<<<<HEAD
metadata_proxy_shared_secret = top_secret_password111
=======
metadata_proxy_shared_secret = {{ neutron_metadata_proxy_shared_secret }}
>>>>>>> ardana
neutron_auth_strategy = keystone
neutron_ca_certificates_file = /etc/ssl/certs/ca-certificates.crt
service_metadata_proxy = True

[neutron]
admin_auth_url = {{ neutron_admin_auth_url }}
admin_password = {{ neutron_admin_password }}
admin_tenant_name = {{ neutron_admin_tenant_name }}
admin_username = {{ neutron_admin_username }}
metadata_proxy_shared_secret = top_secret_password111
neutron_auth_strategy = keystone
neutron_ca_certificates_file = /etc/ssl/certs/ca-certificates.crt
service_metadata_proxy = True

tux > git show :3:ardana/ansible/roles/nova-common/templates/nova.conf.j2 > \
ardana/ansible/roles/nova-common/templates/nova.conf.j2

tux > git diff ardana -- ardana/ansible/roles/nova-common/templates/nova.conf.j2

tux > git add ardana/ansible/roles/nova-common/templates/nova.conf.j2

git commit -m "complete merge"

tux > git reset --hard

tux > git rm -rf ardana
tux > git reset --hard

Once you have your configuration files setup, you need to run the configuration processor to complete your configuration.

When you run the configuration processor, you will be prompted for two passwords. Enter the first password to make the configuration processor encrypt its sensitive data, which consists of the random inter-service passwords that it generates and the ansible group_vars and host_vars that it produces for subsequent deploy runs. You will need this password for subsequent Ansible deploy and configuration processor runs. If you wish to change an encryption password that you have already used when running the configuration processor then enter the new password at the second prompt, otherwise just press Enter to bypass this.

Run the configuration processor with this command:

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost config-processor-run.yml

For automated installation (for example CI), you can specify the required passwords on the ansible command line. For example, the command below will disable encryption by the configuration processor:

ardana > ansible-playbook -i hosts/localhost config-processor-run.yml \
  -e encrypt="" -e rekey=""

If you receive an error during this step, there is probably an issue with one or more of your configuration files. Verify that all information in each of your configuration files is correct for your environment. Then commit those changes to Git using the instructions in the previous section before re-running the configuration processor again.

For any troubleshooting information regarding these steps, see Section 23.2, “Issues while Updating Configuration Files”.

Important

This section is optional, but recommended, for a SUSE OpenStack Cloud installation.

After you run the configuration processor the first time, the IP addresses for your environment will be generated and populated in the ~/openstack/my_cloud/info/address_info.yml file. At this point, consider whether to configure TLS and set up an SSL certificate for your environment. Please read Chapter 29, Configuring Transport Layer Security (TLS) before proceeding for how to achieve this.

For any troubleshooting information regarding these steps, see Section 23.3, “Issues while Deploying the Cloud”.

The OpenStack CLI and OpenStack clients will not be installed automatically. If you require access to these clients, you will need to follow the procedure below to add the appropriate software.

We recommend verifying the installation using the instructions in Chapter 26, Cloud Verification.

There are also a list of other common post-installation administrative tasks listed in the Chapter 32, Other Common Post-Installation Tasks list.

During the configuration phase of the installation you will be making modifications to the example configuration input files to match your cloud environment. You should use the Book “Planning an Installation with Cloud Lifecycle Manager”, Chapter 9 “Example Configurations” documentation for detailed information on how to do this. There is also a README.md file included in each of the example directories on the Cloud Lifecycle Manager that has useful information about the models.

In the steps below we show how to set up the directory structure with the example input files as well as use the optional encryption methods for your sensitive data.

To provision the baremetal nodes in your cloud deployment you can either use the automated operating system installation process provided by SUSE OpenStack Cloud or you can use the 3rd party installation tooling of your choice. We will outline both methods below:

12.4.2 Using the Automated Operating System Installation Provided by SUSE OpenStack Cloud #

  

If you would like to use the automated operating system installation tools provided by SUSE OpenStack Cloud, complete the steps below.

12.4.2.1 Deploying Cobbler #

  

This phase of the install process takes the baremetal information that was provided in servers.yml and installs the Cobbler provisioning tool and loads this information into Cobbler. This sets each node to netboot-enabled: true in Cobbler. Each node will be automatically marked as netboot-enabled: false when it completes its operating system install successfully. Even if the node tries to PXE boot subsequently, Cobbler will not serve it. This is deliberate so that you cannot reimage a live node by accident.

The cobbler-deploy.yml playbook prompts for a password - this is the password that will be encrypted and stored in Cobbler, which is associated with the user running the command on the Cloud Lifecycle Manager, that you will use to log in to the nodes via their consoles after install. The username is the same as the user set up in the initial dialogue when installing the Cloud Lifecycle Manager from the ISO, and is the same user that is running the cobbler-deploy play.

Note

When imaging servers with your own tooling, it is still necessary to have ILO/IPMI settings for all nodes. Even if you are not using Cobbler, the username and password fields in servers.yml need to be filled in with dummy settings. For example, add the following to servers.yml:

ilo-user: manual
ilo-password: deployment

1. Run the following playbook which confirms that there is IPMI connectivity for each of your nodes so that they are accessible to be re-imaged in a later step:

   ardana > cd ~/openstack/ardana/ansible
   ardana > ansible-playbook -i hosts/localhost bm-power-status.yml

2. Run the following playbook to deploy Cobbler:

   ardana > cd ~/openstack/ardana/ansible
   ardana > ansible-playbook -i hosts/localhost cobbler-deploy.yml

12.4.2.2 Imaging the Nodes #

  

This phase of the install process goes through a number of distinct steps:

1. Powers down the nodes to be installed

2. Sets the nodes hardware boot order so that the first option is a network boot.

3. Powers on the nodes. (The nodes will then boot from the network and be installed using infrastructure set up in the previous phase)

4. Waits for the nodes to power themselves down (this indicates a successful install). This can take some time.

5. Sets the boot order to hard disk and powers on the nodes.

6. Waits for the nodes to be reachable by SSH and verifies that they have the signature expected.

Deploying nodes has been automated in the Cloud Lifecycle Manager and requires the following:

• All of your nodes using SLES must already be installed, either manually or via Cobbler.

• Your input model should be configured for your SLES nodes, according to the instructions at Book “Planning an Installation with Cloud Lifecycle Manager”, Chapter 10 “Modifying Example Configurations for Compute Nodes”, Section 10.1 “SLES Compute Nodes”.

• You should have run the configuration processor and the ready-deployment.yml playbook.

Execute the following steps to re-image one or more nodes after you have run the ready-deployment.yml playbook.

1. Run the following playbook, specifying your SLES nodes using the nodelist. This playbook will reconfigure Cobbler for the nodes listed.

   ardana > cd ~/openstack/ardana/ansible
   ardana > ansible-playbook prepare-sles-grub2.yml -e \
         nodelist=node1[,node2,node3]

2. Re-image the node(s) with the following command:

   ardana > cd ~/openstack/ardana/ansible
   ardana > ansible-playbook -i hosts/localhost bm-reimage.yml \
         -e nodelist=node1[,node2,node3]

If a nodelist is not specified then the set of nodes in Cobbler with netboot-enabled: True is selected. The playbook pauses at the start to give you a chance to review the set of nodes that it is targeting and to confirm that it is correct.

You can use the command below which will list all of your nodes with the netboot-enabled: True flag set:

sudo cobbler system find --netboot-enabled=1

Once you have your configuration files setup, you need to run the configuration processor to complete your configuration.

When you run the configuration processor, you will be prompted for two passwords. Enter the first password to make the configuration processor encrypt its sensitive data, which consists of the random inter-service passwords that it generates and the ansible group_vars and host_vars that it produces for subsequent deploy runs. You will need this password for subsequent Ansible deploy and configuration processor runs. If you wish to change an encryption password that you have already used when running the configuration processor then enter the new password at the second prompt, otherwise just press Enter to bypass this.

Run the configuration processor with this command:

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost config-processor-run.yml

For automated installation (for example CI), you can specify the required passwords on the ansible command line. For example, the command below will disable encryption by the configuration processor:

ardana > ansible-playbook -i hosts/localhost config-processor-run.yml \
  -e encrypt="" -e rekey=""

If you receive an error during this step, there is probably an issue with one or more of your configuration files. Verify that all information in each of your configuration files is correct for your environment. Then commit those changes to Git using the instructions in the previous section before re-running the configuration processor again.

For any troubleshooting information regarding these steps, see Section 23.2, “Issues while Updating Configuration Files”.

Important

This section is optional, but recommended, for a SUSE OpenStack Cloud installation.

After you run the configuration processor the first time, the IP addresses for your environment will be generated and populated in the ~/openstack/my_cloud/info/address_info.yml file. At this point, consider whether to configure TLS and set up an SSL certificate for your environment. Please read Chapter 29, Configuring Transport Layer Security (TLS) before proceeding for how to achieve this.

For any troubleshooting information regarding these steps, see Section 23.3, “Issues while Deploying the Cloud”.

SUSE OpenStack Cloud supports multiple block storage backend options. You can use one or more of these for setting up multiple block storage backends. Multiple volume types are also supported.

Whether you have a single or multiple block storage backends defined in your cinder.conf.j2 file, you can create one or more volume types using the specific attributes associated with the backend. For more information, see Section 22.1, “Configuring for 3PAR Block Storage Backend”.

We recommend verifying the installation using the instructions in Chapter 26, Cloud Verification.

There are also a list of other common post-installation administrative tasks listed in the Chapter 32, Other Common Post-Installation Tasks list.

SUSE OpenStack Cloud DNS Service defaults to the BIND back-end if another back-end is not configured for domain name service. BIND will be deployed to one or more control planes clusters. The following configuration example shows how the BIND service is installed.

control-planes:
          - name: control-plane-1
          region-name: region1

          clusters:
          - name: cluster1
          service-components:
          - lifecycle-manager
          - mariadb
          - ip-cluster
          - apache2
          - ...
          - designate-api
          - designate-central
          - designate-pool-manager
          - designate-zone-manager
          - designate-mdns
          - designate-client
          - bind

To configure the default DNS domain and Name Server records for the default pool, follow these steps.

Note

In an entry-scale model (Book “Planning an Installation with Cloud Lifecycle Manager”, Chapter 9 “Example Configurations”, Section 9.3 “KVM Examples”, Section 9.3.1 “Entry-Scale Cloud”), you will have 3 ns_records since the DNS service runs on all three control planes.

In a mid-scale model (Book “Planning an Installation with Cloud Lifecycle Manager”, Chapter 9 “Example Configurations”, Section 9.3 “KVM Examples”, Section 9.3.3 “Single-Region Mid-Size Model”) or dedicated metering, monitoring and logging model (Book “Planning an Installation with Cloud Lifecycle Manager”, Chapter 9 “Example Configurations”, Section 9.3 “KVM Examples”, Section 9.3.2 “Entry Scale Cloud with Metering and Monitoring Services”), the above example would be correct since there are only two controller nodes.

As an OpenStack API service, Magnum provides Container as a Service (CaaS) functionality. Magnum is capable of working with container orchestration engines (COE) such as Kubernetes, Docker Swarm, and Apache Mesos. Some operations work with a User CRUD (Create, Read, Update, Delete) filter.

Components

Figure 14.1: Service Architecture Diagram for Kubernetes #

  

Dependencies

Implementation

Magnum API and Magnum Conductor are run on the SUSE OpenStack Cloud controllers (or core nodes in case of mid-scale deployments).

Summary of controls spanning multiple components and interfaces:

Installing the Magnum Service can be performed as part of a new SUSE OpenStack Cloud 8 environment or can be added to an existing SUSE OpenStack Cloud 8 environment. Both installations require container management services, running in Magnum cluster VMs with access to specific Openstack API endpoints. The following TCP ports need to be open in your firewall to allow access from VMs to external (public) SUSE OpenStack Cloud endpoints.

Magnum is dependent on the following OpenStack services.

Warning

Magnum relies on the public discovery service https://discovery.etcd.io during cluster bootstrapping and update. This service does not perform authentication checks. Although running a cluster cannot be harmed by unauthorized changes in the public discovery registry, it can be compromised during a cluster update operation. To avoid this, it is recommended that you keep your cluster discovery URL (that is, https://discovery.etc.io/SOME_RANDOM_ID) secret.

14.2.1 Installing Magnum as part of new SUSE OpenStack Cloud 8 environment #

  

Magnum components are already included in example SUSE OpenStack Cloud models based on Nova KVM, such as entry-scale-kvm, entry-scale-kvm-mml and mid-scale. These models contain the Magnum dependencies (see above). You can follow generic installation instruction for Mid-Scale and Entry-Scale KM model by using this guide: Chapter 12, Installing Mid-scale and Entry-scale KVM.

Note

1. If you modify the cloud model to utilize a dedicated Cloud Lifecycle Manager, add magnum-client item to the list of service components for the Cloud Lifecycle Manager cluster.

2. Magnum needs a properly configured external endpoint. While preparing the cloud model, ensure that external-name setting in data/network_groups.yml is set to valid hostname, which can be resolved on DNS server, and a valid TLS certificate is installed for your external endpoint. For non-production test installations, you can omit external-name. In test installations, the SUSE OpenStack Cloud installer will use an IP address as a public endpoint hostname, and automatically generate a new certificate, signed by the internal CA. Please refer to Chapter 29, Configuring Transport Layer Security (TLS) for more details.

3. To use LBaaS v2 (Octavia) for container management and container applications, follow the additional steps to configure LBaaS v2 in the guide.

14.2.2 Adding Magnum to an Existing SUSE OpenStack Cloud Environment #

  

Adding Magnum to an already deployed SUSE OpenStack Cloud 8 installation or during an upgrade can be achieved by performing the following steps.

1. Add items listed below to the list of service components in ~/openstack/my_cloud/definition/data/control_plane.yml. Add them to clusters which have server-role set to CONTROLLER-ROLE (entry-scale models) or CORE_ROLE (mid-scale model).

   - magnum-api
   - magnum-conductor

2. If your environment utilizes a dedicated Cloud Lifecycle Manager, add magnum-client to the list of service components for the Cloud Lifecycle Manager.

3. Commit your changes to the local git repository. Run the following playbooks as described in Chapter 10, Using Git for Configuration Management for your installation.

   • config-processor-run.yml

   • ready-deployment.yml

   • site.yml

4. Ensure that your external endpoint is configured correctly. The current public endpoint configuration can be verified by running the following commands on the Cloud Lifecycle Manager.

   $ source service.osrc
   $ openstack endpoint list --interface=public --service=identity
   +-----------+---------+--------------+----------+---------+-----------+------------------------+
   | ID        | Region  | Service Name | Service  | Enabled | Interface | URL                    |
   |           |         |              | Type     |         |           |                        |
   +-----------+---------+--------------+----------+---------+-----------+------------------------+
   | d83...aa3 | region0 | keystone     | identity | True    | public    | https://10.245.41.168: |
   |           |         |              |          |         |           |             5000/v2.0  |
   +-----------+---------+--------------+----------+---------+-----------+------------------------+

   Ensure that the endpoint URL is using either an IP address, or a valid hostname, which can be resolved on the DNS server. If the URL is using an invalid hostname (for example, myardana.test), follow the steps in Chapter 29, Configuring Transport Layer Security (TLS) to configure a valid external endpoint. You will need to update the external-name setting in the data/network_groups.yml to a valid hostname, which can be resolved on DNS server, and provide a valid TLS certificate for the external endpoint. For non-production test installations, you can omit the external-name. The SUSE OpenStack Cloud installer will use an IP address as public endpoint hostname, and automatically generate a new certificate, signed by the internal CA. For more information, see Chapter 29, Configuring Transport Layer Security (TLS).

5. Ensure that LBaaS v2 (Octavia) is correctly configured. For more information, see Chapter 31, Configuring Load Balancer as a Service.

Warning

By default SUSE OpenStack Cloud stores the private key used by Magnum and its passphrase in Barbican which provides a secure place to store such information. You can change this such that this sensitive information is stored on the file system or in the database without encryption. Making such a change exposes you to the risk of this information being exposed to others. If stored in the database then any database backups, or a database breach, could lead to the disclosure of the sensitive information. Similarly, if stored unencrypted on the file system this information is exposed more broadly than if stored in Barbican.

Integration with DNSaaS may be needed if:

Follow these steps to integrate the Magnum Service with the DNS Service.

ESXi is a hypervisor developed by VMware for deploying and serving virtual computers. OVSvApp is a service VM that allows for leveraging advanced networking capabilities that OpenStack Neutron provides. As a result, OpenStack features can be added quickly with minimum effort where ESXi is used. OVSvApp allows for hosting VMs on ESXi hypervisors together with the flexibility of creating port groups dynamically on Distributed Virtual Switches (DVS). Network traffic can then be steered through the OVSvApp VM which provides VLAN and VXLAN underlying infrastructure for VM communication and security features based on OpenStack. More information is available at the OpenStack wiki.

The diagram below illustrates the OVSvApp architecture.