diff --git a/doc/src/docbkx/basic-install/src/basic-install_architecture.xml b/doc/src/docbkx/basic-install/src/basic-install_architecture.xml index c82cf05900b..e4a96399111 100644 --- a/doc/src/docbkx/basic-install/src/basic-install_architecture.xml +++ b/doc/src/docbkx/basic-install/src/basic-install_architecture.xml @@ -19,11 +19,10 @@ of the cloud except actually hosting virtual machines or providing network services. See the "Compute Node" and "Network Controller" for details about those - roles. This server will host the OpenStack Image - Service, the OpenStack Block Storage Service, the - OpenStack Identity Service, and the OpenStack - Dashboard. It will also run portions of the OpenStack - Compute service such as the API server, the scheduler, + roles. This server hosts the OpenStack Image + Service, Block Storage Service, Identity Service, and the + dashboard. It also runs portions of the OpenStack + Compute service, such as the API server, the scheduler, conductor, console authenticator, and VNC service. Finally, it hosts the API endpoint for the OpenStack Network service. @@ -41,7 +40,7 @@ Network service agent (in this case, the Open vSwitch plugin agent). This server also manages an OpenStack-compatible hypervisor such as KVM or Xen. - This server will host the actual virtual machines + This server hosts the actual virtual machines (instances). @@ -56,8 +55,7 @@ Network setup can have up to four distinct physical data center networks. Note that these networks can be combined and re-used. For example, the Management, Data, and API networks - are commonly the same network. For simplicity, this will be - done in this guide. + are commonly the same network. For simplicity, this guide shows this configuration. Management diff --git a/doc/src/docbkx/basic-install/src/basic-install_compute-common.xml b/doc/src/docbkx/basic-install/src/basic-install_compute-common.xml index 54b18bcca9b..14728b2fe2b 100644 --- a/doc/src/docbkx/basic-install/src/basic-install_compute-common.xml +++ b/doc/src/docbkx/basic-install/src/basic-install_compute-common.xml @@ -21,7 +21,7 @@ Packages: OpenSSH-Server - Once installation has finished, the server will reboot. + Once installation has finished, the server reboots. Since the default OpenStack release in Ubuntu 12.04 LTS is older, @@ -40,8 +40,8 @@ Configure the network: - This will change later on in the guide - when Open vSwitch is configured + Later in this guide, this changes + when Open vSwitch is configured. diff --git a/doc/src/docbkx/basic-install/src/basic-install_compute-intro.xml b/doc/src/docbkx/basic-install/src/basic-install_compute-intro.xml index 05f5aaecc76..8f02b35dc08 100644 --- a/doc/src/docbkx/basic-install/src/basic-install_compute-intro.xml +++ b/doc/src/docbkx/basic-install/src/basic-install_compute-intro.xml @@ -4,7 +4,7 @@ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="basic-install_compute-intro"> Introduction - The Compute node will provide : + The Compute node provides: Hypervisor (KVM) diff --git a/doc/src/docbkx/basic-install/src/basic-install_controller-common.xml b/doc/src/docbkx/basic-install/src/basic-install_controller-common.xml index 4281a48d81a..428a4b6f906 100644 --- a/doc/src/docbkx/basic-install/src/basic-install_controller-common.xml +++ b/doc/src/docbkx/basic-install/src/basic-install_controller-common.xml @@ -33,7 +33,7 @@ - Once installation has finished, the server will reboot. + Once installation has finished, the server reboots. @@ -163,8 +163,8 @@ ONBOOT=yes - Install NTP. NTP will ensure that the server has the correct time. This is important because if an OpenStack server's time is - not correct, it will be removed from the rest of the cloud. + Install NTP. NTP ensures that the server has the correct time. This is important because if an OpenStack server's time is + not correct, it is removed from the rest of the cloud. # apt-get install ntp @@ -187,14 +187,14 @@ ONBOOT=yes Install the packages: # apt-get install python-mysqldb mysql-server # yum install mysql mysql-server MySQL-python - apt-get will - prompt you to set the MySQL root + apt-get + prompts you to set the MySQL root password. - By default, MySQL will only accept + By default, MySQL only accepts connections from localhost. This needs changed so that the compute nodes can access the OpenStack Networking service. Database diff --git a/doc/src/docbkx/basic-install/src/basic-install_controller-glance.xml b/doc/src/docbkx/basic-install/src/basic-install_controller-glance.xml index 85ac5ec7cdd..d0a84f4af8f 100644 --- a/doc/src/docbkx/basic-install/src/basic-install_controller-glance.xml +++ b/doc/src/docbkx/basic-install/src/basic-install_controller-glance.xml @@ -5,8 +5,8 @@ xml:id="basic-install_controller-glance"> OpenStack Image Service The Image Service provides the cloud environment with a catalog of virtual machine "templates". These templates are used as the basis - of instances. For example, if the catalog contains an image for an Ubuntu 12.04 distribution, the users of the cloud will be able - to launch Ubuntu 12.04 instances. + of instances. For example, if the catalog contains an image for an Ubuntu 12.04 distribution, cloud users can + launch Ubuntu 12.04 instances. Install the Glance packages: diff --git a/doc/src/docbkx/basic-install/src/basic-install_controller-intro.xml b/doc/src/docbkx/basic-install/src/basic-install_controller-intro.xml index 3751b36662c..57bd63b62c3 100644 --- a/doc/src/docbkx/basic-install/src/basic-install_controller-intro.xml +++ b/doc/src/docbkx/basic-install/src/basic-install_controller-intro.xml @@ -4,7 +4,7 @@ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="basic-install_controller-intro"> Introduction - The Controller node will provide : + The Controller node provides: Databases (with MySQL) diff --git a/doc/src/docbkx/basic-install/src/basic-install_controller-keystone.xml b/doc/src/docbkx/basic-install/src/basic-install_controller-keystone.xml index db128138221..898238f434a 100644 --- a/doc/src/docbkx/basic-install/src/basic-install_controller-keystone.xml +++ b/doc/src/docbkx/basic-install/src/basic-install_controller-keystone.xml @@ -46,7 +46,7 @@ connection = mysql://keystone:password@localhost/keystone Create a file called ~/openrc. This - file contains the OpenStack admin credentials that will be used when interacting with the OpenStack + file contains the OpenStack admin credentials that are used when interacting with the OpenStack environment on the command line. export OS_TENANT_NAME=admin export OS_USERNAME=admin @@ -70,7 +70,7 @@ export SERVICE_TOKEN=password - The following bash script will populate Keystone with some initial data: + The following bash script populates Keystone with some initial data: Projects: admin and services Roles: admin, Member diff --git a/doc/src/docbkx/basic-install/src/basic-install_controller-nova.xml b/doc/src/docbkx/basic-install/src/basic-install_controller-nova.xml index 0a642718e4a..53590fbab2a 100644 --- a/doc/src/docbkx/basic-install/src/basic-install_controller-nova.xml +++ b/doc/src/docbkx/basic-install/src/basic-install_controller-nova.xml @@ -41,7 +41,7 @@ auth_version = v2.0 Add the following to the /etc/nova/nova.conf file. This file is the main configuration file of Nova. There is a large amount of configuration options that can go in this file. This guide illustrates the minimum needed for a simple environment. - Note that the nova.conf file supplied by your distribution will have some options already set. Leave + Note that the nova.conf file supplied by your distribution has some options already set. Leave them as-is. [DEFAULT] diff --git a/doc/src/docbkx/basic-install/src/basic-install_controller-quantum.xml b/doc/src/docbkx/basic-install/src/basic-install_controller-quantum.xml index aeae534d25b..336a8e09511 100644 --- a/doc/src/docbkx/basic-install/src/basic-install_controller-quantum.xml +++ b/doc/src/docbkx/basic-install/src/basic-install_controller-quantum.xml @@ -58,7 +58,7 @@ firewall_driver = quantum.agent.linux.iptables_firewall.OVSHybridIptablesFirewal tunnel mode since you don't have to configure your physical switches for VLANs. - The Fedora kernel module for OpenVSwitch has been compiled without support for tunnels. To use gre tunnels the module will have to be recompiled. + The Fedora kernel module for OpenVSwitch has been compiled without support for tunnels. To use gre tunnels, the module must be recompiled. diff --git a/doc/src/docbkx/basic-install/src/basic-install_intro.xml b/doc/src/docbkx/basic-install/src/basic-install_intro.xml index 5097e9c4b13..2190154bffa 100644 --- a/doc/src/docbkx/basic-install/src/basic-install_intro.xml +++ b/doc/src/docbkx/basic-install/src/basic-install_intro.xml @@ -25,8 +25,7 @@ The OpenStack configuration files contain several commented options. These options specify the default setting. You only need to uncomment these lines if you are changing the setting - to a non-default value. Additionally, the only options that - will be shown throughout this guide are options that are being + to a non-default value. Additionally, this guide only shows options that are being modified from their default value. Finally, please be aware that the use of password as a password throughout this guide is for simplicity and diff --git a/doc/src/docbkx/basic-install/src/basic-install_network-common.xml b/doc/src/docbkx/basic-install/src/basic-install_network-common.xml index 829118ca71c..f7b2a602cb8 100644 --- a/doc/src/docbkx/basic-install/src/basic-install_network-common.xml +++ b/doc/src/docbkx/basic-install/src/basic-install_network-common.xml @@ -20,7 +20,7 @@ Packages: OpenSSH-Server - Once installation has finished, the server will reboot. + Once installation has finished, the server reboots. Since the default OpenStack release @@ -44,8 +44,7 @@ Edit /etc/network/interfaces: - This will change later on in - the guide when Open vSwitch is + Later in this guide, this changes when Open vSwitch is configured. # Internal Network diff --git a/doc/src/docbkx/basic-install/src/basic-install_network-intro.xml b/doc/src/docbkx/basic-install/src/basic-install_network-intro.xml index ce8a9620c0a..b9511447b15 100644 --- a/doc/src/docbkx/basic-install/src/basic-install_network-intro.xml +++ b/doc/src/docbkx/basic-install/src/basic-install_network-intro.xml @@ -4,7 +4,7 @@ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="basic-install_network-intro"> Introduction - The Network node will provide: + The Network node provides: Virtual Bridging (Open-vSwitch + Quantum Agent) with tunneling diff --git a/doc/src/docbkx/basic-install/src/basic-install_network-operating.xml b/doc/src/docbkx/basic-install/src/basic-install_network-operating.xml index 84ed82e1817..719c7a278ce 100644 --- a/doc/src/docbkx/basic-install/src/basic-install_network-operating.xml +++ b/doc/src/docbkx/basic-install/src/basic-install_network-operating.xml @@ -14,7 +14,7 @@ Create a file called ~/openrc. This - file contains the OpenStack admin credentials that will be used when interacting with the OpenStack + file contains the OpenStack admin credentials that are used when interacting with the OpenStack environment on the command line. export OS_TENANT_NAME=admin export OS_USERNAME=admin @@ -38,7 +38,7 @@ export SERVICE_TOKEN=password - The following bash script will create an internal network for the "demo" project. + The following bash script creates an internal network for the "demo" project. #!/bin/bash TENANT_NAME="demo" TENANT_NETWORK_NAME="demo-net" @@ -58,11 +58,11 @@ quantum router-interface-add $ROUTER_ID $TENANT_SUBNET_ID L3 Configuration The Quantum L3 service enables instances to have external network access. If this service is not configured, your instances - will only be able to communicate with each other. Please note that this configuration is highly dependant on your environment. - For example, make note of the subnet-create command below. You will need to verify your own network settings + can only communicate with each other. Note that this configuration is highly dependant on your environment. + For example, make note of the subnet-create command below. You must verify your own network settings for the external subnet (10.0.0.0/24 in this case) as well as an allocation pool. The allocation pool is used to provide each Project with an IP address to access the external network. The pool consists of 50 IPs and therefore - only 50 projects will be able to get a gateway IP. + only 50 projects can get a gateway IP. Create an external network: diff --git a/doc/src/docbkx/cli-guide/pom.xml b/doc/src/docbkx/cli-guide/pom.xml index dbfd40544d2..cc3cdcb2433 100644 --- a/doc/src/docbkx/cli-guide/pom.xml +++ b/doc/src/docbkx/cli-guide/pom.xml @@ -53,7 +53,7 @@ cli-guide 0 - cli-guide.pdf + cli-guide diff --git a/doc/src/docbkx/common/about-dashboard.xml b/doc/src/docbkx/common/about-dashboard.xml index c0b70debe77..c962abf8a74 100644 --- a/doc/src/docbkx/common/about-dashboard.xml +++ b/doc/src/docbkx/common/about-dashboard.xml @@ -2,22 +2,57 @@
- About the Dashboard - - The OpenStack dashboard, also known as horizon, is a Web interface that allows cloud - administrators and users to manage various OpenStack resources - and services. The dashboard enables web-based interactions - with the OpenStack Compute cloud controller through the - OpenStack APIs. The following instructions show you an example - deployment that is configured with an Apache web server. - - - - - - - -
+ xml:id="about-dashboard"> + About the OpenStack dashboard + To install the OpenStack dashboard, complete the + following high-level steps: + + + Meet the system requirements for accessing the + dashboard. See . + + + Install the OpenStack Dashboard framework, + including Apache and related modules. See . + + + Configure the dashboard. + Then, restart and run the Apache server. + See . + + + Verify your installation. See . + + + + Next steps: + After you install the dashboard, you can complete the following tasks: + + + To customize your dashboard, see . + + + + To set up session storage for the dashboard, + see . + + + To deploy the + dashboard, see Deploying Horizon. + + + To launch instances with the dashboard, see the + OpenStack User Guide. + + + diff --git a/doc/src/docbkx/common/ch_installdashboard.xml b/doc/src/docbkx/common/ch_installdashboard.xml index 13dbc7a26b7..b9263553d59 100644 --- a/doc/src/docbkx/common/ch_installdashboard.xml +++ b/doc/src/docbkx/common/ch_installdashboard.xml @@ -1,51 +1,69 @@ - Installing the OpenStack Dashboard - OpenStack has components that provide a view of the - OpenStack installation such as a Django-built website that - serves as a dashboard. - You can use a dashboard interface with an OpenStack - Compute installation with a web-based console provided by - the Openstack-Dashboard project. It provides web-based - interactions with the OpenStack Compute cloud controller - through the OpenStack APIs. For more information about the - Openstack-Dashboard project, please visit: https://github.com/openstack/horizon/. These - instructions are for an example deployment configured with - an Apache web server. -
Dashboard Installation Task Flow - To install the OpenStack Dashboard, complete the - following high-level steps: - + Install the OpenStack dashboard + The + OpenStack dashboard, also known as horizon, is a Web interface that allows cloud + administrators and users to manage various OpenStack resources + and services. + The dashboard enables web-based interactions with the + OpenStack Compute cloud controller through the OpenStack APIs. + The following instructions show an example deployment + configured with an Apache web server. + + After you install the dashboard, you can complete the + following tasks: + Next steps: + - Meet the system requirements for the dashboard. + To customize your dashboard, see . - Install the OpenStack Dashboard framework, - including Apache and related modules. + To set up session storage for the dashboard, see + . - Configure the dashboard. - - - Restart and run the Apache server. - - - Deploy the dashboard. See To deploy the dashboard, see Deploying Horizon. -
- - - - - - - + + To launch instances with the dashboard, see the + OpenStack User + Guide. + + + + + + + + diff --git a/doc/src/docbkx/common/compute-vnc-console.xml b/doc/src/docbkx/common/compute-vnc-console.xml index 2b2723dda00..20fe7780bac 100644 --- a/doc/src/docbkx/common/compute-vnc-console.xml +++ b/doc/src/docbkx/common/compute-vnc-console.xml @@ -245,7 +245,7 @@
Frequently asked questions about VNC access to - VMs + virtual machines diff --git a/doc/src/docbkx/common/dashboard-configure.xml b/doc/src/docbkx/common/dashboard-configure.xml index c00c5ea733c..607c631a16d 100644 --- a/doc/src/docbkx/common/dashboard-configure.xml +++ b/doc/src/docbkx/common/dashboard-configure.xml @@ -3,57 +3,69 @@ xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"> - Configure the Dashboard - You can configure the dashboard for a simple HTTP deployment or a secured HTTPS deployment. While the standard installation uses a non-encrypted - HTTP channel, you can enable SSL support for the - dashboard. -
Configure the Dashboard for HTTPTo configure the dashboard for HTTP: - - Specify the host for your OpenStack Identity Service - endpoint in the - /etc/openstack-dashboard/local_settings.py - file with the OPENSTACK_HOST - setting. - The following example shows this setting: - - The HORIZON_CONFIG dictionary - contains all the settings for the dashboard. Whether - or not a service is in the Dashboard depends on the - Service Catalog configuration in the Identity service. - For the full listing, see Horizon Settings and Configuration. -
-
Configure the Dashboard for HTTPSTo configure the dashboard for HTTPS: - The following example uses the domain, - "http://openstack.example.com." Use a domain that fits - your current setup. - - - - In/etc/openstack-dashboard/local_settings.py update - the following - directive:USE_SSL = True - - - Edit /etc/apache2/ports.conf and add the following - line: NameVirtualHost *:443 - - - - Edit /etc/apache2/conf.d/openstack-dashboard.conf: - - Before: - WSGIScriptAlias / /usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi + Configure the dashboard + + You can configure the dashboard for a simple HTTP deployment + or a secured HTTPS deployment. While the standard installation + uses a non-encrypted HTTP channel, you can enable SSL support + for the dashboard. +
+ Configure the dashboard for HTTP + + To configure the dashboard for HTTP: + + Specify the host for your OpenStack Identity + Service endpoint in the + /etc/openstack-dashboard/local_settings.py + file with the OPENSTACK_HOST + setting. + The following example shows this setting: + + The HORIZON_CONFIG dictionary + contains all the settings for the dashboard. + Whether or not a service is in the Dashboard + depends on the Service Catalog configuration in + the Identity service. For the full listing, see + Horizon Settings and + Configuration. + + +
+
+ Configure the dashboard for HTTPS + + To configure the dashboard for HTTPS: + The following example uses the domain, + "http://openstack.example.com." Use a domain that fits + your current setup. + + In/etc/openstack-dashboard/local_settings.py + update the following + directive:USE_SSL = True + + + Edit + /etc/apache2/ports.conf + and add the following line: + NameVirtualHost *:443 + + + Edit + /etc/apache2/conf.d/openstack-dashboard.conf: + + Before: + WSGIScriptAlias / /usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi WSGIDaemonProcess horizon user=www-data group=www-data processes=3 threads=10 Alias /static /usr/share/openstack-dashboard/openstack_dashboard/static/ <Directory /usr/share/openstack-dashboard/openstack_dashboard/wsgi> Order allow,deny Allow from all -</Directory> - - After: - <VirtualHost *:80> +</Directory> + + After: + <VirtualHost *:80> ServerName openstack.example.com RedirectPermanent / https://openstack.example.com </VirtualHost> @@ -73,20 +85,21 @@ Alias /static /usr/share/openstack-dashboard/openstack_dashboard/static/ Order allow,deny Allow from all </Directory> -</VirtualHost> - In this configuration, Apache listens on the port 443 - and redirects all the hits to the HTTPS protocol - for all the non-secured requests. In the secured - section, the private key, public key, and - certificate to use are defined. - - - Restart Apache and memcached: - # service apache2 restart +</VirtualHost> + In this configuration, Apache listens on the + port 443 and redirects all the hits to the HTTPS + protocol for all the non-secured requests. In the + secured section, the private key, public key, and + certificate to use are defined. + + + Restart Apache and memcached: + # service apache2 restart # service memcached restart - If you call the HTTP version of the dashboard - through your browser, you are redirected to the HTTPS - page. - -
+ If you call the HTTP version of the dashboard + through your browser, you are redirected to the + HTTPS page. + + +
diff --git a/doc/src/docbkx/common/dashboard-install.xml b/doc/src/docbkx/common/dashboard-install.xml index 956e2b80216..94cd38cc176 100644 --- a/doc/src/docbkx/common/dashboard-install.xml +++ b/doc/src/docbkx/common/dashboard-install.xml @@ -1,44 +1,119 @@ -
- Install the OpenStack Dashboard - To install the OpenStack Dashboard:Install the OpenStack Dashboard as root: - # apt-get install -y memcached libapache2-mod-wsgi openstack-dashboard - # yum install -y memcached python-memcached mod_wsgi openstack-dashboard - Modify the CACHE_BACKEND environment variable - in + Install and configure the dashboard + Before you can install and configure the dashboard, meet the + following system requirements: + + Dashboard system requirements: + + OpenStack Compute installation. The cloud operator must set up an OpenStack Compute + installation and enable the Identity Service for user + and project management. + User: Note the URLs + of the Identity Service and Compute endpoints. + + + Identity Service user with sudo privileges. Because Apache does not serve content from a root + user, the cloud operator must set up an Identity + Service user with sudo privileges. + User: Note the + credentials of this user. + + + git. Install git by + running the following command: + $ sudo apt-get install git-core + + + Python 2.6 or 2.7. The Python version must support Django. These + instructions were tested with Ubuntu 10.10. + The Python version should run on any system, + including Mac OS X. + The installation prerequisites might differ by + platform. + + + + To install the dashboard: + + Install the dashboard on the node that can contact + the Identity Service as root: + # apt-get install -y memcached libapache2-mod-wsgi openstack-dashboard + # yum install -y memcached python-memcached mod_wsgi openstack-dashboard + + + Modify the CACHE_BACKEND + environment variable in /etc/openstack-dashboard/local_settings.py/etc/openstack-dashboard/local_settings to match the ones set in /etc/memcached.conf/etc/sysconfig/memcached.conf.Open - /etc/sysconfig/memcached.conf. + Open /etc/openstack-dashboard/local_settings.py/etc/openstack-dashboard/local_settings - and look for this line: - CACHE_BACKEND = 'memcached://127.0.0.1:11211/' - The address and port must match the ones set in /etc/memcached.conf/etc/sysconfig/memcached. - If you change the memcached settings, you must restart the Apache web - server for the changes to take effect. - In this example, memcached is the session store for the OpenStack Dashboard. You can use other options. Each -option has benefits and drawbacks. You can use any available session back-end by setting the SESSION_ENGINE option. - - - To change the timezone, use the dashboard or edit - the /etc/openstack-dashboard/local_settings/etc/openstack-dashboard/local_settings.py - file. - Change the following parameter: - TIME_ZONE = "UTC" - - - + and look for this line: CACHE_BACKEND = + 'memcached://127.0.0.1:11211/' + + Notes + + + The address and port must match the ones + set in /etc/memcached.conf/etc/sysconfig/memcached. + If you change the memcached settings, + you must restart the Apache web server for + the changes to take effect. + + + You can use options other than memcached + option for session storage. Set the + session back-end through the + SESSION_ENGINE + option. + + + To change the timezone, use the + dashboard or edit the /etc/openstack-dashboard/local_settings/etc/openstack-dashboard/local_settings.py + file. + Change the following parameter: + TIME_ZONE = "UTC" + + + + + + + + Make sure that the web browser on your local machine + supports HTML5. + Enable cookies and JavaScript. + + To use the VNC client with the dashboard, the + browser must support HTML5 Canvas and HTML5 + WebSockets. + For details about browsers that support noVNC, + see https://github.com/kanaka/noVNC/blob/master/README.md, + and https://github.com/kanaka/noVNC/wiki/Browser-support, + respectively. + + +
diff --git a/doc/src/docbkx/common/dashboard-system-reqs.xml b/doc/src/docbkx/common/dashboard-system-reqs.xml index 00bcaf82c99..fa96d16c762 100644 --- a/doc/src/docbkx/common/dashboard-system-reqs.xml +++ b/doc/src/docbkx/common/dashboard-system-reqs.xml @@ -4,66 +4,87 @@ xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"> System requirements - You must meet the following system requirements to access - the OpenStack dashboard: - - The cloud operator has set up an OpenStack Compute - installation with the Identity - Service enabled for identity management. Note the - URLs of your Identity Service and Compute - endpoints. - - - - The cloud operator has set up an Identity Service user with sudo - privileges. Because Apache does not - serve content from a root user, you must run the - dashboard as an Identity Service user with sudo - privileges. Note the credentials of this user. - - - You have a recent Web browser - that supports HTML5 and has cookies and - JavaScript enabled. - To use the dashboard's VNC client, which is based on - noVNC, your browser must support HTML5 Canvas and - HTML5 WebSockets. - For more details and a list of browsers that support - noVNC, see - https://github.com/kanaka/noVNC/blob/master/README.md, - and - https://github.com/kanaka/noVNC/wiki/Browser-support, - respectively. - Install the OpenStack - dashboard on the node that can contact - the Identity Service. - - - Install git by - running the following - command:$ sudo apt-get install git-core - - - Install Python 2.6 or 2.7 - . Your version of Python must be capable of - running Django. These instructions have been tested - with Ubuntu 10.10. - The version of Python that you use should run on any - system, including Mac OS X. The installation - prerequisites might differ by platform. - - - - The following components are optional: - - - Image store (Glance) - endpoint - Object store (Swift) - endpoint - Networking (Quantum) endpoint - + Meet the following system requirements to access the + OpenStack dashboard: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Dashboard system requirements
RequirementWho?Description
OpenStack Compute installationCloud operator + Set up an OpenStack Compute installation. + Enable the Identity Service for user and + project management. + User: Note + the URLs of the Identity Service and Compute + endpoints. +
Identity Service user with sudo privilegesCloud operatorBecause Apache does not serve content from a + root user, you must run the dashboard as an + Identity Service user with sudo privileges. + User: Note + the credentials of this user.
OpenStack dashboardCloud operatorInstall the dashboard on the node that can + contact the Identity Service.
gitCloud operatorInstall git + by running the following + command:$ sudo apt-get install git-core
Python 2.6 or 2.7Cloud operator + The Python version must support Django. + These instructions have been tested with + Ubuntu 10.10. + The Python version should run on any system, + including Mac OS X. + The installation prerequisites might differ + by platform. +
Web browser that supports HTML5User + Install a web browser on your local machine + that supports HTML5. + Enable cookies and JavaScript. + + To use the VNC client with the + dashboard, the browser must support HTML5 + Canvas and HTML5 WebSockets. + For details about browsers that support + noVNC, see https://github.com/kanaka/noVNC/blob/master/README.md, + and https://github.com/kanaka/noVNC/wiki/Browser-support, + respectively. + +
diff --git a/doc/src/docbkx/common/dashboard-verify.xml b/doc/src/docbkx/common/dashboard-verify.xml index 2c15b9faccb..0c629f52438 100644 --- a/doc/src/docbkx/common/dashboard-verify.xml +++ b/doc/src/docbkx/common/dashboard-verify.xml @@ -1,18 +1,24 @@ -
- Validate the Dashboard Installation - To validate the dashboard installation:Point your browser to http://192.168.206.130.After you connect to the dashboard through the URL, a login - window appears. Enter the credentials for any user - that you created with the OpenStack Identity Service. + Verify the installation + + To verify the dashboard installation: + + Point your browser to the public IP address for your + instance: For example: + http://192.168.206.130 + + + After you connect to the dashboard through the URL, + a login page appears. + Enter the credentials for any user that you created + with the OpenStack Identity Service. For example, enter admin for the username and secrete as the - password: - - - - -
+ password. + + + diff --git a/doc/src/docbkx/common/dashboard_customizing.xml b/doc/src/docbkx/common/dashboard_customizing.xml index fd693174a91..fc2af0b4e95 100644 --- a/doc/src/docbkx/common/dashboard_customizing.xml +++ b/doc/src/docbkx/common/dashboard_customizing.xml @@ -1,22 +1,22 @@ +
-Custom Brand the Dashboard - Adapted from a blog post by Preston Lee. -When you deploy OpenStack - on Ubuntu Server 12.04, you can have the - openstack-dashboard package installed to provide the web-based “Horizon” - GUI component. Canonical also provides an - openstack-dashboard-ubuntu-theme package that brands the Python-based Django GUI. - -The Horizon documents briefly mention branding - customization to provide a head start. The - following example shows a custom-branded Horizon dashboard - with custom colors, logo, and site title: + xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"> + Customize the dashboard + Adapted from How To Custom Brand The OpenStack “Horizon” + Dashboard. + You install the OpenStack dashboard through the + openstack-dashboard package. You can + customize the dashboard with your own colors, logo, and site + title through a CSS file. + Canonical also provides an + openstack-dashboard-ubuntu-theme + package that brands the Python-based Django interface. + The following example shows a customized dashboard with + custom colors, logo, and site title: - - - - - - - -To customize the dashboard: - - Create a graphical logo with a transparent background. The text “TGen Cloud” - in this example is actually rendered via .png files of multiple sizes created with - a graphics program. Use a 200×27 for the logged-in banner graphic, and 365×50 for - the login screen graphic. - Set the HTML title (shown at the top of the browser window) by adding the - following line to /etc/openstack-dashboard/local_settings.py: SITE_BRANDING = "Example, Inc. Cloud" - - Upload your new graphic files to: - /usr/share/openstack-dashboard/openstack_dashboard/static/dashboard/img/ - - Create a new CSS style sheet — we’ll call ours custom.css — in the directory: - /usr/share/openstack-dashboard/openstack_dashboard/static/dashboard/css/ - - Edit your CSS file using the - following as a starting point for customization, which simply overrides the Ubuntu - customizations made in the ubuntu.css file. - Change the colors and image file names as appropriate, though the relative directory paths should be the same. - /* + + + + + + + + + To customize the dashboard: + + Create a graphical logo with a transparent + background. The text TGen Cloud in + this example is rendered through + .png files of multiple sizes + created with a graphics program. + Use a 200×27 for the logged-in banner graphic, and + 365×50 for the login screen graphic. + + + Set the HTML title, which appears at the top of the + browser window, by adding the following line to + /etc/openstack-dashboard/local_settings.py: + SITE_BRANDING = "Example, Inc. + Cloud" + + + Upload your new graphic files to the following + location: + /usr/share/openstack-dashboard/openstack_dashboard/static/dashboard/img/ + + + Create a CSS style sheet in the following directory: + /usr/share/openstack-dashboard/openstack_dashboard/static/dashboard/css/ + + + Edit your CSS file to override the Ubuntu + customizations in the ubuntu.css + file. + Change the colors and image file names as + appropriate, though the relative directory paths + should be the same. The following example file shows + you how to customize your CSS + file:/* * New theme colors for dashboard that override the defaults: * dark blue: #355796 / rgb(53, 87, 150) * light blue: #BAD3E1 / rgb(186, 211, 225) @@ -92,19 +108,30 @@ border: none; box-shadow: none; background-color: #BAD3E1 !important; text-decoration: none; -} - Open the following HTML template in an editor: - /usr/share/openstack-dashboard/openstack_dashboard/templates/_stylesheets.html - Add a line to include your new style sheet pointing to - custom.css: (I’ve highlighted the new line in - bold.) - ... +} + + + Open the following HTML template in an editor: + /usr/share/openstack-dashboard/openstack_dashboard/templates/_stylesheets.html + + + Add a line to include your + custom.css file: + ... <link href='{{ STATIC_URL }}bootstrap/css/bootstrap.min.css' media='screen' rel='stylesheet' /> <link href='{{ STATIC_URL }}dashboard/css/{% choose_css %}' media='screen' rel='stylesheet' /> <link href='{{ STATIC_URL }}dashboard/css/custom.css' media='screen' rel='stylesheet' /> - ... - Restart apache just for good measure: sudo service apache2 restartsudo service httpd restart + ... + + + Restart apache: + sudo service apache2 restart + sudo service httpd restart + + + Reload the dashboard in your browser to view your + changes. + Modify your CSS file as appropriate. - Reload the dashboard in your browser and fine tune your CSS appropriate. - +
diff --git a/doc/src/docbkx/common/dashboard_sessions.xml b/doc/src/docbkx/common/dashboard_sessions.xml index 84b2fbad094..1a8b19015d8 100644 --- a/doc/src/docbkx/common/dashboard_sessions.xml +++ b/doc/src/docbkx/common/dashboard_sessions.xml @@ -1,90 +1,113 @@ +
-Set up Dashboard Session Storage -The dashboard uses + Set up session storage for the dashboard + The dashboard uses Django’s sessions framework to handle user session - data. However, you can use any available session back-end. You - customize the session back-end through the + data. However, you can use any available session backend. You + customize the session backend through the SESSION_ENGINE setting in your /etc/openstack-dashboard/local_settings local_settings.py file. The following sections describe the pros and cons of each - option as it pertains to deploying the dashboard. -
-Local Memory Cache - Local memory storage is the quickest and easiest session + option as it pertains to deploying the dashboard. +
+ Local memory cache + Local memory storage is the quickest and easiest session backend to set up, as it has no external dependencies whatsoever. It has the following significant drawbacks: - - No shared storage across processes or workers. - No persistence after a process terminates. - - The local memory backend is enabled as the default for Horizon - solely because it has no dependencies. It is not recommended for - production use, or even for serious development work. Enabled by: - SESSION_ENGINE = 'django.contrib.sessions.backends.cache' + + + No shared storage across processes or + workers. + + + No persistence after a process + terminates. + + + The local memory backend is enabled as the default for + Horizon solely because it has no dependencies. It is not + recommended for production use, or even for serious + development work. Enabled by: + SESSION_ENGINE = 'django.contrib.sessions.backends.cache' CACHES = { 'BACKEND': 'django.core.cache.backends.locmem.LocMemCache' } -
- -
- Memcached - External caching using an application such as memcached - offers persistence and shared storage, and can be very useful - for small-scale deployment and/or development. However, for - distributed and high-availability scenarios memcached has - inherent problems which are beyond the scope of this documentation. - Memcached is an extremely fast and efficient cache backend for - cases where it fits the deployment need, but it’s not - appropriate for all scenarios. - Requirements: - - Memcached service running and accessible. - Python memcached module installed. - -Enabled by: - SESSION_ENGINE = 'django.contrib.sessions.backends.cache' +
+
+ Memcached + External caching using an application such as memcached + offers persistence and shared storage, and can be very + useful for small-scale deployment and/or development. + However, for distributed and high-availability scenarios + memcached has inherent problems which are beyond the scope + of this documentation. + Memcached is an extremely fast and efficient cache + backend for cases where it fits the deployment need, but + it’s not appropriate for all scenarios. + Requirements: + + + Memcached service running and accessible. + + + Python memcached module installed. + + + Enabled by: + SESSION_ENGINE = 'django.contrib.sessions.backends.cache' CACHES = { 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache' 'LOCATION': 'my_memcached_host:11211', } -
-
- Database - Database-backed sessions are scalable (using an appropriate - database strategy), persistent, and can be made high-concurrency - and highly-available. - - The downside to this approach is that database-backed sessions - are one of the slower session storages, and incur a high overhead - under heavy usage. Proper configuration of your database deployment - can also be a substantial undertaking and is far beyond the scope - of this documentation. To enable, follow the below steps to - initialise the database and configure it for use - - Start the mysql command line client by running: - $ mysql -u root -p - Enter the MySQL root user's password when prompted. - To configure the MySQL database, create the dash database. - mysql> CREATE DATABASE dash; - Create a MySQL user for the newly-created dash database that - has full control of the database. - mysql> GRANT ALL ON dash.* TO 'dash'@'%' IDENTIFIED BY - 'yourpassword'; - Enter quit at the mysql> prompt to exit MySQL. - - In the /etc/openstack-dashboard/local_settings.py - /etc/openstack-dashboard/local_settings - file, change these options: - - SESSION_ENGINE = 'django.core.cache.backends.db.DatabaseCache' +
+
+ Database + Database-backed sessions are scalable, persistent, and + can be made high-concurrency and highly-available. + However, database-backed sessions are one of the slower + session storages and incur a high overhead under heavy + usage. Proper configuration of your database deployment + can also be a substantial undertaking and is far beyond + the scope of this documentation. + + To initialize and configure the database: + + Start the mysql command line client: + $ mysql -u root -p + + + Enter the MySQL root user's password when + prompted. + + + To configure the MySQL database, create the dash + database: + mysql> CREATE DATABASE dash; + + + Create a MySQL user for the newly-created dash + database that has full control of the + database: + mysql> GRANT ALL ON dash.* TO 'dash'@'%' IDENTIFIED BY 'yourpassword'; + + + Enter quit at the mysql> + prompt to exit MySQL. + + + In the /etc/openstack-dashboard/local_settings.py + /etc/openstack-dashboard/local_settings + file, change these options: + SESSION_ENGINE = 'django.core.cache.backends.db.DatabaseCache' DATABASES = { 'default': { # Database configuration here @@ -96,57 +119,74 @@ DATABASES = { 'default-character-set': 'utf8' } } - After configuring the local_settings.py - /etc/openstack-dashboard/local_settings - as shown, you can run - the manage.py syncdb command to populate this newly-created - database. - $ /usr/share/openstack-dashboard/manage.py syncdb - As a result, you should see the following at the end of what returns: - Installing custom SQL ... + + + After configuring the local_settings.py + /etc/openstack-dashboard/local_settings + as shown, you can run the manage.py + syncdb command to populate this + newly-created database. + $ /usr/share/openstack-dashboard/manage.py syncdb + As a result, the following output is + returned: + Installing custom SQL ... Installing indexes ... DEBUG:django.db.backends:(0.008) CREATE INDEX `django_session_c25c2c28` ON `django_session` (`expire_date`);; args=() No fixtures found. - If you want to avoid a warning when restarting apache2, create a blackhole directory in the dashboard directory like so: - # sudo mkdir -p /var/lib/dash/.blackhole - Restart Apache to pick up the default site and symbolic link settings. - # /etc/init.d/apache2 restart - # service httpd restart - Restart the nova-api service to ensure the API server can connect to the Dashboard and to - avoid an error displayed in the Dashboard. - sudo restart nova-api - -
-
- Cached Database - To mitigate the performance issues of database queries, you - can also consider using Django’s cached_db session backend which - utilizes both your database and caching infrastructure to perform - write-through caching and efficient retrieval. You can enable this - hybrid setting by configuring both your database and cache as - discussed above and then using: - - SESSION_ENGINE = "django.contrib.sessions.backends.cached_db" -
-
- Cookies - If you’re using Django 1.4 or later, a new session backend - is available to you which avoids server load and scaling problems: - the signed_cookies backend! - This backend stores session data in a cookie which is stored - by the user’s browser. The backend uses a cryptographic signing - technique to ensure session data is not tampered with during - transport (this is not the same as encryption, session data is still - readable by an attacker). - The pros of this session engine are that it doesn’t require - any additional dependencies or infrastructure overhead, and it - scales indefinitely as long as the quantity of session data being - stored fits into a normal cookie. - The biggest downside is that it places session data into - storage on the user’s machine and transports it over the wire. It - also limits the quantity of session data which can be stored. - For a thorough discussion of the security implications of - this session backend, please read the Django documentation on - cookie-based sessions. -
+ + + If you want to avoid a warning when you restart + apache2, create a blackhole directory in the + dashboard directory, as follows: + # sudo mkdir -p /var/lib/dash/.blackhole + + + Restart Apache to pick up the default site and + symbolic link settings: + # /etc/init.d/apache2 restart + # service httpd restart + + + Restart the nova-api service to ensure that the + API server can connect to the dashboard without + error: + # sudo restart nova-api + + +
+
+ Cached Database + To mitigate the performance issues of database queries, + you can use the Django cached_db session backend, which + utilizes both your database and caching infrastructure to + perform write-through caching and efficient retrieval. + Enable this hybrid setting by configuring both your + database and cache, as discussed previously. Then, set the + following value: + SESSION_ENGINE = "django.contrib.sessions.backends.cached_db" +
+
+ Cookies + If you use Django 1.4 or later, the signed_cookies + backend avoids server load and scaling problems. + This backend stores session data in a cookie, which is + stored by the user’s browser. The backend uses a + cryptographic signing technique to ensure session data is + not tampered with during transport. This is not the same + as encryption; session data is still readable by an + attacker. + The pros of this engine are that it requires no + additional dependencies or infrastructure overhead, and it + scales indefinitely as long as the quantity of session + data being stored fits into a normal cookie. + The biggest downside is that it places session data into + storage on the user’s machine and transports it over the + wire. It also limits the quantity of session data that can + be stored. + See the Django cookie-based sessions documentation. +
diff --git a/doc/src/docbkx/common/dashboardlaunchinginstances.xml b/doc/src/docbkx/common/dashboardlaunchinginstances.xml deleted file mode 100644 index 9f3242d129b..00000000000 --- a/doc/src/docbkx/common/dashboardlaunchinginstances.xml +++ /dev/null @@ -1,203 +0,0 @@ - -
- Launch instances - - Instances are virtual machines that run inside the cloud. - You can launch an instance directly from one of the available OpenStack -images or from an image that you have copied to a persistent volume. -The OpenStack Image Service provides a pool of images that are accessible -to members of different projects. -
- Add security group rules - Before you launch a virtual machine, you can add - security group rules to enable users to ping and SSH to - the instances. To do so, you either add rules to the - default security group or add a security group with rules. - The following procedure shows you how to add rules to - the default security group. - - - - To add rules to the default security group: - - Log in to the OpenStack dashboard. - - - If you are a member of multiple projects, - select a project from the drop-down list at - the top of the Project - tab. - - - Click the Access & - Security category. - The dashboard shows the security groups that - are available for this project.
- OpenStack dashboard - Security Groups - - - - - - - - -
- - - Select the default security group and click - Edit Rules. The - Security Group Rules page - appears:
- OpenStack dashboard - Security Group Rules - - - - - - - - -
- - Add a TCP ruleClick Add Rule. The Add - Rule window appears. Select IP protocol TCP and enter 22 in "From Port" - and "To Port" and CIDR 0.0.0.0/0. This opens port 22 - for requests from any IP. If you want requests from - particular range of IP, provide it in CIDR - field. - - Add an ICMP ruleSelect IP protocol ICMP and enter -1 in "From Port" - and "To Port" and CIDR 0.0.0.0/0. This allows ping - from any IP. If you want ping requests from particular - range of IP, provide it in CIDR field. -
-
- Adding Keypair - Next add a Keypair. Once a Keypair is added, the - public key would be downloaded. This key can be used - to SSH to the launched instance. - - - - - - - - - - - Once this is done, we are now all set to launch an - Instance -
-
- Launching Instance - Click Images & Snapshots and launch a required - instance from the list of images available. - - - - - - - - - - - Click launch on the required image. Provide a Server - Name, select the flavor, the keypair added above and - the default security group. Provide the number of - instances required. Once these details are provided, - click Launch Instance. - - - - - - - - - - - Once the status is Active, the instance is ready and - we can ping and SSH to the instance. - - - - - - - - - - - -
-
Make a secure connection to the launched instance - Here are the steps to SSH into an instance using the - downloaded keypair file. The username is ubuntu for the - Ubuntu cloud images on TryStack. - - - - - Download the MyKey.pem file from the OpenStack Dashboard. - - - - In a command line interface, modify the - access to the .pem file: - - $ chmod 0600 MyKey.pem - - - Use the ssh-add command to ensure that the - keypair is known to - SSH:$ ssh-add MyKey.pem - - Copy the IP address from the - MyFirstInstance. - - - Use the SSH command to make a secure - connection to the - instance:$ ssh -i MyKey.pem ubuntu@10.0.0.2 - You should see a prompt asking "Are you sure you want to continue connection (yes/no)?" Type yes and you have successfully connected. - - -
-
diff --git a/doc/src/docbkx/common/figures/add_rule.png b/doc/src/docbkx/common/figures/add_rule.png index 6085f844bd7..4ad1813b808 100644 Binary files a/doc/src/docbkx/common/figures/add_rule.png and b/doc/src/docbkx/common/figures/add_rule.png differ diff --git a/doc/src/docbkx/common/figures/create_keypair.png b/doc/src/docbkx/common/figures/create_keypair.png new file mode 100644 index 00000000000..8dfe4687858 Binary files /dev/null and b/doc/src/docbkx/common/figures/create_keypair.png differ diff --git a/doc/src/docbkx/openstack-user/src/figures/instances.png b/doc/src/docbkx/common/figures/instances.png similarity index 100% rename from doc/src/docbkx/openstack-user/src/figures/instances.png rename to doc/src/docbkx/common/figures/instances.png diff --git a/doc/src/docbkx/common/figures/keypairs.png b/doc/src/docbkx/common/figures/keypairs.png new file mode 100644 index 00000000000..7076c372757 Binary files /dev/null and b/doc/src/docbkx/common/figures/keypairs.png differ diff --git a/doc/src/docbkx/openstack-user/src/figures/launch_instances.png b/doc/src/docbkx/common/figures/launch_instances.png similarity index 100% rename from doc/src/docbkx/openstack-user/src/figures/launch_instances.png rename to doc/src/docbkx/common/figures/launch_instances.png diff --git a/doc/src/docbkx/common/figures/security_group_rules.png b/doc/src/docbkx/common/figures/security_group_rules.png new file mode 100644 index 00000000000..6085f844bd7 Binary files /dev/null and b/doc/src/docbkx/common/figures/security_group_rules.png differ diff --git a/doc/src/docbkx/common/host_aggregates.xml b/doc/src/docbkx/common/host_aggregates.xml index 2eacad7395d..6a67a043e83 100644 --- a/doc/src/docbkx/common/host_aggregates.xml +++ b/doc/src/docbkx/common/host_aggregates.xml @@ -195,8 +195,8 @@ xml:id="host-aggregates"> XenServer hypervisor pools to support live migration When using the XenAPI-based hypervisor, the Compute service uses host aggregates to - manage XenServer Resource pools, which are used in supporting live migration. See Configuring Migrations for details on how to - create these kinds of host aggregates to support live migration. + create these kinds of host aggregates to support live migration. --> diff --git a/doc/src/docbkx/common/section_dashboard_launch_instances_from_image.xml b/doc/src/docbkx/common/section_dashboard_launch_instances_from_image.xml new file mode 100644 index 00000000000..1b975262504 --- /dev/null +++ b/doc/src/docbkx/common/section_dashboard_launch_instances_from_image.xml @@ -0,0 +1,172 @@ + +
+ Launch an instance from an image + + Instances are virtual machines that run inside the + cloud. + You can launch an instance directly from one of the + available OpenStack images. The OpenStack Image Service + provides a pool of images that are accessible to members of + different projects. When you launch an instance from an image, + OpenStack creates a local copy of the image on the respective + compute node where the instance is started. + Alternatively, you can launch an instance from an image that + you have copied to a persistent volume. + To launch an instance, specify the following + parameters: + + + The instance source, which is + an image or snapshot. Alternatively, you can boot from + a volume, which is block storage, to which you've + copied an image or snapshot. + + + The image or + snapshot, which represents + the operating system. + + + A name for your instance. + + + + The flavor for your + instance, which defines the compute, memory, and + storage capacity of nova computing instances. A flavor + is an available hardware configuration for a server. + It defines the size of a virtual server that can be + launched. + + + Access and security credentials, which include one + or both of the following credentials: + + + A keypair + for your instance, which are SSH credentials + that are injected into images when they are + launched. For this to work, the image must + contain the cloud-init + package. Create at least one keypair for each + project. If you already have generated a + keypair with an external tool, you can import + it into OpenStack. You can use the keypair for + multiple instances that belong to that + project. + + + A security + group, which defines which + incoming network traffic is forwarded to + instances. Security groups hold a set of + firewall policies, known as security group + rules. + + + + + If needed, you can assign a floating (public) IP address to a + running instance and attach a block storage device, or + volume, for persistent storage. + + + + To launch an instance: + + Log in to the OpenStack dashboard. + + + If you are a member of multiple projects, select a + project from the drop-down list at the top of the + Project tab. + + + Click the Images & Snapshot + category. + The dashboard shows the images that have been + uploaded to OpenStack Image Service and are available + for this project. + + + Select an image and click + Launch. The + Launch Image window appears:
+ OpenStack dashboard - Launch Instances + window + + + + + +
+ + + Specify the following parameters: + + + + Enter an instance name to assign to the + virtual machine. + + + From the Flavor + drop-down list, select the size of the virtual + machine to launch. + + + Optionally, select a keypair. + In case an image uses a static root password + or a static key set (neither is recommended), + you do not need to provide a keypair on + starting the instance. + + + In Instance Count, + enter the number of virtual machines to launch + from this image. + + + Assign the instance to the default security + group. If you added rules to this group, the + instance implements these rules. + + + + + + Click Launch Instance. The + instance is launched on any of the compute nodes in + the cloud. + + + After you have launched an instance, switch to the + Instances & Volumes category to + view the instance name, its (private or public) IP address, + size, status, task, and power state. +
+ OpenStack dashboard - Instances + + + + + +
+ If you did not provide a keypair on starting and have not + touched security groups or rules so far, by default the + instance can only be accessed from inside the cloud through + VNC at this point. Even pinging the instance is not possible. +
diff --git a/doc/src/docbkx/common/wadl/security-groups.wadl b/doc/src/docbkx/common/wadl/security-groups.wadl new file mode 100644 index 00000000000..d9ef5b8a30d --- /dev/null +++ b/doc/src/docbkx/common/wadl/security-groups.wadl @@ -0,0 +1,258 @@ + + +%common;]> + + + + + + + + + + +

The + unique identifier of the tenant or + account.

+ + + + + + + + + +

The unique identifier of the + security group.

+ + + + + + + + + + + + +

The unique identifier of the + security group rule.

+ + + + + + + + + + + + +

The UUID for the server of + interest to you.

+ + + + + + + + + + + + + + +

Lists a summary of all Quantum-defined security groups that are accessible to the specified tenant.

The list provides + the unique ID for each security group.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Shows information + for a specified security group.

+ + + + + + + + + + + + + + + + + +

Creates a security + group.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Deletes a security + group.

+ + + + + +

Lists security + group rules.

+ + + + + + + + + + + + + + + + +

Creates a security + group rule.

+ + + + + + + + + + + + + + + + + + + + + + + + +

Deletes a + specified Quantum security group rule from a security + group.

+ + + + + diff --git a/doc/src/docbkx/openstack-compute-admin/bk-compute-adminguide.xml b/doc/src/docbkx/openstack-compute-admin/bk-compute-adminguide.xml index cae7ad4dc82..9fbaa8674bf 100644 --- a/doc/src/docbkx/openstack-compute-admin/bk-compute-adminguide.xml +++ b/doc/src/docbkx/openstack-compute-admin/bk-compute-adminguide.xml @@ -228,14 +228,15 @@ - - + + + diff --git a/doc/src/docbkx/openstack-compute-admin/ch_instance_mgmt.xml b/doc/src/docbkx/openstack-compute-admin/ch_instance_mgmt.xml index 2eec7b053b5..79964ba8575 100644 --- a/doc/src/docbkx/openstack-compute-admin/ch_instance_mgmt.xml +++ b/doc/src/docbkx/openstack-compute-admin/ch_instance_mgmt.xml @@ -6,14 +6,15 @@ Instance Management Instances are the running virtual machines within an - OpenStack cloud. The Images and Instances section of the Introduction to OpenStack Compute Chapter provides - a high level overview of instances and their life cycle + OpenStack cloud. +See + for + a high level overview of instances and their life cycle. - This chapter deals with the details of how to manage that - life cycle + This chapter describes how to manage that + life cycle.
@@ -151,10 +152,10 @@ header: Date: Thu, 13 Sep 2012 20:27:36 GMT provides an EC2 compatible API. This allows legacy workflows built for EC2 to work with OpenStack. - Configuring the + @@ -401,8 +402,7 @@ header: Date: Thu, 13 Sep 2012 20:27:36 GMT
Controlling where instances run - The scheduler - filters section provides detailed information + The provides detailed information on controlling where your instances run, including ensuring a set of instances run on different compute @@ -457,10 +457,10 @@ header: Date: Thu, 13 Sep 2012 20:27:36 GMT or you are trying to debug a problem image OpenStack can be configured to provide a VNC console, be aware that VNC is an unencrypted protocol so you should be cautious what - you type across that link. See the
diff --git a/doc/src/docbkx/openstack-compute-admin/computeadmin.xml b/doc/src/docbkx/openstack-compute-admin/computeadmin.xml index 1a1cd530cdf..a3c80fc6fba 100644 --- a/doc/src/docbkx/openstack-compute-admin/computeadmin.xml +++ b/doc/src/docbkx/openstack-compute-admin/computeadmin.xml @@ -341,8 +341,8 @@ local0.error @@172.20.1.43:1024
Using Migration - Before starting migrations, review the Configuring Migrations section. + Migration provides a scheme to migrate running instances from one OpenStack Compute server to another OpenStack Compute server. This feature can be used as described below. @@ -437,9 +437,9 @@ HostC p2 5 10240 150 list. If instances are still running on HostB, check logfiles (src/dest nova-compute and nova-scheduler) to determine why. While the nova command is called live-migration, under the default Compute - configuration options the instances are suspended before migration. See + configuration options the instances are suspended before migration.
@@ -447,10 +447,10 @@ HostC p2 5 10240 150 Recovering from a failed compute node If you have deployed OpenStack Compute with a shared filesystem, you can quickly recover from a failed compute node. -
- Using the evacuate API for KVM/libvirt - Refer to Evacuate API Reference section for more details. -
+ + +
Manual recovery For KVM/libvirt compute node recovery refer to section above, while the guide below may be applicable for other hypervisors. diff --git a/doc/src/docbkx/openstack-compute-admin/computeinstall.xml b/doc/src/docbkx/openstack-compute-admin/computeinstall.xml index 60702409430..2719930f552 100644 --- a/doc/src/docbkx/openstack-compute-admin/computeinstall.xml +++ b/doc/src/docbkx/openstack-compute-admin/computeinstall.xml @@ -175,10 +175,10 @@ URI: http://download.opensuse.org/repositories/Cloud:/OpenStack:/Grizzly/openSUS When using OpenStack Compute with Citrix XenServer or XCP hypervisor, OpenStack Compute should be installed in a virtual machine running on your hypervisor, rather than installed directly on the hypervisor, - as you would do when using the Libvirt driver. - For more information see: + as you would do when using the Libvirt driver. + Given how you should deploy OpenStack with XenServer, the first step when @@ -186,11 +186,10 @@ URI: http://download.opensuse.org/repositories/Cloud:/OpenStack:/Grizzly/openSUS is to install XenServer and install the required XenServer plugins. You can install XCP by installing Debian or Ubuntu, but generally rather than installing the operating system of your choice on your compute nodes, - you should first install XenServer. - For more information see: + you should first install XenServer. + Once you have installed XenServer and the XenAPI plugins on all your compute nodes, you next need to create a virtual machine on each of those compute nodes. @@ -199,8 +198,8 @@ URI: http://download.opensuse.org/repositories/Cloud:/OpenStack:/Grizzly/openSUS You can follow the previous distribution specific instructions to get the OpenStack code running in your Virtual Machine. Once installed, you will need to configure OpenStack Compute to talk to - your XenServer or XCP installation. For more information see: + your XenServer or XCP installation.
diff --git a/doc/src/docbkx/openstack-compute-admin/computeinterfaces.xml b/doc/src/docbkx/openstack-compute-admin/computeinterfaces.xml index 1a9af028915..87d96543b20 100644 --- a/doc/src/docbkx/openstack-compute-admin/computeinterfaces.xml +++ b/doc/src/docbkx/openstack-compute-admin/computeinterfaces.xml @@ -5,8 +5,13 @@ version="5.0" xml:id="ch_openstack-interfaces"> OpenStack Interfaces - The OpenStack dashboard, a Web interface, -enables you to connect to running instances through a VNC connection. - - + You can interact with an OpenStack cloud in the following ways: + + The OpenStack dashboard. + + + A VNC connection through a VNC proxy. + + + diff --git a/doc/src/docbkx/openstack-compute-admin/computenetworking.xml b/doc/src/docbkx/openstack-compute-admin/computenetworking.xml index 18967691594..08e6884d8ea 100644 --- a/doc/src/docbkx/openstack-compute-admin/computenetworking.xml +++ b/doc/src/docbkx/openstack-compute-admin/computenetworking.xml @@ -446,9 +446,9 @@ echo 'Extra user data here' Before reading how to configure networking using the XenAPI compute driver, you may find it useful to read the Citrix article on - Understanding XenServer Networking and the section of this + Understanding XenServer Networking.
@@ -2125,8 +2125,8 @@ enabled_apis=ec2,osapi_compute,osapi_volume,metadata hosts networks will send all network related commands to the host that the specific VM is on. You need to edit the configuration option enabled_apis such that it includes metadata in the list of enabled APIs. - Other options become available when you configure multi_host nova networking please - refer to Configuration: nova.conf. + Other options become available when you configure multi_host nova networking. + You must specify the multi_host option on the command line when creating fixed networks. For example: diff --git a/doc/src/docbkx/openstack-compute-admin/pom.xml b/doc/src/docbkx/openstack-compute-admin/pom.xml index 85a373df1f1..3238dd3aa42 100644 --- a/doc/src/docbkx/openstack-compute-admin/pom.xml +++ b/doc/src/docbkx/openstack-compute-admin/pom.xml @@ -44,11 +44,11 @@ appendix toc,title article/appendix nop article toc,title - book title,figure,table,example,equation - chapter toc,title + book toc,title,figure,table,example,equation + chapter toc section toc - part toc,title - preface toc,title + part toc + preface toc qandadiv toc qandaset toc reference toc,title diff --git a/doc/src/docbkx/openstack-compute-admin/remote-console-access.xml b/doc/src/docbkx/openstack-compute-admin/remote-console-access.xml index 8cf665542f7..041ae8e9eb6 100644 --- a/doc/src/docbkx/openstack-compute-admin/remote-console-access.xml +++ b/doc/src/docbkx/openstack-compute-admin/remote-console-access.xml @@ -4,7 +4,7 @@ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="remote-console-access"> - Remote Console Access + Access OpenStack through a remote console OpenStack has two main methods for providing a remote console or remote desktop access to guest Virtual diff --git a/doc/src/docbkx/openstack-compute-admin/section_dashboard.xml b/doc/src/docbkx/openstack-compute-admin/section_dashboard.xml new file mode 100644 index 00000000000..f727210fb0c --- /dev/null +++ b/doc/src/docbkx/openstack-compute-admin/section_dashboard.xml @@ -0,0 +1,69 @@ + +
+ The OpenStack dashboard + The + OpenStack dashboard, also known as horizon, is a Web interface that allows cloud + administrators and users to manage various OpenStack resources + and services. + The dashboard enables web-based interactions with the + OpenStack Compute cloud controller through the OpenStack APIs. + The following instructions show an example deployment + configured with an Apache web server. + To install the OpenStack dashboard, complete the following + high-level steps: + + + Meet the system requirements for accessing the + dashboard. See . + + + Install the OpenStack Dashboard framework, including + Apache and related modules. See . + + + Configure the dashboard. + Then, restart and run the Apache server. + See . + + + Verify your installation. See . + + + + Next steps: + After you install the dashboard, you can complete the + following tasks: + + To customize your dashboard, see . + + + To set up session storage for the dashboard, see + . + + + To deploy the dashboard, see Deploying Horizon. + + + To launch instances with the dashboard, see the + OpenStack User + Guide. + + + + + + + + +
diff --git a/doc/src/docbkx/openstack-user/pom.xml b/doc/src/docbkx/openstack-user/pom.xml index 74ae92ca397..374c4ee2324 100644 --- a/doc/src/docbkx/openstack-user/pom.xml +++ b/doc/src/docbkx/openstack-user/pom.xml @@ -7,6 +7,14 @@ 1.0.0-SNAPSHOT jar OpenStack Guides + + + grizzly + 1 + apt + + ubuntu + @@ -52,7 +60,7 @@ set toc,title 0 user-guide 0 - user-guide.pdf + user-guide diff --git a/doc/src/docbkx/openstack-user/src/ch_cli.xml b/doc/src/docbkx/openstack-user/src/ch_cli.xml index fc15471db23..0b56458bec8 100644 --- a/doc/src/docbkx/openstack-user/src/ch_cli.xml +++ b/doc/src/docbkx/openstack-user/src/ch_cli.xml @@ -12,7 +12,18 @@ The OpenStack project provides a variety of command-line clients that let you manage the services within your cloud and automate tasks by using scripts. Each of the core OpenStack - components has its own command-line client. + components has its own command-line client. These open-source + Python clients run on Linux or Mac OS X systems and are easy + to learn and use. + You can use the OpenStack command-line clients to run simple + commands that make API calls. You can specify a debug + parameter on any client command to show the underlying API + request for the command. This is a good way to become familiar + with the OpenStack API requests. These examples walk you through the steps to create a server instance with 2 GB of physical memory. diff --git a/doc/src/docbkx/openstack-user/src/ch_dashboard.xml b/doc/src/docbkx/openstack-user/src/ch_dashboard.xml index f734a952853..76afe36ae51 100644 --- a/doc/src/docbkx/openstack-user/src/ch_dashboard.xml +++ b/doc/src/docbkx/openstack-user/src/ch_dashboard.xml @@ -7,14 +7,40 @@ xmlns:raxm="http://docs.rackspace.com/api/metadata" version="5.0" xml:id="ch_dashboard"> - OpenStack dashboard + The OpenStack dashboard The OpenStack dashboard, also known as horizon, is a Web interface that allows cloud - administrators and users to manage various OpenStack resources - and services. + >horizon, is a Web-based interface that enables + cloud administrators and users to manage various OpenStack + resources and services. + You can customize the + dashboard with your own brand and other features. + As a cloud + administrator, the dashboard provides you with an overall view + of the size and state of your cloud. You can create users and + projects, assign users to projects and set limits on the + resources for those projects. + As a cloud user, the + dashboard enables you to provision your own resources within + the limits set by administrators. + To see a demo of the + dashboard, go to OpenStack Dashboard. After a short introduction, learn how to use the install and configure the dashboard. Then use the simple @@ -26,8 +52,7 @@ - - + diff --git a/doc/src/docbkx/openstack-user/src/ch_openstack_what_and_how.xml b/doc/src/docbkx/openstack-user/src/ch_openstack_what_and_how.xml index 959ee674e07..827595869a7 100644 --- a/doc/src/docbkx/openstack-user/src/ch_openstack_what_and_how.xml +++ b/doc/src/docbkx/openstack-user/src/ch_openstack_what_and_how.xml @@ -14,70 +14,56 @@ images and snapshots, set up cloud access and security, and track usage. Cloud administrators can also create and manage users and projects. + As a cloud administrator, the dashboard provides you with + an overall view of the size and state of your cloud. You can + create users and projects, assign users to projects and set + limits on the resources for those projects. As a cloud user, + the dashboard enables you to provision your own resources + within the limits set by administrators. You can achieve most of these tasks with the OpenStack dashboard or the OpenStack command-line clients. The dashboard and the command-line clients are not the only ways to interact with OpenStack resources and services. You can automate access or build tools to manage resources and services by using the native OpenStack APIs or the EC2 compatibility API. + This guide helps OpenStack cloud administrators and users + launch and manage instances and manage volumes. For each exercise in this guide, you choose one of the - following methods to complete tasks in the cloud: - - The OpenStack - dashboard. The OpenStack dashboard - provides administrators and users a graphical - interface to access, provision, and automate - cloud-based resources. You can customize the - dashboard with your own brand. The dashboard is an - extensible web app that allows cloud - administrators and users to control their compute, - storage, and networking resources. - As a cloud administrator, the dashboard provides - an overall view of the size and state of your - cloud. You can create users and projects, assign - users to projects and set limits on the resources - for those projects. The dashboard provides users a - self-service portal to provision their own - resources within the limits set by administrators. - To see a demo of the dashboard, go to OpenStack Dashboard. - - - The OpenStack command-line - clients. We recommend that you use - the OpenStack command-line clients to run simple - commands that make API calls. These open-source - Python clients run on Linux or Mac OS X systems - and are easy to learn and use. You can specify a - debug parameter on any - client command to show the underlying API request - for the command. This is a good way to become - familiar with the OpenStack API requests. - - - Other methods. - - cURL commands. - If you are familiar with or want to - learn cURL commands, choose this - method. With cURL, you send HTTP - requests with embedded API calls from - the command line. The cURL examples in - this guide include request bodies that - are in JSON format. - - - Rackspace SDKs. Rackspace Developer - Center. - - - - - - + following methods to complete tasks in the cloud: + + + OpenStack dashboard, also known as horizon, is a Web-based graphical + interface that enables cloud administrators and users + to access, provision, and automate cloud-based + resources. + + + OpenStack command-line clients let cloud + administrators and users run simple commands to manage + resources and services within a cloud and automate + tasks by using scripts. Each of the core OpenStack + projects has its own command-line client. + + + You can also interact with an OpenStack cloud in the + following ways: + + + cURL + commands. If you are familiar with or + want to learn cURL commands, choose this method. With + cURL, you send HTTP requests with embedded API calls + from the command line. The cURL examples in this guide + include request bodies that are in JSON format. + + + + Rackspace SDKs. See Rackspace Developer Center. + + diff --git a/doc/src/docbkx/openstack-user/src/ch_overview.xml b/doc/src/docbkx/openstack-user/src/ch_overview.xml index c8e04d73718..1a9f536d26d 100644 --- a/doc/src/docbkx/openstack-user/src/ch_overview.xml +++ b/doc/src/docbkx/openstack-user/src/ch_overview.xml @@ -9,43 +9,25 @@ xml:id="openstack_user_guide"> OpenStack User Guide - OpenStack is a global collaboration of developers and cloud - computing technologists producing the ubiquitous open source - cloud computing platform for public and private clouds. - The project delivers solutions for all types of clouds by - being simple to implement, massively scalable, and feature - rich. - The technology consists of a series of interrelated projects - that deliver various components for a cloud infrastructure - solution. + OpenStack is an open source cloud computing platform for + public and private clouds. The technology consists of a series + of interrelated projects that deliver various components for a + cloud infrastructure solution. This guide helps OpenStack cloud administrators and users launch and manage instances and manage volumes. You can achieve most of these tasks with the OpenStack dashboard or the OpenStack command-line clients. - The OpenStack dashboard, also known as horizon, is a Web interface that allows cloud - administrators and users to manage various OpenStack resources - and services. The dashboard enables web-based interactions - with the OpenStack Compute cloud controller through the - OpenStack APIs. - The OpenStack project also provides a variety of - command-line clients that let you manage resources and - services within your cloud and automate tasks by using - scripts. Each of the core OpenStack components has its own - command-line client. - The exercises help you learn how cURL commands and the - OpenStack APIs work. To use the OpenStack APIs, it helps to be familiar with HTTP/1.1, RESTful web services, the OpenStack services, and JSON or XML data serialization formats.
Resources - For the available documentation, see For the available OpenStack documentation, see docs.openstack.org. - For the Rackspace SDKs, see . + For the Rackspace SDKs, see the Rackspace + Developer Center.
diff --git a/doc/src/docbkx/openstack-user/src/section_cli_overview.xml b/doc/src/docbkx/openstack-user/src/section_cli_overview.xml index f27b56714d7..58c6343b7cc 100644 --- a/doc/src/docbkx/openstack-user/src/section_cli_overview.xml +++ b/doc/src/docbkx/openstack-user/src/section_cli_overview.xml @@ -6,49 +6,64 @@ Command-line clients overview The following command-line clients are available for the respective services' APIs: - - keystone - Identity Service + + + keystone + + Identity Service Manage users and projects. - python-keystoneclient - - - nova + python-keystoneclient + + + + nova + Compute, Compute extensions Manage instances and flavors. - python-novaclient - - - glance + python-novaclient + + + + glance + Image Service Manage images. - python-glanceclient - - - cinder + python-glanceclient + + + + cinder + Block Storage Service Manage volumes. - python-cinderclient - - - quantum + python-cinderclient + + + + quantum + Networking Configure networks for guest servers. - python-quantumclient - - - swift + python-quantumclient + + + + swift + Object Storage Manage the object store. - python-swiftclient - - - heat + python-swiftclient + + + + heat + Orchestration Launch stacks from templates and manage stacks. - python-heatclient - + python-heatclient + + All clients have tab completion. Help and detailed information about the individual commands diff --git a/doc/src/docbkx/openstack-user/src/section_dashboard_install.xml b/doc/src/docbkx/openstack-user/src/section_dashboard_install.xml index 298e1f7b814..4287d850bd7 100644 --- a/doc/src/docbkx/openstack-user/src/section_dashboard_install.xml +++ b/doc/src/docbkx/openstack-user/src/section_dashboard_install.xml @@ -5,29 +5,53 @@ xml:id="section_dashboad_install"> Install the OpenStack dashboard - To install the OpenStack dashboard, complete the following - high-level tasks: - - - Meet the system requirements for the - dashboard. - - - Install the OpenStack dashboard framework, including - Apache and related modules. - - - Configure the dashboard. - - - Restart and run the Apache server. - - - Deploy the dashboard. See Deploying Horizon. - - + The following instructions show an example dashboard + deployment configured with an Apache web server. + To install the OpenStack dashboard, complete the + following high-level steps: + + + Meet the system requirements for accessing the + dashboard. See . + + + Install the OpenStack Dashboard framework, + including Apache and related modules. See . + + + Configure the dashboard. + Then, restart and run the Apache server. + See . + + + Verify your installation. See . + + + Next steps: + After you install the dashboard, you can complete + the following tasks: + + To customize your dashboard, see . + + + + To set up session storage for the dashboard, + see . + + + To deploy the dashboard, see Deploying Horizon. + + diff --git a/doc/src/docbkx/openstack-user/src/section_dashboard_launch_instances.xml b/doc/src/docbkx/openstack-user/src/section_dashboard_launch_instances.xml new file mode 100644 index 00000000000..87a0c52ab6e --- /dev/null +++ b/doc/src/docbkx/openstack-user/src/section_dashboard_launch_instances.xml @@ -0,0 +1,367 @@ + +
+ Launch an instance + + Instances are virtual machines that run inside the cloud. + You can launch an instance directly from one of the available + OpenStack images or from an image that you have copied to a + persistent volume. The OpenStack Image Service provides a pool + of images that are accessible to members of different + projects. + You can optionally add security group rules to the default + security group, and create a keypair to enable SSH access to + your instance. +
+ Add security group rules + Before you launch a virtual machine, you can add + security group rules to enable users to ping and SSH to + the instances. To do so, you either add rules to the + default security group or add a security group with rules. + The following procedure shows you how to add rules to + the default security group. + + To add rules to the default security group: + + Log in to the OpenStack dashboard. + + + If you are a member of multiple projects, select + a project from the drop-down list at the top of + the Project tab. + + + Click the Access & + Security category. + The dashboard shows the security groups that are + available for this project. +
+ OpenStack dashboard - Security + Groups + + + + + + + + +
+ + + Select the default security group and click + Edit Rules. + The Security Group Rules + page appears: +
+ OpenStack dashboard - Security Group + Rules + + + + + + + + +
+ + + Add a TCP rule + Click Add Rule. + The Add Rule window + appears. +
+ OpenStack dashboard - Add Rule + + + + + + + +
+ + + In the IP Protocol + list, select TCP. + + + + In the Open list, + select Port. + + + In the Port box, + enter 22. + + + In the Source list, + select CIDR. + + + In the CIDR box, + enter 0.0.0.0/0. + + + Click Add. + Port 22 is now open for requests from + any IP address. + If you want to accept requests from a + particular range of IP addresses, specify + the IP address block in the + CIDR box. + + + + + Add an ICMP rule + Click Add Rule. + The Add Rule window + appears. + + + In the IP Protocol + list, select ICMP. + + + + In the Type box, + enter -1. + + + In the Code box, + enter -1. + + + In the Source list, + select CIDR. + + + In the CIDR box, + enter 0.0.0.0/0. + + + Click Add. + + If you want to accept requests from a + particular range of IP addresses, specify + the IP address block in the + CIDR box. + + + + +
+
+ Add keypair + Keypairs are SSH credentials that are injected into + images when they are launched. For this to work, the image + must contain the cloud-init package. + Create at least one keypair for each project. If you + have generated a keypair with an external tool, you can + import it into OpenStack. The keypair can be used for + multiple instances that belong to a project. + + To add a keypair: + + Log in to the OpenStack dashboard. + + + If you are a member of multiple projects, select + a project from the drop-down list at the top of + the Project tab. + + + Click the Access & + Security category. + + + Click the Keypairs tab. The + dashboard shows the keypairs that are available + for this project. + + + To add a keypair: + Click Create Keypair. + The Create Keypair window + appears. +
+ OpenStack dashboard - Create + Keypair + + + + + + + + +
+ + + + In the Keypair Name + box, enter a name for your keypair. + + + + + Click Create + Keypair. + + + Respond to the prompt to download the + keypair. + + + + + To import a keypair: + Click Import Keypair. + The Import Keypair window + appears. + + + In the Keypair Name + box, enter the name of your keypair. + + + + In the Public Key + box, copy the public key. + + + Click Import + Keypair. + + + + + Save the *.pem file locally + and change its permissions so that only you can + read and write to the file: + + $ chmod 0600 MY_PRIV_KEY.pem + + + + Use the ssh-add command to + make the keypair known to + SSH:$ ssh-add MY_PRIV_KEY.pem + + + The public key of the keypair is registered in the Nova + database. + The dashboard lists the keypair in the Access + & Security category, as follows: +
+ OpenStack dashboard - Keypairs + + + + + + + + +
+
+ + +
+ SSH in to your instance + To SSH into your instance, you use the downloaded + keypair file. + + The username is ubuntu for the Ubuntu cloud images + on TryStack. + + + To SSH in to your instance: + + Copy the IP address for your instance. + + + Use the SSH command to make a secure connection + to the instance. For + example:$ ssh -i MyKey.pem ubuntu@10.0.0.2 + + + A prompt asks, "Are you sure you want to + continue connection (yes/no)?" Type + yes and you have + successfully connected. + + +
+
diff --git a/doc/src/docbkx/openstack-user/src/section_dashboard_launch_instances_from_image.xml b/doc/src/docbkx/openstack-user/src/section_dashboard_launch_instances_from_image.xml index 6bfbc404847..d137424755d 100644 --- a/doc/src/docbkx/openstack-user/src/section_dashboard_launch_instances_from_image.xml +++ b/doc/src/docbkx/openstack-user/src/section_dashboard_launch_instances_from_image.xml @@ -117,17 +117,22 @@ Select an image and click Launch. The Launch Image window - appears:
- OpenStack dashboard - Launch - Instances window + appears: +
+ OpenStack dashboard - Launch Instances - - + + + + + -
+
, specify the following: @@ -194,11 +199,17 @@ public) IP address, size, status, task, and power state.
- OpenStack dashboard - Instances screen + OpenStack dashboard - Instances - - + + + + +
diff --git a/doc/src/docbkx/openstack-user/src/section_dashboard_launch_instances_from_volume.xml b/doc/src/docbkx/openstack-user/src/section_dashboard_launch_instances_from_volume.xml index fcca2d02d62..95c4ace5592 100644 --- a/doc/src/docbkx/openstack-user/src/section_dashboard_launch_instances_from_volume.xml +++ b/doc/src/docbkx/openstack-user/src/section_dashboard_launch_instances_from_volume.xml @@ -132,8 +132,7 @@ Guide. - Launch an instance as described in . + Launch an instance. Attach the volume to the instance as @@ -163,11 +162,11 @@ As only detached volumes are available for booting, detach the volume. - For details, see xxxx. + - + To boot an instance from the volume, - continue with . @@ -188,7 +187,7 @@ iSCSI. For preparation details, see . - To boot an instance from the volume, follow +