From 67b08719dd485a4c5ba20f961e81c18e125d2544 Mon Sep 17 00:00:00 2001 From: Meg McRoberts Date: Wed, 26 Mar 2014 17:45:14 -0700 Subject: [PATCH] split user guide source into modular files Change-Id: Id8e464114a88c46c138007c78003b20fb2d59adc --- pages/user-guide/custom-attributes.rst | 3 - .../0100-intro-health-checks.rst | 33 + .../health-checks/0120-benefits.rst | 21 + .../health-checks/0200-run-tests.rst | 40 ++ .../health-checks/0300-test-fails.rst | 38 ++ .../health-checks/0400-sanity-tests-about.rst | 25 + .../0410-functional-tests-about.rst | 28 + .../0500-addtional-checks-intro.rst | 16 + .../0600-platform-tests-intro.rst | 15 + .../0610-sahara-prepare-test.rst | 35 + .../0620-murano-prepare-test.rst | 65 ++ .../health-checks/0630-heat-prepare-test.rst | 20 + .../0640-platform-test-details.rst | 260 ++++++++ .../user-guide/post-install-healthchecks.rst | 596 +----------------- .../troubleshooting-ug/network-issues.rst | 107 +--- .../0100-network-check-baremetal.rst | 19 + .../0150-network-check-virtualbox.rst | 15 + .../0200-openstack-api-timeout.rst | 68 ++ 18 files changed, 709 insertions(+), 695 deletions(-) create mode 100644 pages/user-guide/health-checks/0100-intro-health-checks.rst create mode 100644 pages/user-guide/health-checks/0120-benefits.rst create mode 100644 pages/user-guide/health-checks/0200-run-tests.rst create mode 100644 pages/user-guide/health-checks/0300-test-fails.rst create mode 100644 pages/user-guide/health-checks/0400-sanity-tests-about.rst create mode 100644 pages/user-guide/health-checks/0410-functional-tests-about.rst create mode 100644 pages/user-guide/health-checks/0500-addtional-checks-intro.rst create mode 100644 pages/user-guide/health-checks/0600-platform-tests-intro.rst create mode 100644 pages/user-guide/health-checks/0610-sahara-prepare-test.rst create mode 100644 pages/user-guide/health-checks/0620-murano-prepare-test.rst create mode 100644 pages/user-guide/health-checks/0630-heat-prepare-test.rst create mode 100644 pages/user-guide/health-checks/0640-platform-test-details.rst create mode 100644 pages/user-guide/troubleshooting-ug/network-issues/0100-network-check-baremetal.rst create mode 100644 pages/user-guide/troubleshooting-ug/network-issues/0150-network-check-virtualbox.rst create mode 100644 pages/user-guide/troubleshooting-ug/network-issues/0200-openstack-api-timeout.rst diff --git a/pages/user-guide/custom-attributes.rst b/pages/user-guide/custom-attributes.rst index 488db5fb6..d5a4e7070 100644 --- a/pages/user-guide/custom-attributes.rst +++ b/pages/user-guide/custom-attributes.rst @@ -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:: diff --git a/pages/user-guide/health-checks/0100-intro-health-checks.rst b/pages/user-guide/health-checks/0100-intro-health-checks.rst new file mode 100644 index 000000000..cb9594227 --- /dev/null +++ b/pages/user-guide/health-checks/0100-intro-health-checks.rst @@ -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. + diff --git a/pages/user-guide/health-checks/0120-benefits.rst b/pages/user-guide/health-checks/0120-benefits.rst new file mode 100644 index 000000000..03659591f --- /dev/null +++ b/pages/user-guide/health-checks/0120-benefits.rst @@ -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. + diff --git a/pages/user-guide/health-checks/0200-run-tests.rst b/pages/user-guide/health-checks/0200-run-tests.rst new file mode 100644 index 000000000..1a99187eb --- /dev/null +++ b/pages/user-guide/health-checks/0200-run-tests.rst @@ -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% + diff --git a/pages/user-guide/health-checks/0300-test-fails.rst b/pages/user-guide/health-checks/0300-test-fails.rst new file mode 100644 index 000000000..cd1d3656a --- /dev/null +++ b/pages/user-guide/health-checks/0300-test-fails.rst @@ -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- 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. + diff --git a/pages/user-guide/health-checks/0400-sanity-tests-about.rst b/pages/user-guide/health-checks/0400-sanity-tests-about.rst new file mode 100644 index 000000000..7cde17a27 --- /dev/null +++ b/pages/user-guide/health-checks/0400-sanity-tests-about.rst @@ -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 + diff --git a/pages/user-guide/health-checks/0410-functional-tests-about.rst b/pages/user-guide/health-checks/0410-functional-tests-about.rst new file mode 100644 index 000000000..d16e4727d --- /dev/null +++ b/pages/user-guide/health-checks/0410-functional-tests-about.rst @@ -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 + diff --git a/pages/user-guide/health-checks/0500-addtional-checks-intro.rst b/pages/user-guide/health-checks/0500-addtional-checks-intro.rst new file mode 100644 index 000000000..c832ed383 --- /dev/null +++ b/pages/user-guide/health-checks/0500-addtional-checks-intro.rst @@ -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. + diff --git a/pages/user-guide/health-checks/0600-platform-tests-intro.rst b/pages/user-guide/health-checks/0600-platform-tests-intro.rst new file mode 100644 index 000000000..34573012f --- /dev/null +++ b/pages/user-guide/health-checks/0600-platform-tests-intro.rst @@ -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 + diff --git a/pages/user-guide/health-checks/0610-sahara-prepare-test.rst b/pages/user-guide/health-checks/0610-sahara-prepare-test.rst new file mode 100644 index 000000000..6aade8655 --- /dev/null +++ b/pages/user-guide/health-checks/0610-sahara-prepare-test.rst @@ -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. + diff --git a/pages/user-guide/health-checks/0620-murano-prepare-test.rst b/pages/user-guide/health-checks/0620-murano-prepare-test.rst new file mode 100644 index 000000000..c4ac3df10 --- /dev/null +++ b/pages/user-guide/health-checks/0620-murano-prepare-test.rst @@ -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) `_ + + (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) `_ + + (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. + diff --git a/pages/user-guide/health-checks/0630-heat-prepare-test.rst b/pages/user-guide/health-checks/0630-heat-prepare-test.rst new file mode 100644 index 000000000..81bdad18e --- /dev/null +++ b/pages/user-guide/health-checks/0630-heat-prepare-test.rst @@ -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. + diff --git a/pages/user-guide/health-checks/0640-platform-test-details.rst b/pages/user-guide/health-checks/0640-platform-test-details.rst new file mode 100644 index 000000000..f9213270b --- /dev/null +++ b/pages/user-guide/health-checks/0640-platform-test-details.rst @@ -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 `_ + +.. 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 `_ + +.. 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 `_ + +.. 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 `_ + +.. 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 `_ + +.. 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 ` + +.. 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 ` + +.. 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 ` + +.. 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 `_ + diff --git a/pages/user-guide/post-install-healthchecks.rst b/pages/user-guide/post-install-healthchecks.rst index 48b490dea..a71516bd2 100644 --- a/pages/user-guide/post-install-healthchecks.rst +++ b/pages/user-guide/post-install-healthchecks.rst @@ -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- 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) `_ - - (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) `_ - - (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 `_ - -.. 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 `_ - -.. 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 `_ - -.. 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 `_ - -.. 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 `_ - -.. 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 ` - -.. 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 ` - -.. 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 ` - -.. 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 `_ diff --git a/pages/user-guide/troubleshooting-ug/network-issues.rst b/pages/user-guide/troubleshooting-ug/network-issues.rst index 3e2dd3416..d23af35e9 100644 --- a/pages/user-guide/troubleshooting-ug/network-issues.rst +++ b/pages/user-guide/troubleshooting-ug/network-issues.rst @@ -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 diff --git a/pages/user-guide/troubleshooting-ug/network-issues/0100-network-check-baremetal.rst b/pages/user-guide/troubleshooting-ug/network-issues/0100-network-check-baremetal.rst new file mode 100644 index 000000000..3170dae3d --- /dev/null +++ b/pages/user-guide/troubleshooting-ug/network-issues/0100-network-check-baremetal.rst @@ -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 diff --git a/pages/user-guide/troubleshooting-ug/network-issues/0150-network-check-virtualbox.rst b/pages/user-guide/troubleshooting-ug/network-issues/0150-network-check-virtualbox.rst new file mode 100644 index 000000000..7b5f20d5a --- /dev/null +++ b/pages/user-guide/troubleshooting-ug/network-issues/0150-network-check-virtualbox.rst @@ -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`. diff --git a/pages/user-guide/troubleshooting-ug/network-issues/0200-openstack-api-timeout.rst b/pages/user-guide/troubleshooting-ug/network-issues/0200-openstack-api-timeout.rst new file mode 100644 index 000000000..31ffedec4 --- /dev/null +++ b/pages/user-guide/troubleshooting-ug/network-issues/0200-openstack-api-timeout.rst @@ -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.