rackspace.com/cloud/private

Transcription

1 rackspace.com/cloud/private

2 Rackspace Private Cloud Installation ( ) Copyright 2014 Rackspace All rights reserved. This documentation is intended for users who want to install Rackspace Private Cloud. ii

3 Table of Contents 1. Preface About Rackspace Private Cloud Rackspace Private Cloud configuration Rackspace Private Cloud support Installation prerequisites Preparing for the installation Hardware requirements Chef server requirements Cluster node requirements Software requirements Proxy considerations High Availability Availability zones Installation Node preparation Chef server and cookbooks Chef server installation Rackspace Private Cloud cookbook installation Installing OpenStack Overview of the configuration Create an environment Define network attributes Installing Chef client Adding a controller node Adding a Compute node Controller node high availability Troubleshooting the installation Integration with OpenStack OpenStack metering OpenStack Orchestration Installing Orchestration Using Orchestration Storage Local File Storage Rackspace cloud files Swift storage Additional resources Document Change History iii

4 1. Preface 1.1. About Rackspace Private Cloud Rackspace Private Cloud is a set of tools that allow you to quickly install an OpenStack private cloud, configured as recommended by Rackspace OpenStack specialists. Rackspace Private Cloud uses Chef to create an OpenStack cluster on Ubuntu, CentOS, or Red Hat Enterprise Linux. The installation scripts provide a familiar approach for Linux system administrators, and can be updated easily without downloading and installing a new ISO. Note This is the Rackspace Private Cloud Installation. The Rackspace Private Cloud v9 Installation is available at rpc/api/v9/bk-rpc-installation/content/rpc-common-front.html 1.2. Rackspace Private Cloud configuration Rackspace Private Cloud.1.5 installs OpenStack Grizzly, which contains these components: Compute (nova) Image Service (glance) Dashboard (horizon) Identity (keystone) Virtual Network (neutron) Rackspace Private Cloud.2.2 installs OpenStack Havana, which contains these components: Compute (nova) Image Service (glance) Dashboard (horizon) Identity (keystone) Virtual Network (neutron) Metering (ceilometer) Object Storage (swift) is also available in the Rackspace Private Cloud Object Storage offering. 1

5 1.3. Rackspace Private Cloud support Rackspace offers 365x24x7 support for Rackspace Private Cloud. If you are interested in purchasing Escalation Support or Core Support for your cloud, or taking advantage of our training offerings, contact us at: You can also visit the Rackspace Private Cloud community forums. The forum is open to all Rackspace Private Cloud users and is moderated and maintained by Rackspace personnel and OpenStack specialists: For any other information regarding your Rackspace Private Cloud, refer to the Rackspace Private Cloud release notes. 2

6 2. Installation prerequisites This chapter lists the prerequisites for installing a cluster with the Rackspace Private Cloud tools. Rackspace recommends that you review this chapter in detail before attempting the installation Preparing for the installation You need the following information for the installation: The nova network address in CIDR format. The nova network bridge, such as br100 or eth0. This will be used as the VM bridge on compute nodes. The default value is usually acceptable. This bridge will be created by Nova as necessary and does not need to be manually configured. The public network address in CIDR format. This is where public API services, such as the public Keystone endpoint and the dashboard, will run. An IP address from this network should be configured on all hosts in the Nova cluster. The public network interface, such as eth0 or eth1. This is the network interface that is connected to the public network on compute nodes. In a nova-network configuration, compute nodes with instance traffic NAT out from this interface unless a specific floating IP address has been assigned to that instance. The management network address in CIDR format. This network is used for communication among services such as monitoring and syslog. This is the same as your Nova public network if you do not want to separate service traffic. The VM network CIDR range. This is the range from which IP addresses will be automatically assigned to VMs. An address from this network will be visible from within your instance on eth0. This network should be dedicated to OpenStack and not shared with other services. The network interface of the VM network for the compute notes (such as eth1). The name of the Nova cluster. This should be unique and composed of alphanumeric characters, hyphens (-), or underscores (_). The name of the default availability zone. Rackspace recommends using nova as the default. For nova-network configurations, an optional NAT exclusion CIDR range or ranges for networks configured with a DMZ. A comma-separated list of CIDR network ranges that will be excluded from NAT rules. This enables direct communication to and from instances from other network ranges without the use of floating IPs Hardware requirements Rackspace Private Cloud has been tested in deployment with a physical device for each of the following nodes: 3

7 A Chef server An OpenStack Nova Controller node Additional physical machines with OpenStack Nova compute nodes as required Chef server requirements Rackspace recommends that the Chef server hardware meet the following requirements: 4 GB RAM 50 GB disk space Dual socket CPU with dual core Cluster node requirements Each node in the cluster will have chef-client installed on it. The hardware requirements vary depending on the purpose of the node. Each device should support VT-x. This table outlines the detailed requirements: Node Type Nova Controller Nova Compute Requirements 16 GB RAM 144 GB disk space Dual socket CPU with dual core, or single socket quad core 32 GB RAM 144 GB disk space Dual socket CPU with dual core, or single socket quad core CPU overcommit is set at 16:1 VCPUs to cores, and memory overcommit is set to 1.5:1. Each physical core can support up to 16 virtual cores; for example, one dual-core processor can support up to 32 virtual cores. If you require more virtual cores, add additional physical nodes to your configuration. For a list of Private Cloud certified devices, refer to Private Cloud Certified Devices - Compute Software requirements This table lists the operating systems on which Rackspace Private Cloud has been tested. Operating System Ubuntu Ubuntu and later CentOS 6.3 CentOS 6.4 Red Hat Enterprise Linux 6.0 Tested Rackspace Private Cloud Version All versions None.0.0 and earlier.1.2 and later None It is possible to install Rackspace Private Cloud on untested OSes, however this can cause unexpected issues. 4

8 If you require the Controller and Networking nodes with OpenStack Networking, Rackspace recommends that you use Rackspace Private Cloud.2.2 or later with CentOS 6.4 or Ubuntu Note Rackspace Private Cloud only supports kernel kernel openstack.el6.x86_ Proxy considerations When installing Rackspace Private Cloud, please ensure none of your nodes are behind a proxy. If they are behind a proxy, review this section before proceeding with the installation. Procedure 2.1. Configuring proxy environment settings on the nodes 1. You must make your proxy settings available to the entire OS on each node by configuring /etc/environment as follows: $ /etc/environment http_proxy= https_proxy= ftp_proxy= no_proxy=<localhost>,<node1>,<node2> 2. Replace node1 and node2 with the hostnames of your nodes. In all cases, no_proxy is required and must contain a localhost entry. If localhost is missing, the Omnibus Chef Server installation will fail. We recommend that you set as many variables as you can as installation methods can change over time. Ubuntu requires at least http_proxy and no_proxy to be set. CentOS requires at least http_proxy, https_proxy, and no_proxy for yum packages and key updates. 3. The nodes must also have root configured to retain the following environment variables: Defaults env_keep += "http_proxy https_proxy ftp_proxy no_proxy" On Ubuntu, this can be put in a file in /etc/sudoers.d. On CentOS, ensure that your version loads files in /etc/sudoers.d before adding this variable. 4. Verify that the proxy settings are correct by running the env command as both the unprivileged and root users. 5

9 This command will output a list of environment variables for the current user. If your proxy settings have been set correctly, then the http_proxy, https_proxy, ftp_proxy, and no_proxy settings will appear in the list High Availability Rackspace Private Cloud has the ability to implement support for high availability (HA) for all Nova service components and APIs. Rackspace Private Cloud can also implement HA support for Glance, Keystone, Cinder, RabbitMQ and MySQL. The scheduler High Availability functionality is powered by Keepalived and HAProxy. Note High availability requires that you allocate a virtual IP (VIP) for each component. For more information, see Section 3.3.7, Controller node high availability [14]. Rackspace Private Cloud uses the following methods to implement HA in your cluster: MySQL master-master replication and active-passive failover: MySQL is installed on both controller nodes, and master-master replication is configured between the nodes. Keepalived manages connections to the two nodes, so that only one node receives reads/write requests at any one time. RabbitMQ active/passive failover: RabbitMQ is installed on both controller nodes. Keepalived manages connections to the two nodes, so that only one node is active at any one time. API load balancing: All services that are stateless and can be load balanced (essentially all the APIs and a few others) are installed on both controller nodes. HAProxy is then installed on both nodes, and Keepalived manages connections to HAProxy, which makes HAProxy itself HA. Keystone endpoints and all API access go through Keepalived Availability zones Availability zones enable you to manage and isolate different nodes within the environment. For example, you may want to isolate different sets of compute nodes to provide different resources to customers. If one availability zone experiences downtime, other zones in the cluster are not affected. When you create a Nova cluster, it is created with a default availability zone, and all compute nodes are assigned to that zone. You can create additional availability zones within the cluster as needed. 6

10 3. Installation This chapter discusses the process for installing an OpenStack environment with the Rackspace Private Cloud cookbooks. For networking, these instructions only apply to the default nova-network configuration. For information about OpenStack Networking (Neutron) see the Rackspace Private Cloud Networking. For information about upgrading between Rackspace Private Cloud versions, refer to the Rackspace Private Cloud Upgrade. The installation process involves the following stages: Preparing the nodes Installing Chef server, the Rackspace Private Cloud cookbooks, and chef-client Creating a Chef environment and defining attributes Setting the node environments Applying the controller and compute roles to the nodes Note Before you begin, Rackspace recommends that you review Installation prerequisites to ensure that you have completed all necessary preparations for the installation process Node preparation Before you begin, ensure that the OS is up-to-date on the nodes and that an administrative user with the same user name is configured across all nodes in your environment Chef server and cookbooks Your environment must have a Chef server, the latest versions of the Rackspace Private Cloud cookbooks, and chef-client on each node within the environment. You must install the Chef server node first. chef-client will be installed as part of the node bootstrapping process. Installation is performed via a curl command, which launches an installation script. The script downloads the packages from GitHub, and uses the packages to install the components. You can review the scripts in the GitHub repository at the following link github.com/rcbops/support-tools/tree/master/chef-install. Before you begin, ensure that curl is available, or install it with apt-get install -y curl on Ubuntu or yum install curl on CentOS. 7

11 Chef server installation To ensure correct server installation, the devices configured as OpenStack cluster nodes on ports 443 and 80 should be able to access the Chef Server device. On distributions running iptables, you will need to enable access on these ports. By default, the script installs Chef with a set of randomly generated passwords, and also installs a Knife configuration that is set up for the root user. The following variables are added to your environment: CHEF_SERVER_VERSION: defaults to CHEF_URL: defaults to CHEF_UNIX_USER: the user for which the Knife configuration is set; defaults to root. A set of randomly generated passwords: CHEF_WEBUI_PASSWORD CHEF_AMQP_PASSWORD CHEF_POSTGRESQL_PASSWORD CHEF_POSTGRESQL_RO_PASSWORD Procedure 3.1. To install the Chef server 1. Log in to the device that will be the Chef server and download the install-chefserver.sh script. Run the script: # curl -s -O master/chef-install/install-chef-server.sh \ # bash install-chef-server.sh 2. Source the environment file to enable the knife command. # source /root/.bash_profile 3. Run the following command to ensure that knife is working correctly. # knife client list If the command runs successfully, the installation is complete. If the installation fails, you will need to log out of the server and log in again to re-source the environment. 8

12 Rackspace Private Cloud cookbook installation The Rackspace Private Cloud cookbooks are set up as Git submodules and are hosted at with individual cookbook repositories at You can also download the cookbooks from the rcbops GitHub repository without the script. The following procedure describes the download process for the full suite, but you can also download individual cookbook repositories, such as the Nova repository, at Procedure 3.2. To download and install cookbooks from GitHub 1. Log into your Chef server, or on a workstation that has knife access to the Chef server. 2. Verify that the knife.rb configuration file contains the correct cookbook_path setting. 3. Use git clone to download the cookbooks. # git clone 4. Navigate to the chef-cookbooks directory. # cd chef-cookbooks 5. Check out the desired version of the cookbooks. The current versions are.2.2 and.1.3. # git checkout <version> # git submodule init # git submodule sync # git submodule update 6. Upload the cookbooks to the Chef server. # knife cookbook upload -a -o cookbooks 7. Apply the updated roles. # knife role from file roles/*rb 3.3. Installing OpenStack This section demonstrates a typical Rackspace Private Cloud installation, and includes additional information about customizing or modifying your installation. 9

13 Overview of the configuration When your configure your Rackspace Private Cloud environment with the Rackspace Private Cloud cookbooks, the cookbooks will configure a specific set of components into your environment: One or two controller nodes that host central services: RabbitMQ, MySQL, and the Horizon Dashboard. One or more Compute nodes that host Virtual Machines. One networking node. You may have a standalone networking node set up if you are using OpenStack Networking. Networking roles can also be applied to the Controller node. Configuration The Rackspace Private Cloud Cookbooks create a custom OpenStack installation that has been designed by Rackspace: MySQL is set up as the database for all OpenStack Services, including Nova, Glance, and Neutron. The VRRP provides high availability. HAproxy provides load balancing. KVM is used for the hypervisor. The network is a flat High Availability network, such as nova-network, or can be Neutron-controlled Create an environment The first step is to create an environment on the Chef server. In this example, the knife environment create command is used to create an environment called private-cloud. The -d flag is used to add a description of the environment. # knife environment create private-cloud -d "Rackspace Private Cloud OpenStack Environment" This creates a JSON environment file, which can be directly edited to add attributes specific to your configuration. To edit the environment, run the knife environment edit command: # knife environment edit private-cloud This will open a text editor where the environment settings can be modified and override attributes added Define network attributes You must now add a set of override attributes to define the nova, public, and management networks in your environment. 10

14 Note This information is for configuring nova-network, which is what a Rackspace Private Cloud environment uses by default. If you want to use OpenStack Networking, see the Networking. To define override attributes, you will need to run the knife environment edit command. Add a networking section, and substitute your own network information. The.2.2 and.1.5 cookbooks use hash syntax to define network attributes. The syntax is as follows: "override_attributes": { "nova": { "network": { "public_interface": "<publicinterface>", "networks": { "public": { "label": "public", "bridge_dev": "<VMNetworkInterface>", "dns2": " ", "ip_cidr": "<VMNetworkCIDR>", "bridge": "<networkbridge>", "dns1": " ", "mysql": { "allow_remote_root": true, "root_network_acl": "%", "osops_networks": { "nova": "<novanetworkcidr>", "public": "<publicnetworkcidr>", "management": "<managementnetworkcidr>" 11

15 The following example shows an environment configuration in which all three networks are folded onto a single physical network. This network has an IP address in the /24 range. All internal services, API endpoints, and monitoring and management functions run over this network. VMs are brought up on a /24 network on eth1, connected to a bridge called br100. "override_attributes": { "nova": { "network": { "public_interface": "br100", "networks": { "public": { "label": "public", "bridge_dev": "eth1", "dns2": " ", "ip_cidr": " /24", "bridge": "br100", "dns1": " ", "mysql": { "allow_remote_root": true, "root_network_acl": "%", "osops_networks": { "nova": " /24", "public": " /24", "management": " /24" Installing Chef client All of the nodes in your OpenStack cluster need to have chef-client installed and configured to communicate with the Chef server. This can be most easily accomplished with the knife bootstrap command. The nodes on which the OpenStack Object Storage cluster will be configured should be able to access the Chef server on ports 443 and 80. This will not work if you are behind an HTTP proxy. Each client node must have a resolvable hostname. If the hostname cannot resolve, the nodes will not be able to check in properly. Procedure 3.3. Bootstrapping nodes to the Chef server 1. Log in to the Chef server as root. 2. Generate an ssh key with the ssh-keygen command. Accept the defaults when prompted. 3. Use the knife bootstrap command to bootstrap the nodes to the Chef server. This command installs chef-client on the target node. It allows the node to communicate with the server. You will specify the name of the environment, the user name that will be associated with the ssh key, and the IP address of the node. 12

16 For a single controller node: # knife bootstrap -E <environmentname> -i.ssh/id_rsa_private \ --sudo -x <sshusername> <nodeipaddress> 4. After you have completed the bootstrap process on each node, you must add the IP address and host name of the Chef server to the /etc/hosts file on each node. Log into the first client node and open /etc/hosts with your preferred text editor. 5. Add a line with the Chef server's IP address and host name in the following format: <chefserveripaddress> <chefserverhostname> 6. Save the file. 7. Repeat steps 5-6 for each node in the environment Adding a controller node The controller node must be installed before any compute nodes are added. Until the controller node chef-client run is complete, the endpoint information will not be pushed back to the Chef server, and the Compute nodes will be unable to locate or connect to infrastructure services. A device with the ha-controller1 role assigned will include all core OpenStack services and should be used even in non-ha environments. For more information about HA, see Controller Node High Availability. Before you begin this procedure, please ensure you are logged in to the Chef server, and have installed chef-client on the device, as described in Section 3.3.4, Installing Chef client [12]. Procedure 3.4. To install a single controller node 1. Add the ha-controller1 role to the target node's run list. # knife node run_list add <devicehostname> 'role[ha-controller1]' 2. Log in to the target node via ssh. 3. Run chef-client on the node. It will take chef-client several minutes to complete the installation tasks. Chef client will provide output to help you monitor the progress of the installation Adding a Compute node The Compute nodes can be installed after the Controller node installation is complete. 13

17 Procedure 3.5. To install a single Compute node 1. Add the single-compute role to the target node's run list. # knife node run_list add <devicehostname> 'role[single-compute]' 2. Log in to the target node via ssh. 3. Run chef-client on the node. It will take chef-client several minutes to complete the installation tasks. Chef client will provide output to help you monitor the progress of the installation. Repeat this process on each Compute node. You will also need to run chef-client on each existing Compute node when additional Compute nodes are added Controller node high availability By creating two controller nodes in the environment and applying the ha-controller roles to them, you can create a pair of controller nodes that provide HA with VRRP and monitored by keepalived. Each service has a VIP of its own, and failover occurs on a service-by-service basis. Refer to High Availability Concepts for more information about High Availability configuration. Before you configure HA in your environment, you must allocate IP addresses for the MySQL, RabbitMQ, and haproxy VIPs on an interface available to both controller nodes. You will then add the VIPs to the override attributes. Note If you are upgrading your environment from an older configuration in which VIP virtual router ID (vrid) and networks were not defined, you will have to remove the keepalived configurations in /etc/keepalived/conf.d/* and run chef-client before adding the VIP vrid and network definitions to override_attributes Havana VIP attribute blocks These attribute blocks define which VIPs are associated with which service, and they also define the vrid and network for each VIP. The neutron-api VIP only needs to be specified if you are deploying OpenStack Networking. 14

18 The following example shows the attributes for a.2.2 (Havana) VIP configuration where the RabbitMQ VIP is , the HAProxy VIP is , and the MySQL VIP is : "override_attributes": { "vips": { "rabbitmq-queue": " ", "ceilometer-api": " ", "ceilometer-central-agent": " ", "cinder-api": " ", "glance-api": " ", "glance-registry": " ", "heat-api": " ", "heat-api-cfn": " ", "heat-api-cloudwatch": " ", "horizon-dash": " ", "horizon-dash_ssl": " ", "keystone-admin-api": " ", "keystone-internal-api": " ", "keystone-service-api": " ", "nova-api": " ", "nova-api-metadata": " ", "nova-ec2-public": " ", "nova-novnc-proxy": " ", "nova-xvpvnc-proxy": " ", "swift-proxy": " ", "neutron-api": " ", "mysql-db": " ", "config": { " ": { "vrid": 1, "network": "public", " ": { "vrid": 2, "network": "public", " ": { "vrid": 3, "network": "public" Grizzly VIP attribute blocks These attribute blocks define which VIPs are associated with which service, and they also define the virtual router ID (vrid) and network for each VIP. The quantum-api VIP only needs to be specified if you are deploying OpenStack Networking. 15

19 The following example shows the attributes for a.1.n (Grizzly) VIP configuration where the RabbitMQ VIP is , the HAProxy VIP is , and the MySQL VIP is : "override_attributes": { "vips": { "rabbitmq-queue": " ", "cinder-api": " ", "glance-api": " ", "glance-registry": " ", "horizon-dash": " ", "horizon-dash_ssl": " ", "keystone-admin-api": " ", "keystone-internal-api": " ", "keystone-service-api": " ", "nova-api": " ", "nova-ec2-public": " ", "nova-novnc-proxy": " ", "nova-xvpvnc-proxy": " ", "swift-proxy": " ", "quantum-api": " ", "mysql-db": " ", "config": { " ": { "vrid": 1, "network": "public", " ": { "vrid": 2, "network": "public", " ": { "vrid": 3, "network": "public" Installing a pair of High Availability Controller nodes Follow this procedure to edit your environment file and apply the HA controller roles to your controller nodes. Procedure 3.6. To install a pair of High Availability controller nodes 1. Open the environment file for editing. # knife environment edit <yourenvironmentname> 2. Locate the override_attributes section. 16

20 3. Add the VIP information to the override_attributes. If you are deploying a.2.2 Havana environment, refer to Havana VIP attributes. If you are deploying a.1.n Grizzly environment, refer to Grizzly VIP attributes. 4. On the first controller node, add the ha-controller1 role. # knife node run_list add <devicehostname> 'role[ha-controller1]' 5. On the second controller node, add the ha-controller2 role. # knife node run_list add <devicehostname> 'role[ha-controller2]' 6. Run chef-client on the first controller node. 7. Run chef-client on the second controller node. 8. Run chef-client on the first controller node again Troubleshooting the installation If the installation is unsuccessful, it can be a result of one of the following issues: The node does not have access to the internet. The installation process requires internet access to download installation files. Ensure that the address for the nodes provides access, and that the proxy information entered is correct. You should also ensure that the nodes have access to a DNS server. Your network firewall is preventing internet access. Ensure the IP address that you assign to the Controller is available through the network firewall. For more troubleshooting information and user discussion, you can also inquire at the Rackspace Private Cloud Support Forum at the following URL: 17

21 4. Integration with OpenStack Rackspace Private Cloud.2.2 offers full OpenStack Metering (Ceilometer) support, including access to OpenStack statistics through the Horizon dashboard OpenStack metering The Rackspace Private Cloud Metering implementation is based on a MySQL framework and uses SQL Alchemy. For more information about the parameters involved in this implementation, refer to the OpenStack documentation on Metering configuration options. For a list of database backends and what they support, refer to the OpenStack documentation on choosing a database backend for metering. Procedure 4.1. Using OpenStack metering 1. Metering statistics are available through the Horizon dashboard. When you log in to the dashboard as the admin user, click on the Resource Usage tab to view the statistics. 2. The following information is available: Global Disk Usage: Provides an average of the last 30 days of disk usage, broken down by tenant/project. Global Network Traffic Usage: Provides an average of the last 30 days of network traffic usage, broken down by tenant/project. Statistics: Provides a graphic represenation of all resources. You can view the usage for individual services, over a range of periods from the last day up to the last year. For more information about Metering, refer to the Ceilometer developer documentation, maintained by OpenStack OpenStack Orchestration Rackspace Private Cloud.2.2 offers a technology preview of OpenStack Orchestration (Heat) implementation, which enables you to manage infrastructure and applications within OpenStack clouds. Note Rackspace Private Cloud Support does not currently support technology preview features. They are not recommended for Rackspace Private Cloud production environments, and are included for experienced OpenStack users only. OpenStack Orchestration is a service that orchestrates cloud applications onto cloud resources using the OpenStack Heat Orchestration Syntax (HOT) template format through an OpenStack ReST API. OpenStack Orchestration also provides compatibility with the AWS CloudFormation template format. More information about Orchestration is available on the OpenStack wiki at 18

22 The Rackspace Private Cloud implementation of Orchestration includes the following components: The standard Heat API The heat-api-cfn API The CloudWatch API, which enables metric collection Installing Orchestration OpenStack Orchestration is not included in the default controller and all-in-one installations, but you can add Orchestration to your private cloud at any time by applying the heat-all role to your controller node. Procedure 4.2. To install OpenStack Orchestration 1. Log into the Chef server or a device that has knife access on the Chef server. 2. Add the heat-all role to the controller node's run list. # knife node run_list add <devicehostname> 'role[heat-all]' 3. Log on to the controller node via ssh. 4. Run chef-client on the controller node. It will take chef-client several minutes to complete the installation tasks. Chef client will provide output to help you monitor the progress of the installation Using Orchestration OpenStack Orchestration is accessible through the Horizon dashboard and through the command line interface. Generally, Orchestration interaction through the command line interface provides improved error handling and user interaction. Refer to the Heat commands chapter of the OpenStack End User for documentation of the heat client. The Orchestration page is accessed through the Project tab of the navigation bar. A repository of templates is maintained at enabling you to develop your own for your environment. When a template is launched, it will create a stack of one or more instances, which can be configured to run applications. Follow this procedure to launch a stack from a URL, a template file, or by entering template information directly through the Horizon dashboard. Procedure 4.3. To launch OpenStack Orchestration 1. On the Orchestration page, click the Launch Stack button in the upper right corner of the screen. The Select Template dialog opens. 19

23 2. Select the Template Source and enter the source information: URL: Enter the URL where the template is located. File: Browse to the location of the template file on your workstation. Direct Input: Enter the template code in the Template Data field. 3. You are prompted to enter information that the template requires to launch the stack. The exact information will vary depending on the template. 4. Click Launch Template. When the stack is complete, it will appear in the Stacks list. Any instances that have been created by the template will appear on the Instances page. Click on a stack name to view the following information: A network topology diagram. Resources in a healthy state are displayed in green, and those experiencing issues are displayed in red. Detailed information about the stack and its parameters. A list of resources being used by the stack, as well as detailed information about the resources. Events that have taken place in the stack, such as server creation. 20

24 5. Storage The Glance cookbook used for Rackspace Private Cloud supports OpenStack Image storage in the local file system, in OpenStack Object Storage (Swift), and in Rackspace Cloud Files. Note If you change the image storage location from Swift to Cloud Files (or vice versa), you must manually export and import the images Local File Storage By default, OpenStack Image stores the image files locally on the controller node, and as long as you're using local file storage, you will not have to make any changes to your configuration. In the event that you need to switch from a different storage method to the local file system, follow these steps. Procedure 5.1. To configure local image storage 1. Log into the controller node with root access and open your preferred text editor and use knife to open the environment file for editing. Add this line: # knife environment edit <environmentfile> 2. Add the following attributes to the environment. "glance": { "api": { "default_store": "file", "images": [ "cirros" ], "image_upload": true 3. Run chef-client to commit the change. # chef-client 21

25 5.2. Rackspace cloud files To use Rackspace Cloud Files for image storage, you must have an account. To sign up, visit the Rackspace Cloud Files website. Procedure 5.2. To configure Rackspace Cloud Files image storage 1. Log into the controller node with root access and use the following command to obtain your Cloud Files tenant ID: # curl -s -X POST \ -d '{"auth": {"passwordcredentials": {"<cloudfilesusername>": "", \ "password": "<cloudfilespassword>"' \ -H "Content-type: application/json" python -mjson.tool \ grep "tenantid.*mosso" head -1 The output of this command is displayed on the screen. Copy and save the tenant ID. 2. Open your preferred text editor and use knife to open the environment file for editing. Add this line: # knife environment edit <environmentfile> 3. Add the following attributes to the environment, using the tenant ID that you obtained in Step 2 and your Cloud Files username and password. "glance": { "api": { "default_store": "swift", "swift_store_user": "<cloudfilestenant_id:<cloudfilesusername>", "swift_store_key": "<cloudfilespassword>", "swift_store_auth_version": "2", "swift_store_auth_address": " v2.0", "images": [ "cirros" ], "image_upload": true, 4. Run chef-client to commit the change. # chef-client 22

26 5.3. Swift storage To use Swift storage, you must have a Swift cluster configured in your environment. For more about creating and configuring a Swift cluster, see Rackspace Private Cloud Open- Stack Object Storage Installation. Procedure 5.3. To configure Swift image storage 1. Log into the controller node with root access and open your preferred text editor and use knife to open the environment file for editing. Add this line: # knife environment edit <environmentfile> 2. Add the following attributes to the environment. "glance": { "api": { "default_store": "swift", "images": [ "cirros" ], "image_upload": true 3. Run chef-client to commit the change. # chef-client 23

27 6. Additional resources These additional resources are designed help you learn more about the Rackspace Private Cloud Software and OpenStack. If you are an advanced user and are comfortable with APIs, the OpenStack API documentation is available in the OpenStack API Documentation library. OpenStack API Quick Start Programming OpenStack Compute API OpenStack Compute Developer Rackspace Private Cloud Knowledge Center OpenStack Manuals OpenStack API Reference OpenStack - Nova Developer Documentation OpenStack - Glance Developer Documentation OpenStack - Keystone Developer Documentation OpenStack - Horizon Developer Documentation OpenStack - Cinder Developer Documentation 6.1. Document Change History This version replaces and obsoletes all previous versions. The most recent set of changes are listed in the following table: Revision Date September 25, 2014 August 28, 2014 Summary of Changes Rackspace Private Cloud v9 Software General Availability release Rackspace Private Cloud v9 Software Limited Availability release 24