openstack/fuel-docs
Code Issues Proposed changes

split user guide source into modular files

Browse Source 
Change-Id: Id8e464114a88c46c138007c78003b20fb2d59adc
This commit is contained in:
Meg McRoberts 2014-03-26 17:45:14 -07:00 committed by Dmitry Borodaenko
parent 6351cad4a4
commit 67b08719dd
18 changed files with 709 additions and 695 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
pages/user-guide/custom-attributes.rst
View File

@ -16,9 +16,6 @@ You can do this at your own risk, and some features might
become unaccessible from UI after that. Also, there will be a warning
telling that some attributes were modified from the outside.
Possible Use Cases
------------------
First, you should set up an environment as always, assign roles to nodes but don't
start deployment yet. Now you can dump provisioning after that as JSON using this
command::

33
pages/user-guide/health-checks/0100-intro-health-checks.rst Normal file
View File

@ -0,0 +1,33 @@
.. raw:: pdf
PageBreak
.. index:: Fuel UI: Post-Deployment Check
.. _Post-Deployment-Check:
Post-Deployment Check
=====================
.. contents :local:
On occasion, even a successful deployment may result in some OpenStack
components not working correctly. If this happens, Fuel offers the ability
to perform post-deployment checks to verify operations. Part of Fuel's goal
is to provide easily accessible status information about the most commonly
used components and the most recently performed actions. To perform these
checks you will use Sanity and Functional checks, as described below:
**Sanity Checks**
Reveal whether the overall system is functional.
If these tests fail, you probably need to restart some services to operate OpenStack.
**Functional Checks**
Dive in a little deeper and reveal networking, system-requirements,
functionality issues.
Sanity Checks will likely be the point on which the success of your
deployment pivots, but it is critical to pay close attention to all
information collected from theses tests. Another way to look at these tests
is by their names.

21
pages/user-guide/health-checks/0120-benefits.rst Normal file
View File

@ -0,0 +1,21 @@
Benefits
--------
* Using post-deployment checks helps you identify potential issues which
may impact the health of a deployed system.
* All post-deployment checks provide detailed descriptions about failed
operations and tell you which component or components are not working
properly.
* Previously, performing these checks manually would have consumed a
great deal of time. Now, with these checks the process will take only a
few minutes.
* Aside from verifying that everything is working correctly, the process
will also determine how quickly your system works.
* Post-deployment checks continue to be useful, for example after
sizable changes are made in the system you can use the checks to
determine if any new failure points have been introduced.

40
pages/user-guide/health-checks/0200-run-tests.rst Normal file
View File

@ -0,0 +1,40 @@
Running Post-Deployment Checks
------------------------------
Now, let`s take a closer look on what should be done to execute the tests and
to understand if something is wrong with your OpenStack environment.
.. image:: /_images/001-health-check-tab.jpg
:align: center
:width: 100%
As you can see on the image above, the Fuel UI now contains a ``Health Check``
tab, indicated by the Heart icon.
All of the post-deployment checks are displayed on this tab. If your
deployment was successful, you will see a list of tests this show a green
Thumbs Up in the last column. The Thumb indicates the status of the
component. If you see a detailed message and a Thumbs Down, that
component has failed in some manner, and the details will indicate where the
failure was detected. All tests can be run on different environments, which
you select on main page of Fuel UI. You can run checks in parallel on
different environments.
Each test contains information on its estimated and actual duration. There is
information included about test processing time from in-house testing and
indicate this in each test. Note that average times are listed from the slowest
to the fastest systems tested, so your results may vary.
Once a test is complete, the results will appear in the Status column. If
there was an error during the test, the you will see the error message
below the test name. To assist in troubleshooting, the test
scenario is displayed under the failure message and the failed step is
highlighted. You will find more detailed information on these tests later in
this section.
An actual test run looks like this:
.. image:: /_images/002-health-check-results.jpg
:align: center
:width: 100%

38
pages/user-guide/health-checks/0300-test-fails.rst Normal file
View File

@ -0,0 +1,38 @@
What To Do When a Test Fails
----------------------------
If a test fails, there are several ways to investigate the problem. You may
prefer to start in Fuel UI, since its feedback is directly related to the
health of the deployment. To do so, start by checking the following:
* Under the `Health Check` tab
* In the OpenStack Dashboard
* In the test execution logs (in Environment Logs)
* In the individual OpenStack components' logs
Certainly there are many different conditions that can lead to system
breakdowns, but there are some simple items that can be examined before you
start digging deeply. The most common issues include:
* Not all OpenStack services are running
* Some defined quota has been exceeded
* Something has broken in the network configuration
* A general lack of resources (memory/disk space)
The first thing to be done is to ensure all OpenStack services are up and
running. To do this, you can run the sanity test set or execute the following
command on your Controller node::
nova-manage service list
If any service is off (has “XXX” status), you can restart it using this command::
service openstack-<service name> restart
If all services are on, but you`re still experiencing some issues, you can
gather information from OpenStack Dashboard (exceeded number of instances,
fixed IPs, etc). You may also read the logs generated by tests which are
stored in Logs -> Fuel Master -> Health Check and check if any operation is
in ERROR status. If it looks like the last item, you may have underprovisioned
our environment and should check your math and your project requirements.

25
pages/user-guide/health-checks/0400-sanity-tests-about.rst Normal file
View File

@ -0,0 +1,25 @@
Sanity Tests Description
------------------------
Sanity checks work by sending a query to all OpenStack components to get a
response back from them. Many of these tests are simple in that they ask
each service for a list of its associated objects and then waits for a
response. The response can be something, nothing, an error, or a timeout,
so there are several ways to determine if a service is up. The following list
includes the suite of sanity tests implemented:
* Instance list availability
* Images list availability
* Volume list availability
* Snapshots list availability
* Flavor list availability
* Limits list availability
* Services list availability
* User list availability
* Stack list availability
* Check all the services execute normally
* Check Internet connectivity from a compute
* Check DNS resolution on a compute
* Murano environment and service creation, listing and deletion
* Networks availability

28
pages/user-guide/health-checks/0410-functional-tests-about.rst Normal file
View File

@ -0,0 +1,28 @@
Functional Tests Description
----------------------------
Functional tests verify how your system handles basic OpenStack operations
under normal circumstances.
The Functional Test series gives you information about the speed of your environment
and runs timeout tests.
All tests use the basic OpenStack services (Nova, Glance, Keystone, Cinder, etc)
so, if any of these are inactive, the test using it will fail.
You should run all sanity checks before running the functional checks
to verify that all services are alive.
This helps ensure that you do not get false negatives.
The following is a description of each sanity test available:
* Create instance flavor
* Create instance volume
* Launch instance, create snapshot, launch instance from snapshot
* Keypair creation
* Security group creation
* Check networks parameters
* Launch instance
* Assign floating IP
* Check that VM is accessible via floating IP address
* Check network connectivity from instance via floating IP
* Check network connectivity from instance without floating IP
* User creation and authentication in Horizon

16
pages/user-guide/health-checks/0500-addtional-checks-intro.rst Normal file
View File

@ -0,0 +1,16 @@
Additional Checks
-----------------
If you have installed OpenStack to use a High Availability (HA) architecture
or have installed related OpenStack projects like Savanna or Murano,
additional tests will be shown. The following are the tests available
in HA mode:
* Check data replication over mysql
* Check amount of tables in os databases is the same on each node
* Check mysql environment state
* Check galera environment state
* RabbitMQ availability
Savanna and Murano tests are included in Platform Tests and are
described in the next section.

15
pages/user-guide/health-checks/0600-platform-tests-intro.rst Normal file
View File

@ -0,0 +1,15 @@
.. _platform-tests-label:
Platform Tests Description
--------------------------
Platform tests verify basic functionality of Heat, Savanna and Murano
services.
Typically, preparation for Savanna testing is a lengthy process that
involves several manual configuration steps.
.. include:: /pages/user-guide/health-checks/0610-sahara-prepare-test.rst
.. include:: /pages/user-guide/health-checks/0620-murano-prepare-test.rst
.. include:: /pages/user-guide/health-checks/0630-heat-prepare-test.rst
.. include:: /pages/user-guide/health-checks/0640-platform-test-details.rst

35
pages/user-guide/health-checks/0610-sahara-prepare-test.rst Normal file
View File

@ -0,0 +1,35 @@
Preparing Savanna for Testing
+++++++++++++++++++++++++++++
The platform tests are run in the tenant you've specified in
'OpenStack Settings' tab during OpenStack installation. By default that is
'admin' tenant. Perform in the that tenant the following actions:
1. Configure security groups in the 'admin' tenant for post-deployment checks.
See :ref:`savanna-deployment-label` for the details.
2. Get an image with Hadoop for Savanna and register it with Savanna.
* First download the following image:
http://savanna-files.mirantis.com/savanna-0.3-vanilla-1.2.1-ubuntu-13.04.qcow2
* Then upload the image into OpenStack Image Service (Glance) into
'admin' tenant and name it 'savanna'.
* In OpenStack Dashboard (Horizon) access 'Savanna' tab.
* Switch to 'admin' tenant if you are not in it already.
* Go to the ‘Image Registry’ menu. Here push ‘Register Image’ button.
Image registration window will open up.
* Select the image you’ve just uploaded.
* Set username to ‘ubuntu’
* For tags, pick ‘vanilla’ plugin and ‘1.2.1’ version and press
‘Add all’ button.
* Finally push ‘Done’ button
After the steps above are done, the Savanna is ready to be tested.

65
pages/user-guide/health-checks/0620-murano-prepare-test.rst Normal file
View File

@ -0,0 +1,65 @@
Preparing Murano for Testing
+++++++++++++++++++++++++++++
The platform tests are run in the tenant you've specified in
'OpenStack Settings' tab during OpenStack installation.
The 'admin' tenant is selected by default.
To prepare Murano for Windows-based services deployment testing:
1. Add Windows based image to Murano:
* Create a Windows image with Murano agent.
See `Murano documentation (Windows Image Builder) <http://murano-docs.github.io/latest/administrators-guide/content/ch03.html>`_
(Please note, the Murano Image Builder documentation referenced here cannot guarantee success with image creation and could be outdated)
* Upload the image to the OpenStack Image Service (Glance) into the 'admin' tenant.
* In the OpenStack Dashboard, click the 'Project' tab.
* Switch to admin tenant if needed.
* Open 'Murano' tab.
* Click the 'Images' menu.
* Click 'Mark Image'. The Image registration window displays.
* Select the Windows image with Murano agent.
* In the 'Title' field, set title for this image.
* Select the 'Windows Server 2012' type.
* Click 'Mark'.
2. Add Linux based image to Murano:
* Create a Linux image with Murano agent.
See `Murano documentation (Linux Image Builder) <http://murano-docs.github.io/latest/administrators-guide/content/ch04.html>`_
(Please note, the Murano Image Builder documentation referenced here cannot guarantee success with image creation and could be outdated)
* Upload the image to the OpenStack Image Service (Glance) into the 'admin' tenant.
* In the OpenStack Dashboard, click the 'Project' tab.
* Switch to admin tenant if needed.
* Open 'Murano' tab.
* Click the 'Images' menu.
* Click 'Mark Image'. The Image registration window displays.
* Select the Linux image with Murano Agent.
* In the 'Title' field, set title for this image.
* Select the 'Generic Linux' type.
* Click 'Mark'.
Murano is ready for testing.

20
pages/user-guide/health-checks/0630-heat-prepare-test.rst Normal file
View File

@ -0,0 +1,20 @@
Preparing Heat for Testing
+++++++++++++++++++++++++++
The platform tests are run in the tenant you've specified in
'OpenStack Settings' tab during OpenStack installation. By default that is
'admin' tenant. Perform the following actions under that tenant to prepare Heat
for testing of its autoscaling feature:
1. Download the following image of Linux Fedora with pre-installed
cloud-init and heat-cfntools packages:
http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F17-x86_64-cfntools.qcow2
2. Then upload the image into OpenStack Image Service (Glance)
into 'admin' tenant and name it 'F17-x86_64-cfntools'.
Now Heat autoscaling is ready for testing. Note that this test creates a stack
with two instances of Linux Fedora and it may fail if Compute node doesn't
have enough resources.

260
pages/user-guide/health-checks/0640-platform-test-details.rst Normal file
View File

@ -0,0 +1,260 @@
Platform Tests Details
++++++++++++++++++++++
.. topic:: Hadoop cluster operations
Test checks that Savanna can launch a Hadoop cluster
using the Vanilla plugin.
Target component: Savanna
Scenario:
1. Create a flavor for Savanna VMs.
2. Create a node group template for JobTracker and NameNode.
3. Create a cluster template using the node group template.
4. List current node group templates.
5. List current cluster templates.
6. Launch a Hadoop cluster with the created cluster template.
7. Check the launched Hadoop cluster is up by accessing web interfaces of
the appropriate components (JobTracker, NameNode, TaskTracker, DataNode).
8. Terminate the launched cluster.
9. Delete the created cluster template.
10. Delete the created node group templates.
11. Delete the created flavor.
For more information, see:
`Savanna documentation <http://savanna.readthedocs.org/en/0.3/>`_
.. topic:: Typical stack actions: create, update, delete, show details, etc
The test verifies that the Heat service can create, update and delete a stack
and show details of the stack and its resources, events and template.
Target component: Heat
Scenario:
1. Create a stack.
2. Wait for the stack status to change to 'CREATE_COMPLETE'.
3. Get the details of the created stack by its name.
4. Get the resources list of the created stack.
5. Get the details of the stack resource.
6. Get the events list of the created stack.
7. Get the details of the stack event.
8. Update the stack.
9. Wait for the stack to update.
10. Get the stack template details.
11. Get the resources list of the updated stack.
12. Delete the stack.
13. Wait for the stack to be deleted.
.. topic:: Check stack autoscaling
The test verifies that the Heat service can scale the stack capacity
up and down automatically according to the current conditions.
Target component: Heat
Scenario:
1. Image with cfntools package should be imported.
2. Create a flavor.
3. Create a keypair.
4. Save generated private key to file on Controller node.
5. Create a security group.
6. Create a stack.
7. Wait for the stack status to change to 'CREATE_COMPLETE'.
8. Create a floating ip.
9. Assign the floating ip to the instance of the stack.
10. Wait for cloud_init procedure to be completed on the instance.
11. Load the instance CPU to initiate the stack scaling up.
12. Wait for the 2nd instance to be launched.
13. Release the instance CPU to initiate the stack scaling down.
14. Wait for the 2nd instance to be terminated.
15. Delete the file with private key.
16. Delete the stack.
17. Wait for the stack to be deleted.
.. topic:: Check stack rollback
The test verifies that the Heat service can rollback the stack
if its creation failed.
Target component: Heat
Scenario:
1. Start stack creation with rollback enabled.
2. Verify the stack appears with status 'CREATE_IN_PROGRESS'.
3. Wait for the stack to be deleted in result of rollback after
expiration of timeout defined in WaitHandle resource
of the stack.
4. Verify the instance of the stack has been deleted.
.. topic:: Murano environment with AD service deployment
The test verifies that the Murano service can create and deploy the Active Directory service.
Target component: Murano
Scenario:
1. Check Windows Server 2012 image in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service AD.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status
8. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`_
.. topic:: Murano environment with ASP.NET application service deployment
The test verifies that the Murano service can create and deploy the ASP.NET service.
Target component: Murano
Scenario:
1. Check Windows Server 2012 image in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service ASPNet.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status
8. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`_
.. topic:: Murano environment with IIS service deployment
The test verifies that the Murano service can create and deploy the IIS service.
Target component: Murano
Scenario:
1. Check Windows Server 2012 image in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service IIS.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status
8. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`_
.. topic:: Murano environment with SQL service deployment
The test verifies that the Murano service can create and deploy the SQL service.
Target component: Murano
Scenario:
1. Check Windows Server 2012 image in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service SQL.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status
8. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`_
.. topic:: Murano environment with SQL Cluster service deployment
The test verifies that the Murano service can create and deploy the SQL Cluster service.
Target component: Murano
Scenario:
1. Check Windows Server 2012 image in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service AD.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status.
8. Send request to create session for environment.
9. Send request to create service SQL cluster.
10. Request to deploy session..
11. Checking environment status.
12. Checking deployments status.
13. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`
.. topic:: Murano environment with Demo service deployment
The test verifies that the Murano service can create and deploy the Demo service.
Target component: Murano
Scenario:
1. Check image for Demo service in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service Demo.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status.
8. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`
.. topic:: Murano environment with Linux Telnet service deployment
The test verifies that the Murano service can create and deploy the Linux Telnet service.
Target component: Murano
Scenario:
1. Check image for Linux Telnet service in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service Linux Telnet.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status.
8. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`
.. topic:: Murano environment with Linux Apache service deployment
The test verifies that the Murano service can create and deploy the Linux Apache service.
Target component: Murano
Scenario:
1. Check image for Linux Apache service in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service Linux Apache.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status.
8. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`_

596
pages/user-guide/post-install-healthchecks.rst
View File

@ -1,590 +1,10 @@
.. raw:: pdf
PageBreak
.. include:: /pages/user-guide/health-checks/0100-intro-health-checks.rst
.. include:: /pages/user-guide/health-checks/0120-benefits.rst
.. include:: /pages/user-guide/health-checks/0200-run-tests.rst
.. include:: /pages/user-guide/health-checks/0300-test-fails.rst
.. include:: /pages/user-guide/health-checks/0400-sanity-tests-about.rst
.. include:: /pages/user-guide/health-checks/0410-functional-tests-about.rst
.. include:: /pages/user-guide/health-checks/0500-addtional-checks-intro.rst
.. include:: /pages/user-guide/health-checks/0600-platform-tests-intro.rst
.. index:: Fuel UI: Post-Deployment Check
.. _Post-Deployment-Check:
Post-Deployment Check
=====================
.. contents :local:
On occasion, even a successful deployment may result in some OpenStack
components not working correctly. If this happens, Fuel offers the ability
to perform post-deployment checks to verify operations. Part of Fuel's goal
is to provide easily accessible status information about the most commonly
used components and the most recently performed actions. To perform these
checks you will use Sanity and Functional checks, as described below:
**Sanity Checks**
Reveal whether the overall system is functional.
If these tests fail, you probably need to restart some services to operate OpenStack.
**Functional Checks**
Dive in a little deeper and reveal networking, system-requirements,
functionality issues.
Sanity Checks will likely be the point on which the success of your
deployment pivots, but it is critical to pay close attention to all
information collected from theses tests. Another way to look at these tests
is by their names.
Benefits
--------
* Using post-deployment checks helps you identify potential issues which
may impact the health of a deployed system.
* All post-deployment checks provide detailed descriptions about failed
operations and tell you which component or components are not working
properly.
* Previously, performing these checks manually would have consumed a
great deal of time. Now, with these checks the process will take only a
few minutes.
* Aside from verifying that everything is working correctly, the process
will also determine how quickly your system works.
* Post-deployment checks continue to be useful, for example after
sizable changes are made in the system you can use the checks to
determine if any new failure points have been introduced.
Running Post-Deployment Checks
------------------------------
Now, let`s take a closer look on what should be done to execute the tests and
to understand if something is wrong with your OpenStack environment.
.. image:: /_images/001-health-check-tab.jpg
:align: center
:width: 100%
As you can see on the image above, the Fuel UI now contains a ``Health Check``
tab, indicated by the Heart icon.
All of the post-deployment checks are displayed on this tab. If your
deployment was successful, you will see a list of tests this show a green
Thumbs Up in the last column. The Thumb indicates the status of the
component. If you see a detailed message and a Thumbs Down, that
component has failed in some manner, and the details will indicate where the
failure was detected. All tests can be run on different environments, which
you select on main page of Fuel UI. You can run checks in parallel on
different environments.
Each test contains information on its estimated and actual duration. There is
information included about test processing time from in-house testing and
indicate this in each test. Note that average times are listed from the slowest
to the fastest systems tested, so your results may vary.
Once a test is complete, the results will appear in the Status column. If
there was an error during the test, the you will see the error message
below the test name. To assist in troubleshooting, the test
scenario is displayed under the failure message and the failed step is
highlighted. You will find more detailed information on these tests later in
this section.
An actual test run looks like this:
.. image:: /_images/002-health-check-results.jpg
:align: center
:width: 100%
What To Do When a Test Fails
----------------------------
If a test fails, there are several ways to investigate the problem. You may
prefer to start in Fuel UI, since its feedback is directly related to the
health of the deployment. To do so, start by checking the following:
* Under the `Health Check` tab
* In the OpenStack Dashboard
* In the test execution logs (in Environment Logs)
* In the individual OpenStack components' logs
Certainly there are many different conditions that can lead to system
breakdowns, but there are some simple items that can be examined before you
start digging deeply. The most common issues include:
* Not all OpenStack services are running
* Some defined quota has been exceeded
* Something has broken in the network configuration
* A general lack of resources (memory/disk space)
The first thing to be done is to ensure all OpenStack services are up and
running. To do this, you can run the sanity test set or execute the following
command on your Controller node::
nova-manage service list
If any service is off (has “XXX” status), you can restart it using this command::
service openstack-<service name> restart
If all services are on, but you`re still experiencing some issues, you can
gather information from OpenStack Dashboard (exceeded number of instances,
fixed IPs, etc). You may also read the logs generated by tests which are
stored in Logs -> Fuel Master -> Health Check and check if any operation is
in ERROR status. If it looks like the last item, you may have underprovisioned
our environment and should check your math and your project requirements.
Sanity Tests Description
------------------------
Sanity checks work by sending a query to all OpenStack components to get a
response back from them. Many of these tests are simple in that they ask
each service for a list of its associated objects and then waits for a
response. The response can be something, nothing, an error, or a timeout,
so there are several ways to determine if a service is up. The following list
includes the suite of sanity tests implemented:
* Instance list availability
* Images list availability
* Volume list availability
* Snapshots list availability
* Flavor list availability
* Limits list availability
* Services list availability
* User list availability
* Stack list availability
* Check all the services execute normally
* Check Internet connectivity from a compute
* Check DNS resolution on a compute
* Murano environment and service creation, listing and deletion
* Networks availability
Functional Tests Description
----------------------------
Functional tests verify how your system handles basic OpenStack operations
under normal circumstances.
The Functional Test series gives you information about the speed of your environment
and runs timeout tests.
All tests use the basic OpenStack services (Nova, Glance, Keystone, Cinder, etc)
so, if any of these are inactive, the test using it will fail.
You should run all sanity checks before running the functional checks
to verify that all services are alive.
This helps ensure that you do not get false negatives.
The following is a description of each sanity test available:
* Create instance flavor
* Create instance volume
* Launch instance, create snapshot, launch instance from snapshot
* Keypair creation
* Security group creation
* Check networks parameters
* Launch instance
* Assign floating IP
* Check that VM is accessible via floating IP address
* Check network connectivity from instance via floating IP
* Check network connectivity from instance without floating IP
* User creation and authentication in Horizon
Additional Checks
-----------------
If you have installed OpenStack to use a High Availability (HA) architecture
or have installed related OpenStack projects like Savanna or Murano,
additional tests will be shown. The following are the tests available
in HA mode:
* Check data replication over mysql
* Check amount of tables in os databases is the same on each node
* Check mysql environment state
* Check galera environment state
* RabbitMQ availability
Savanna and Murano tests are included in Platform Tests and are
described in the next section.
.. _platform-tests-label:
Platform Tests Description
--------------------------
Platform tests verify basic functionality of Heat, Savanna and Murano
services.
Typically, preparation for Savanna testing is a lengthy process that
involves several manual configuration steps.
Preparing Savanna for Testing
+++++++++++++++++++++++++++++
The platform tests are run in the tenant you've specified in
'OpenStack Settings' tab during OpenStack installation. By default that is
'admin' tenant. Perform in the that tenant the following actions:
1. Configure security groups in the 'admin' tenant for post-deployment checks.
See :ref:`savanna-deployment-label` for the details.
2. Get an image with Hadoop for Savanna and register it with Savanna.
* First download the following image:
http://savanna-files.mirantis.com/savanna-0.3-vanilla-1.2.1-ubuntu-13.04.qcow2
* Then upload the image into OpenStack Image Service (Glance) into
'admin' tenant and name it 'savanna'.
* In OpenStack Dashboard (Horizon) access 'Savanna' tab.
* Switch to 'admin' tenant if you are not in it already.
* Go to the ‘Image Registry’ menu. Here push ‘Register Image’ button.
Image registration window will open up.
* Select the image you’ve just uploaded.
* Set username to ‘ubuntu’
* For tags, pick ‘vanilla’ plugin and ‘1.2.1’ version and press
‘Add all’ button.
* Finally push ‘Done’ button
After the steps above are done, the Savanna is ready to be tested.
Preparing Murano for Testing
+++++++++++++++++++++++++++++
The platform tests are run in the tenant you've specified in
'OpenStack Settings' tab during OpenStack installation.
The 'admin' tenant is selected by default.
To prepare Murano for Windows-based services deployment testing:
1. Add Windows based image to Murano:
* Create a Windows image with Murano agent.
See `Murano documentation (Windows Image Builder) <http://murano-docs.github.io/latest/administrators-guide/content/ch03.html>`_
(Please note, the Murano Image Builder documentation referenced here cannot guarantee success with image creation and could be outdated)
* Upload the image to the OpenStack Image Service (Glance) into the 'admin' tenant.
* In the OpenStack Dashboard, click the 'Project' tab.
* Switch to admin tenant if needed.
* Open 'Murano' tab.
* Click the 'Images' menu.
* Click 'Mark Image'. The Image registration window displays.
* Select the Windows image with Murano agent.
* In the 'Title' field, set title for this image.
* Select the 'Windows Server 2012' type.
* Click 'Mark'.
2. Add Linux based image to Murano:
* Create a Linux image with Murano agent.
See `Murano documentation (Linux Image Builder) <http://murano-docs.github.io/latest/administrators-guide/content/ch04.html>`_
(Please note, the Murano Image Builder documentation referenced here cannot guarantee success with image creation and could be outdated)
* Upload the image to the OpenStack Image Service (Glance) into the 'admin' tenant.
* In the OpenStack Dashboard, click the 'Project' tab.
* Switch to admin tenant if needed.
* Open 'Murano' tab.
* Click the 'Images' menu.
* Click 'Mark Image'. The Image registration window displays.
* Select the Linux image with Murano Agent.
* In the 'Title' field, set title for this image.
* Select the 'Generic Linux' type.
* Click 'Mark'.
Murano is ready for testing.
Preparing Heat for Testing
+++++++++++++++++++++++++++
The platform tests are run in the tenant you've specified in
'OpenStack Settings' tab during OpenStack installation. By default that is
'admin' tenant. Perform the following actions under that tenant to prepare Heat
for testing of its autoscaling feature:
1. Download the following image of Linux Fedora with pre-installed
cloud-init and heat-cfntools packages:
http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F17-x86_64-cfntools.qcow2
2. Then upload the image into OpenStack Image Service (Glance)
into 'admin' tenant and name it 'F17-x86_64-cfntools'.
Now Heat autoscaling is ready for testing. Note that this test creates a stack
with two instances of Linux Fedora and it may fail if Compute node doesn't
have enough resources.
Platform Tests Details
++++++++++++++++++++++
.. topic:: Hadoop cluster operations
Test checks that Savanna can launch a Hadoop cluster
using the Vanilla plugin.
Target component: Savanna
Scenario:
1. Create a flavor for Savanna VMs.
2. Create a node group template for JobTracker and NameNode.
3. Create a cluster template using the node group template.
4. List current node group templates.
5. List current cluster templates.
6. Launch a Hadoop cluster with the created cluster template.
7. Check the launched Hadoop cluster is up by accessing web interfaces of
the appropriate components (JobTracker, NameNode, TaskTracker, DataNode).
8. Terminate the launched cluster.
9. Delete the created cluster template.
10. Delete the created node group templates.
11. Delete the created flavor.
For more information, see:
`Savanna documentation <http://savanna.readthedocs.org/en/0.3/>`_
.. topic:: Typical stack actions: create, update, delete, show details, etc
The test verifies that the Heat service can create, update and delete a stack
and show details of the stack and its resources, events and template.
Target component: Heat
Scenario:
1. Create a stack.
2. Wait for the stack status to change to 'CREATE_COMPLETE'.
3. Get the details of the created stack by its name.
4. Get the resources list of the created stack.
5. Get the details of the stack resource.
6. Get the events list of the created stack.
7. Get the details of the stack event.
8. Update the stack.
9. Wait for the stack to update.
10. Get the stack template details.
11. Get the resources list of the updated stack.
12. Delete the stack.
13. Wait for the stack to be deleted.
.. topic:: Check stack autoscaling
The test verifies that the Heat service can scale the stack capacity
up and down automatically according to the current conditions.
Target component: Heat
Scenario:
1. Image with cfntools package should be imported.
2. Create a flavor.
3. Create a keypair.
4. Save generated private key to file on Controller node.
5. Create a security group.
6. Create a stack.
7. Wait for the stack status to change to 'CREATE_COMPLETE'.
8. Create a floating ip.
9. Assign the floating ip to the instance of the stack.
10. Wait for cloud_init procedure to be completed on the instance.
11. Load the instance CPU to initiate the stack scaling up.
12. Wait for the 2nd instance to be launched.
13. Release the instance CPU to initiate the stack scaling down.
14. Wait for the 2nd instance to be terminated.
15. Delete the file with private key.
16. Delete the stack.
17. Wait for the stack to be deleted.
.. topic:: Check stack rollback
The test verifies that the Heat service can rollback the stack
if its creation failed.
Target component: Heat
Scenario:
1. Start stack creation with rollback enabled.
2. Verify the stack appears with status 'CREATE_IN_PROGRESS'.
3. Wait for the stack to be deleted in result of rollback after
expiration of timeout defined in WaitHandle resource
of the stack.
4. Verify the instance of the stack has been deleted.
.. topic:: Murano environment with AD service deployment
The test verifies that the Murano service can create and deploy the Active Directory service.
Target component: Murano
Scenario:
1. Check Windows Server 2012 image in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service AD.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status
8. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`_
.. topic:: Murano environment with ASP.NET application service deployment
The test verifies that the Murano service can create and deploy the ASP.NET service.
Target component: Murano
Scenario:
1. Check Windows Server 2012 image in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service ASPNet.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status
8. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`_
.. topic:: Murano environment with IIS service deployment
The test verifies that the Murano service can create and deploy the IIS service.
Target component: Murano
Scenario:
1. Check Windows Server 2012 image in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service IIS.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status
8. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`_
.. topic:: Murano environment with SQL service deployment
The test verifies that the Murano service can create and deploy the SQL service.
Target component: Murano
Scenario:
1. Check Windows Server 2012 image in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service SQL.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status
8. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`_
.. topic:: Murano environment with SQL Cluster service deployment
The test verifies that the Murano service can create and deploy the SQL Cluster service.
Target component: Murano
Scenario:
1. Check Windows Server 2012 image in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service AD.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status.
8. Send request to create session for environment.
9. Send request to create service SQL cluster.
10. Request to deploy session..
11. Checking environment status.
12. Checking deployments status.
13. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`
.. topic:: Murano environment with Demo service deployment
The test verifies that the Murano service can create and deploy the Demo service.
Target component: Murano
Scenario:
1. Check image for Demo service in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service Demo.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status.
8. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`
.. topic:: Murano environment with Linux Telnet service deployment
The test verifies that the Murano service can create and deploy the Linux Telnet service.
Target component: Murano
Scenario:
1. Check image for Linux Telnet service in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service Linux Telnet.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status.
8. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`
.. topic:: Murano environment with Linux Apache service deployment
The test verifies that the Murano service can create and deploy the Linux Apache service.
Target component: Murano
Scenario:
1. Check image for Linux Apache service in glance.
2. Send request to create environment.
3. Send request to create session for environment.
4. Send request to create service Linux Apache.
5. Request to deploy session.
6. Checking environment status.
7. Checking deployments status.
8. Send request to delete environment.
For more infromation, see:
`Murano documentation <https://wiki.openstack.org/wiki/Murano#Documentation>`_

107
pages/user-guide/troubleshooting-ug/network-issues.rst
View File

@ -1,104 +1,3 @@
.. raw:: pdf
PageBreak
.. index:: Fuel UI: Network Issues
Network Issues
==============
Fuel has the built-in capability to run a network check before or after
OpenStack deployment. The network check includes tests for connectivity between
nodes via configured VLANs on configured host interfaces. Additionally, checks
for an unexpected DHCP server are done to ensure outside DHCP servers will not
interfere with deployment. The image below shows a sample result of the check.
If there are errors, it is either in your configuration of interfaces or
possibly the VLAN tagging feature is disabled on your switch port.
.. image:: /_images/net_verify_failure.jpg
:align: center
On VirtualBox
-------------
The scripts provided for quick Fuel setup create 3 host-interface adapters.
Basically, networking works as if you have 3 switches, with one connected
to a VM network interface. It means that there is only L2 connectivity between
VMs on interfaces with the same name. If you try to move, for example,
the management network to `eth1` on Controller node, and the
same network to `eth2` on the Compute, then there will be no connectivity
between OpenStack services, despite being configured to exist on the same
VLAN. It is very easy to validate network settings prior to deployment by
clicking the "Verify Networks" button.
If you need to access the OpenStack REST API over Public network, VNC console
of VMs, Horizon in HA mode or VMs, refer to this section:
:ref:`access_to_public_net`.
Timeout In Connection to OpenStack API From Client Applications
---------------------------------------------------------------
If you use Java, Python or any other code to work with OpenStack API, all
connections should be done over OpenStack Public network. To explain why we
can not use Fuel network, let's try to run nova client with debug
option enabled::
[root@controller-6 ~]# nova --debug list
REQ: curl -i http://192.168.0.2:5000/v2.0/tokens -X POST -H "Content-Type: appli
cation/json" -H "Accept: application/json" -H "User-Agent: python-novaclient" -d
'{"auth": {"tenantName": "admin", "passwordCredentials": {"username": "admin",
"password": "admin"}}}'
INFO (connectionpool:191) Starting new HTTP connection (1): 192.168.0.2
DEBUG (connectionpool:283) "POST /v2.0/tokens HTTP/1.1" 200 2702
RESP: [200] {'date': 'Tue, 06 Aug 2013 13:01:05 GMT', 'content-type': 'applicati
on/json', 'content-length': '2702', 'vary': 'X-Auth-Token'}
RESP BODY: {"access": {"token": {"issued_at": "2013-08-06T13:01:05.616481", "exp
ires": "2013-08-07T13:01:05Z", "id": "c321cd823c8a4852aea4b870a03c8f72", "tenant
": {"description": "admin tenant", "enabled": true, "id": "8eee400f7a8a4f35b7a92
bc6cb54de42", "name": "admin"}}, "serviceCatalog": [{"endpoints": [{"adminURL":
"http://192.168.0.2:8774/v2/8eee400f7a8a4f35b7a92bc6cb54de42", "region": "Region
One", "internalURL": "http://192.168.0.2:8774/v2/8eee400f7a8a4f35b7a92bc6cb54de4
2", "id": "6b9563c1e37542519e4fc601b994f980", "publicURL": "http://172.16.1.2:87
74/v2/8eee400f7a8a4f35b7a92bc6cb54de42"}], "endpoints_links": [], "type": "compu
te", "name": "nova"}, {"endpoints": [{"adminURL": "http://192.168.0.2:8080", "re
gion": "RegionOne", "internalURL": "http://192.168.0.2:8080", "id": "4db0e11de35
74c889179f499f1e53c7e", "publicURL": "http://172.16.1.2:8080"}], "endpoints_link
s": [], "type": "s3", "name": "swift_s3"}, {"endpoints": [{"adminURL": "http://1
92.168.0.2:9292", "region": "RegionOne", "internalURL": "http://192.168.0.2:9292
", "id": "960a3ad83e4043bbbc708733571d433b", "publicURL": "http://172.16.1.2:929
2"}], "endpoints_links": [], "type": "image", "name": "glance"}, {"endpoints": [
{"adminURL": "http://192.168.0.2:8776/v1/8eee400f7a8a4f35b7a92bc6cb54de42", "reg
ion": "RegionOne", "internalURL": "http://192.168.0.2:8776/v1/8eee400f7a8a4f35b7
a92bc6cb54de42", "id": "055edb2aface49c28576347a8c2a5e35", "publicURL": "http://
172.16.1.2:8776/v1/8eee400f7a8a4f35b7a92bc6cb54de42"}], "endpoints_links": [], "
type": "volume", "name": "cinder"}, {"endpoints": [{"adminURL": "http://192.168.
0.2:8773/services/Admin", "region": "RegionOne", "internalURL": "http://192.168.
0.2:8773/services/Cloud", "id": "1e5e51a640f94e60aed0a5296eebdb51", "publicURL":
"http://172.16.1.2:8773/services/Cloud"}], "endpoints_links": [], "type": "ec2"
, "name": "nova_ec2"}, {"endpoints": [{"adminURL": "http://192.168.0.2:8080/",
"region": "RegionOne", "internalURL": "http://192.168.0.2:8080/v1/AUTH_8eee400f
7a8a4f35b7a92bc6cb54de42", "id": "081a50a3c9fa49719673a52420a87557", "publicURL
": "http://172.16.1.2:8080/v1/AUTH_8eee400f7a8a4f35b7a92bc6cb54de42"}], "endpoi
nts_links": [], "type": "object-store", "name": "swift"}, {"endpoints": [{"admi
nURL": "http://192.168.0.2:35357/v2.0", "region": "RegionOne", "internalURL": "
http://192.168.0.2:5000/v2.0", "id": "057a7f8e9a9f4defb1966825de957f5b", "publi
cURL": "http://172.16.1.2:5000/v2.0"}], "endpoints_links": [], "type": "identit
y", "name": "keystone"}], "user": {"username": "admin", "roles_links": [], "id"
: "717701504566411794a9cfcea1a85c1f", "roles": [{"name": "admin"}], "name": "ad
min"}, "metadata": {"is_admin": 0, "roles": ["90a1f4f29aef48d7bce3ada631a54261"
]}}}
REQ: curl -i http://172.16.1.2:8774/v2/8eee400f7a8a4f35b7a92bc6cb54de42/servers/
detail -X GET -H "X-Auth-Project-Id: admin" -H "User-Agent: python-novaclient" -
H "Accept: application/json" -H "X-Auth-Token: c321cd823c8a4852aea4b870a03c8f72"
INFO (connectionpool:191) Starting new HTTP connection (1): 172.16.1.2
Even though initial connection was in 192.168.0.2, the client tries to
access the Public network for Nova API. The reason is because Keystone returns
the list of OpenStack services URLs, and for production-grade deployments it
is required to access services over public network.
.. seealso:: :ref:`access_to_public_net` if you want to configure the
installation on VirtualBox and fix issues like the one above.
.. include:: /pages/user-guide/troubleshooting-ug/network-issues/0100-network-check-baremetal.rst
.. include:: /pages/user-guide/troubleshooting-ug/network-issues/0150-network-check-virtualbox.rst
.. include:: /pages/user-guide/troubleshooting-ug/network-issues/0200-openstack-api-timeout.rst

19
pages/user-guide/troubleshooting-ug/network-issues/0100-network-check-baremetal.rst Normal file
View File

@ -0,0 +1,19 @@
.. raw:: pdf
PageBreak
.. index:: Fuel UI: Network Issues
Network Issues
==============
Fuel has the built-in capability to run a network check before or after
OpenStack deployment. The network check includes tests for connectivity between
nodes via configured VLANs on configured host interfaces. Additionally, checks
for an unexpected DHCP server are done to ensure outside DHCP servers will not
interfere with deployment. The image below shows a sample result of the check.
If there are errors, it is either in your configuration of interfaces or
possibly the VLAN tagging feature is disabled on your switch port.
.. image:: /_images/net_verify_failure.jpg
:align: center

15
pages/user-guide/troubleshooting-ug/network-issues/0150-network-check-virtualbox.rst Normal file
View File

@ -0,0 +1,15 @@
On VirtualBox
-------------
The scripts provided for quick Fuel setup create 3 host-interface adapters.
Basically, networking works as if you have 3 switches, with one connected
to a VM network interface. It means that there is only L2 connectivity between
VMs on interfaces with the same name. If you try to move, for example,
the management network to `eth1` on Controller node, and the
same network to `eth2` on the Compute, then there will be no connectivity
between OpenStack services, despite being configured to exist on the same
VLAN. It is very easy to validate network settings prior to deployment by
clicking the "Verify Networks" button.
If you need to access the OpenStack REST API over Public network, VNC console
of VMs, Horizon in HA mode or VMs, refer to this section:
:ref:`access_to_public_net`.

68
pages/user-guide/troubleshooting-ug/network-issues/0200-openstack-api-timeout.rst Normal file
View File

@ -0,0 +1,68 @@
Timeout In Connection to OpenStack API From Client Applications
---------------------------------------------------------------
If you use Java, Python or any other code to work with OpenStack API, all
connections should be done over OpenStack Public network. To explain why we
can not use Fuel network, let's try to run nova client with debug
option enabled::
[root@controller-6 ~]# nova --debug list
REQ: curl -i http://192.168.0.2:5000/v2.0/tokens -X POST -H "Content-Type: appli
cation/json" -H "Accept: application/json" -H "User-Agent: python-novaclient" -d
'{"auth": {"tenantName": "admin", "passwordCredentials": {"username": "admin",
"password": "admin"}}}'
INFO (connectionpool:191) Starting new HTTP connection (1): 192.168.0.2
DEBUG (connectionpool:283) "POST /v2.0/tokens HTTP/1.1" 200 2702
RESP: [200] {'date': 'Tue, 06 Aug 2013 13:01:05 GMT', 'content-type': 'applicati
on/json', 'content-length': '2702', 'vary': 'X-Auth-Token'}
RESP BODY: {"access": {"token": {"issued_at": "2013-08-06T13:01:05.616481", "exp
ires": "2013-08-07T13:01:05Z", "id": "c321cd823c8a4852aea4b870a03c8f72", "tenant
": {"description": "admin tenant", "enabled": true, "id": "8eee400f7a8a4f35b7a92
bc6cb54de42", "name": "admin"}}, "serviceCatalog": [{"endpoints": [{"adminURL":
"http://192.168.0.2:8774/v2/8eee400f7a8a4f35b7a92bc6cb54de42", "region": "Region
One", "internalURL": "http://192.168.0.2:8774/v2/8eee400f7a8a4f35b7a92bc6cb54de4
2", "id": "6b9563c1e37542519e4fc601b994f980", "publicURL": "http://172.16.1.2:87
74/v2/8eee400f7a8a4f35b7a92bc6cb54de42"}], "endpoints_links": [], "type": "compu
te", "name": "nova"}, {"endpoints": [{"adminURL": "http://192.168.0.2:8080", "re
gion": "RegionOne", "internalURL": "http://192.168.0.2:8080", "id": "4db0e11de35
74c889179f499f1e53c7e", "publicURL": "http://172.16.1.2:8080"}], "endpoints_link
s": [], "type": "s3", "name": "swift_s3"}, {"endpoints": [{"adminURL": "http://1
92.168.0.2:9292", "region": "RegionOne", "internalURL": "http://192.168.0.2:9292
", "id": "960a3ad83e4043bbbc708733571d433b", "publicURL": "http://172.16.1.2:929
2"}], "endpoints_links": [], "type": "image", "name": "glance"}, {"endpoints": [
{"adminURL": "http://192.168.0.2:8776/v1/8eee400f7a8a4f35b7a92bc6cb54de42", "reg
ion": "RegionOne", "internalURL": "http://192.168.0.2:8776/v1/8eee400f7a8a4f35b7
a92bc6cb54de42", "id": "055edb2aface49c28576347a8c2a5e35", "publicURL": "http://
172.16.1.2:8776/v1/8eee400f7a8a4f35b7a92bc6cb54de42"}], "endpoints_links": [], "
type": "volume", "name": "cinder"}, {"endpoints": [{"adminURL": "http://192.168.
0.2:8773/services/Admin", "region": "RegionOne", "internalURL": "http://192.168.
0.2:8773/services/Cloud", "id": "1e5e51a640f94e60aed0a5296eebdb51", "publicURL":
"http://172.16.1.2:8773/services/Cloud"}], "endpoints_links": [], "type": "ec2"
, "name": "nova_ec2"}, {"endpoints": [{"adminURL": "http://192.168.0.2:8080/",
"region": "RegionOne", "internalURL": "http://192.168.0.2:8080/v1/AUTH_8eee400f
7a8a4f35b7a92bc6cb54de42", "id": "081a50a3c9fa49719673a52420a87557", "publicURL
": "http://172.16.1.2:8080/v1/AUTH_8eee400f7a8a4f35b7a92bc6cb54de42"}], "endpoi
nts_links": [], "type": "object-store", "name": "swift"}, {"endpoints": [{"admi
nURL": "http://192.168.0.2:35357/v2.0", "region": "RegionOne", "internalURL": "
http://192.168.0.2:5000/v2.0", "id": "057a7f8e9a9f4defb1966825de957f5b", "publi
cURL": "http://172.16.1.2:5000/v2.0"}], "endpoints_links": [], "type": "identit
y", "name": "keystone"}], "user": {"username": "admin", "roles_links": [], "id"
: "717701504566411794a9cfcea1a85c1f", "roles": [{"name": "admin"}], "name": "ad
min"}, "metadata": {"is_admin": 0, "roles": ["90a1f4f29aef48d7bce3ada631a54261"
]}}}
REQ: curl -i http://172.16.1.2:8774/v2/8eee400f7a8a4f35b7a92bc6cb54de42/servers/
detail -X GET -H "X-Auth-Project-Id: admin" -H "User-Agent: python-novaclient" -
H "Accept: application/json" -H "X-Auth-Token: c321cd823c8a4852aea4b870a03c8f72"
INFO (connectionpool:191) Starting new HTTP connection (1): 172.16.1.2
Even though initial connection was in 192.168.0.2, the client tries to
access the Public network for Nova API. The reason is because Keystone returns
the list of OpenStack services URLs, and for production-grade deployments it
is required to access services over public network.
.. seealso:: :ref:`access_to_public_net` if you want to configure the
installation on VirtualBox and fix issues like the one above.