Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
ContentsContents
Deployment Guide using Cloud Lifecycle Manager
  1. I Planning an Installation using Cloud Lifecycle Manager
    1. 1 Registering SLES
    2. 2 Hardware and Software Support Matrix
    3. 3 Recommended Hardware Minimums for the Example Configurations
    4. 4 High Availability
  2. II Cloud Lifecycle Manager Overview
    1. 5 Input Model
    2. 6 Configuration Objects
    3. 7 Other Topics
    4. 8 Configuration Processor Information Files
    5. 9 Example Configurations
    6. 10 Modifying Example Configurations for Compute Nodes
    7. 11 Modifying Example Configurations for Object Storage using Swift
    8. 12 Alternative Configurations
  3. III Pre-Installation
    1. 13 Overview
    2. 14 Pre-Installation Checklist
    3. 15 Installing the Cloud Lifecycle Manager server
    4. 16 Installing and Setting Up an SMT Server on the Cloud Lifecycle Manager server (Optional)
    5. 17 Software Repository Setup
    6. 18 Boot from SAN and Multipath Configuration
  4. IV Cloud Installation
    1. 19 Overview
    2. 20 Preparing for Stand-Alone Deployment
    3. 21 Installing with the Install UI
    4. 22 Using Git for Configuration Management
    5. 23 Installing a Stand-Alone Cloud Lifecycle Manager
    6. 24 Installing Mid-scale and Entry-scale KVM
    7. 25 DNS Service Installation Overview
    8. 26 Magnum Overview
    9. 27 Installing ESX Computes and OVSvAPP
    10. 28 Integrating NSX for vSphere
    11. 29 Installing Baremetal (Ironic)
    12. 30 Installation for SUSE OpenStack Cloud Entry-scale Cloud with Swift Only
    13. 31 Installing SLES Compute
    14. 32 Installing manila and Creating manila Shares
    15. 33 Installing SUSE CaaS Platform heat Templates
    16. 34 Installing SUSE CaaS Platform v4 using terraform
    17. 35 Integrations
    18. 36 Troubleshooting the Installation
    19. 37 Troubleshooting the ESX
  5. V Post-Installation
    1. 38 Post Installation Tasks
    2. 39 UI Verification
    3. 40 Installing OpenStack Clients
    4. 41 Configuring Transport Layer Security (TLS)
    5. 42 Configuring Availability Zones
    6. 43 Configuring Load Balancer as a Service
    7. 44 Other Common Post-Installation Tasks
  6. VI Support
    1. 45 FAQ
    2. 46 Support
    3. 47 Applying PTFs (Program Temporary Fixes) Provided by SUSE L3 Support
    4. 48 Testing PTFs (Program Temporary Fixes) on a Single Node
Navigation
Applies to SUSE OpenStack Cloud 9

39 UI Verification Edit source

Once you have completed your cloud deployment, these are some of the common post-installation tasks you may need to perform to verify your cloud installation.

39.1 Verifying Your Block Storage Backend Edit source

The sections below will show you the steps to verify that your Block Storage backend was setup properly.

39.1.1 Create a Volume Edit source

Perform the following steps to create a volume using horizon dashboard.

  1. Log into the horizon dashboard.

  2. Choose Project › Compute › Volumes.

  3. On the Volumes tabs, click the Create Volume button to create a volume.

  4. In the Create Volume options, enter the required details into the fields and then click the Create Volume button:

    1. Volume Name - This is the name you specify for your volume.

    2. Description (optional) - This is an optional description for the volume.

    3. Type - Select the volume type you have created for your volumes from the drop down.

    4. Size (GB) - Enter the size, in GB, you would like the volume to be.

    5. Availability Zone - You can either leave this at the default option of Any Availability Zone or select a specific zone from the drop-down box.

The dashboard will then show the volume you have just created.

39.1.2 Attach Volume to an Instance Edit source

Perform the following steps to attach a volume to an instance:

  1. Log into the horizon dashboard.

  2. Choose Project › Compute › Instances.

  3. In the Action column, choose the Edit Attachments in the drop-down box next to the instance you want to attach the volume to.

  4. In the Attach To Instance drop-down, select the volume that you want to attach.

  5. Edit the Device Name if necessary.

  6. Click Attach Volume to complete the action.

  7. On the Volumes screen, verify that the volume you attached is displayed in the Attached To columns.

39.1.3 Detach Volume from Instance Edit source

Perform the following steps to detach the volume from instance:

  1. Log into the horizon dashboard.

  2. Choose Project › Compute › Instances.

  3. Click the check box next to the name of the volume you want to detach.

  4. In the Action column, choose the Edit Attachments in the drop-down box next to the instance you want to attach the volume to.

  5. Click Detach Attachment. A confirmation dialog box appears.

  6. Click Detach Attachment to confirm the detachment of the volume from the associated instance.

39.1.4 Delete Volume Edit source

Perform the following steps to delete a volume using horizon dashboard:

  1. Log into the horizon dashboard.

  2. Choose Project › Compute › Volumes.

  3. In the Actions column, click Delete Volume next to the volume you would like to delete.

  4. To confirm and delete the volume, click Delete Volume again.

  5. Verify that the volume was removed from the Volumes screen.

39.1.5 Verifying Your Object Storage (swift) Edit source

The following procedure shows how to validate that all servers have been added to the swift rings:

  1. Run the swift-compare-model-rings.yml playbook as follows:

    cd ~/scratch/ansible/next/ardana/ansible
    ansible-playbook -i hosts/verb_hosts swift-compare-model-rings.yml
  2. Search for output similar to the following. Specifically, look at the number of drives that are proposed to be added.

    TASK: [swiftlm-ring-supervisor | validate-input-model | Print report] *********
    ok: [ardana-cp1-c1-m1-mgmt] => {
        "var": {
            "report.stdout_lines": [
                "Rings:",
                "  ACCOUNT:",
                "    ring exists",
                "    no device changes",
                "    ring will be rebalanced",
                "  CONTAINER:",
                "    ring exists",
                "    no device changes",
                "    ring will be rebalanced",
                "  OBJECT-0:",
                "    ring exists",
                "    no device changes",
                "    ring will be rebalanced"
            ]
        }
    }
  3. If the text contains "no device changes" then the deploy was successful and no further action is needed.

  4. If more drives need to be added, it indicates that the deploy failed on some nodes and that you restarted the deploy to include those nodes. However, the nodes are not in the swift rings because enough time has not elapsed to allow the rings to be rebuilt. You have two options to continue:

    1. Repeat the deploy. There are two steps:

      1. Delete the ring builder files as described in Book “Operations Guide CLM”, Chapter 18 “Troubleshooting Issues”, Section 18.6 “Storage Troubleshooting”, Section 18.6.2 “swift Storage Troubleshooting”, Section 18.6.2.8 “Restarting the Object Storage Deployment”.

      2. Repeat the installation process starting by running the site.yml playbook as described in Section 24.7, “Deploying the Cloud”.

    2. Rebalance the rings several times until all drives are incorporated in the rings. This process may take several hours to complete (because you need to wait one hour between each rebalance). The steps are as follows:

      1. Change the min-part-hours to 1 hour. See Book “Operations Guide CLM”, Chapter 9 “Managing Object Storage”, Section 9.5 “Managing swift Rings”, Section 9.5.7 “Changing min-part-hours in Swift”.

      2. Use the "First phase of ring rebalance" and "Final rebalance phase" as described in Book “Operations Guide CLM”, Chapter 9 “Managing Object Storage”, Section 9.5 “Managing swift Rings”, Section 9.5.5 “Applying Input Model Changes to Existing Rings”. The Weight change phase of ring rebalance does not apply because you have not set the weight-step attribute at this stage.

      3. Set the min-part-hours to the recommended 16 hours as described in Book “Operations Guide CLM”, Chapter 9 “Managing Object Storage”, Section 9.5 “Managing swift Rings”, Section 9.5.7 “Changing min-part-hours in Swift”.

If you receive errors during the validation, see Book “Operations Guide CLM”, Chapter 18 “Troubleshooting Issues”, Section 18.6 “Storage Troubleshooting”, Section 18.6.2 “swift Storage Troubleshooting”, Section 18.6.2.3 “Interpreting Swift Input Model Validation Errors”.

Print this page