2 Tutorials #

Download the installation media

Obtain a copy of the SUSE OpenStack Cloud installation media, and make sure that it is accessible by the server that you are installing it on. Your method of doing this may vary. For instance, some may choose to load the installation ISO on a USB drive and physically attach it to the server, while others may run the IPMI Remote Console and attach the ISO to a virtual disc drive.

Install the operating system

1. Boot your server, using the installation media as the boot source.

2. Choose "install" from the list of options and choose your preferred keyboard layout, location, language, and other settings.

3. Set the address, netmask, and gateway for the primary network interface.

4. Create a root user account.

Proceed with the OS installation. After the installation is complete and the server has rebooted into the new OS, log in with the user account you created.

Configure the new server

1. SSH to your new server, and set a valid DNS nameserver in the /etc/resolv.conf file.

2. Set the environment variable LC_ALL:

   export LC_ALL=C

You now have a server running SUSE Linux Enterprise Server (SLES). The next step is to configure this machine as a Cloud Lifecycle Manager.

Configure the Cloud Lifecycle Manager

The installation media you used to install the OS on the server also has the files that will configure your cloud. You need to mount this installation media on your new server in order to use these files.

1. Using the URL that you obtained the SUSE OpenStack Cloud installation media from, run wget to download the ISO file to your server:

   wget INSTALLATION_ISO_URL

2. Now mount the ISO in the /media/cdrom/ directory

   sudo mount INSTALLATION_ISO /media/cdrom/

3. Unpack the tar file found in the /media/cdrom/ardana/ directory where you just mounted the ISO:

   tar xvf /media/cdrom/ardana/ardana-x.x.x-x.tar

4. Now you will install and configure all the components needed to turn this server into a Cloud Lifecycle Manager. Run the ardana-init.bash script from the uncompressed tar file:

   ~/ardana-x.x.x/ardana-init.bash

   The ardana-init.bash script prompts you to enter an optional SSH passphrase. This passphrase protects the RSA key used to SSH to the other cloud nodes. This is an optional passphrase, and you can skip it by pressing Enter at the prompt.

   The ardana-init.bash script automatically installs and configures everything needed to set up this server as the lifecycle manager for your cloud.

   When the script has finished running, you can proceed to the next step, editing your input files.

Edit your input files

Your SUSE OpenStack Cloud input files are where you define your cloud infrastructure and how it runs. The input files define options such as which servers are included in your cloud, the type of disks the servers use, and their network configuration. The input files also define which services your cloud will provide and use, the network architecture, and the storage backends for your cloud.

There are several example configurations, which you can find on your Cloud Lifecycle Manager in the ~/openstack/examples/ directory.

1. The simplest way to set up your cloud is to copy the contents of one of these example configurations to your ~/openstack/mycloud/definition/ directory. You can then edit the copied files and define your cloud.

   cp -r ~/openstack/examples/CHOSEN_EXAMPLE/* ~/openstack/my_cloud/definition/

2. Edit the files in your ~/openstack/my_cloud/definition/ directory to define your cloud.

Commit your changes

When you finish editing the necessary input files, stage them, and then commit the changes to the local Git repository:

cd ~/openstack/ardana/ansible
git add -A
git commit -m "My commit message"

Image your servers

Now that you have finished editing your input files, you can deploy the configuration to the servers that will comprise your cloud.

1. Image the servers. You will install the SLES operating system across all the servers in your cloud, using Ansible playbooks to trigger the process.

2. The following playbook confirms that your servers are accessible over their IPMI ports, which is a prerequisite for the imaging process:

   ansible-playbook -i hosts/localhost bm-power-status.yml

3. Now validate that your cloud configuration files have proper YAML syntax by running the config-processor-run.yml playbook:

   ansible-playbook -i hosts/localhost config-processor-run.yml

   If you receive an error when running the preceeding playbook, one or more of your configuration files has an issue. Refer to the output of the Ansible playbook, and look for clues in the Ansible log file, found at ~/.ansible/ansible.log.

4. The next step is to prepare your imaging system, Cobbler, to deploy operating systems to all your cloud nodes:

   ansible-playbook -i hosts/localhost cobbler-deploy.yml

5. Now you can image your cloud nodes. You will use an Ansible playbook to trigger Cobbler to deploy operating systems to all the nodes you specified in your input files:

   ansible-playbook -i hosts/localhost bm-reimage.yml

   The bm-reimage.yml playbook performs the following operations:

   1. Powers down the servers.

   2. Sets the servers to boot from a network interface.

   3. Powers on the servers and performs a PXE OS installation.

   4. Waits for the servers to power themselves down as part of a successful OS installation. This can take some time.

   5. Sets the servers to boot from their local hard disks and powers on the servers.

   6. Waits for the SSH service to start on the servers and verifies that they have the expected host-key signature.

Deploy your cloud

Now that your servers are running the SLES operating system, it is time to configure them for the roles they will play in your new cloud.

1. Prepare the Cloud Lifecycle Manager to deploy your cloud configuration to all the nodes:

   ansible-playbook -i hosts/localhost ready-deployment.yml

   NOTE: The preceding playbook creates a new directory, ~/scratch/ansible/next/ardana/ansible/, from which you will run many of the following commands.

2. (Optional) If you are reusing servers or disks to run your cloud, you can wipe the disks of your newly imaged servers by running the wipe_disks.yml playbook:

   cd ~/scratch/ansible/next/ardana/ansible/
   ansible-playbook -i hosts/verb_hosts wipe_disks.yml

   The wipe_disks.yml playbook removes any existing data from the drives on your new servers. This can be helpful if you are reusing servers or disks. This action will not affect the OS partitions on the servers.

   

   Note

   The wipe_disks.yml playbook is only meant to be run on systems immediately after running bm-reimage.yml. If used for any other case, it may not wipe all of the expected partitions. For example, if site.yml fails, you cannot start fresh by running wipe_disks.yml. You must bm-reimage the node first and then run wipe_disks.

3. Now it is time to deploy your cloud. Do this by running the site.yml playbook, which pushes the configuration you defined in the input files out to all the servers that will host your cloud.

   cd ~/scratch/ansible/next/ardana/ansible/
   ansible-playbook -i hosts/verb_hosts site.yml

   The site.yml playbook installs packages, starts services, configures network interface settings, sets iptables firewall rules, and more. Upon successful completion of this playbook, your SUSE OpenStack Cloud will be in place and in a running state. This playbook can take up to six hours to complete.

SSH to your nodes

Now that you have successfully run site.yml, your cloud will be up and running. You can verify connectivity to your nodes by connecting to each one by using SSH. You can find the IP addresses of your nodes by viewing the /etc/hosts file.

For security reasons, you can only SSH to your nodes from the Cloud Lifecycle Manager. SSH connections from any machine other than the Cloud Lifecycle Manager will be refused by the nodes.

From the Cloud Lifecycle Manager, SSH to your nodes:

ssh <management IP address of node>

Also note that SSH is limited to your cloud's management network. Each node has an address on the management network, and you can find this address by reading the /etc/hosts or server_info.yml file.

Log in to the Cloud Lifecycle Manager.

Edit your control_plane.yml file. Full path:

~/openstack/my_cloud/definition/data/control_plane.yml

In this file you will see a list of service-components to be installed on each of your clusters. These clusters will be divided per role, with your controller node cluster likely coming at the beginning. Here you will see a list of each of the clients that can be installed. These include:

keystone-client
glance-client
cinder-client
nova-client
neutron-client
swift-client
heat-client
openstack-client
monasca-client
barbican-client
designate-client

For each client you want to install, specify the name under the service-components section for the cluster you want to install it on.

So, for example, if you would like to install the nova and neutron clients on your Compute node cluster, you can do so by adding the nova-client and neutron-client services, like this:

      resources:
        - name: compute
          resource-prefix: comp
          server-role: COMPUTE-ROLE
          allocation-policy: any
          min-count: 0
          service-components:
            - ntp-client
            - nova-compute
            - nova-compute-kvm
            - neutron-l3-agent
            - neutron-metadata-agent
            - neutron-openvswitch-agent
            - nova-client
            - neutron-client

Note

This example uses the entry-scale-kvm sample file. Your model may be different so use this as a guide but do not copy and paste the contents of this example into your input model.

Commit your configuration to the local git repo, as follows:

cd ~/openstack/ardana/ansible
git add -A
git commit -m "My config or other commit message"

Continue with the rest of your installation.

Make sure that the LDAP-enabled system you plan to integrate with is up and running and accessible over the necessary ports from your cloud management network.

Edit the /var/lib/ardana/openstack/my_cloud/config/keystone/keystone.conf.j2 file and set the following options:

domain_specific_drivers_enabled = True
domain_configurations_from_database = False

Create a YAML file in the /var/lib/ardana/openstack/my_cloud/config/keystone/ directory that defines your LDAP connection. You can make a copy of the sample keystone-LDAP configuration file, and then edit that file with the details of your LDAP connection.

The following example copies the keystone_configure_ldap_sample.yml file and names the new file keystone_configure_ldap_my.yml:

ardana > cp /var/lib/ardana/openstack/my_cloud/config/keystone/keystone_configure_ldap_sample.yml \
  /var/lib/ardana/openstack/my_cloud/config/keystone/keystone_configure_ldap_my.yml

Edit the new file to define the connection to your LDAP source. This guide does not provide comprehensive information on all aspects of the keystone_configure_ldap.yml file. Find a complete list of keystone/LDAP configuration file options at: https://github.com/openstack/keystone/tree/stable/rocky/etc

The following file illustrates an example keystone configuration that is customized for an Active Directory connection.

keystone_domainldap_conf:

    # CA certificates file content.
    # Certificates are stored in Base64 PEM format. This may be entire LDAP server
    # certificate (in case of self-signed certificates), certificate of authority
    # which issued LDAP server certificate, or a full certificate chain (Root CA
    # certificate, intermediate CA certificate(s), issuer certificate).
    #
    cert_settings:
      cacert: |
        -----BEGIN CERTIFICATE-----

        certificate appears here

        -----END CERTIFICATE-----

    # A domain will be created in MariaDB with this name, and associated with ldap back end.
    # Installer will also generate a config file named /etc/keystone/domains/keystone.<domain_name>.conf
    #
    domain_settings:
      name: ad
      description: Dedicated domain for ad users

    conf_settings:
      identity:
         driver: ldap


      # For a full list and description of ldap configuration options, please refer to
      # http://docs.openstack.org/liberty/config-reference/content/keystone-configuration-file.html.
      #
      # Please note:
      #  1. LDAP configuration is read-only. Configuration which performs write operations (i.e. creates users, groups, etc)
      #     is not supported at the moment.
      #  2. LDAP is only supported for identity operations (reading users and groups from LDAP). Assignment
      #     operations with LDAP (i.e. managing roles, projects) are not supported.
      #  3. LDAP is configured as non-default domain. Configuring LDAP as a default domain is not supported.
      #

      ldap:
        url: ldap://YOUR_COMPANY_AD_URL
        suffix: YOUR_COMPANY_DC
        query_scope: sub
        user_tree_dn: CN=Users,YOUR_COMPANY_DC
        user : CN=admin,CN=Users,YOUR_COMPANY_DC
        password: REDACTED
        user_objectclass: user
        user_id_attribute: cn
        user_name_attribute: cn
        group_tree_dn: CN=Users,YOUR_COMPANY_DC
        group_objectclass: group
        group_id_attribute: cn
        group_name_attribute: cn
        use_pool: True
        user_enabled_attribute: userAccountControl
        user_enabled_mask: 2
        user_enabled_default: 512
        use_tls: True
        tls_req_cert: demand
        # if you are configuring multiple LDAP domains, and LDAP server certificates are issued
        # by different authorities, make sure that you place certs for all the LDAP backend domains in the
        # cacert parameter as seen in this sample yml file so that all the certs are combined in a single CA file
        # and every LDAP domain configuration points to the combined CA file.
        # Note:
        # 1. Please be advised that every time a new ldap domain is configured, the single CA file gets overwritten
        # and hence ensure that you place certs for all the LDAP backend domains in the cacert parameter.
        # 2. There is a known issue on one cert per CA file per domain when the system processes
        # concurrent requests to multiple LDAP domains. Using the single CA file with all certs combined
        # shall get the system working properly.

        tls_cacertfile: /etc/keystone/ssl/certs/all_ldapdomains_ca.pem

Add your new file to the local Git repository and commit the changes.

ardana > cd ~/openstack
ardana > git checkout site
ardana > git add -A
ardana > git commit -m "Adding LDAP server integration config"

Run the configuration processor and deployment preparation playbooks to validate the YAML files and prepare the environment for configuration.

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

Run the keystone reconfiguration playbook to implement your changes, passing the newly created YAML file as an argument to the -e@FILE_PATH parameter:

ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > ansible-playbook -i hosts/verb_hosts keystone-reconfigure.yml \
  -e@/var/lib/ardana/openstack/my_cloud/config/keystone/keystone_configure_ldap_my.yml

To integrate your SUSE OpenStack Cloud cloud with multiple domains, repeat these steps starting from Step 3 for each domain.