openstack/fuel-docs
Code Issues Proposed changes

murano docs and 3.2 relase notes

Browse Source 
more wording fixes

trimmed down health checks

updated Murano wording
This commit is contained in:
Matthew Mosesohn 2013-10-15 16:41:05 +04:00
parent f68866a788
commit 043b695d0c
2 changed files with 102 additions and 363 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

78
pages/user-guide/murano.rst Normal file
View File

@ -0,0 +1,78 @@
.. raw:: pdf
PageBreak
.. index:: Murano
Murano Deployment Notes
==================================
.. contents :local:
Overview
--------
Fuel can deploy OpenStack and set up Murano, an open source project designed
to enable Windows virtual machines in OpenStack. Some highlights of Murano
features include:
* Native to OpenStack
* Introduction of abstraction level for Windows Environments
* Support for Availability Zones and Disaster Recovery scenarios
* Use of native Windows features to provide HA solutions
Considerations
--------------
Because Microsoft Windows and other necessary components can only be obtained
directly from Microsoft, Murano is still to some degree a do-it-yourself
project. Fuel is able to configure Murano's dashboard, API, and conductor
services, but you will need to read documention on the steps to set up a
Windows base image. Images can be uploaded via Glance. For information about
creating a Windows image, see `Build Windows Image
<http://murano-docs.github.io/0.2.11/getting-started/content/ch03s03.html>`_.
.. _Installation_Steps:
Murano is installed in Fuel simply by checking the appropriate check box when
configuring your environment. Murano is supported in CentOS and Ubuntu.
.. _Murano_Components:
Murano Components
-----------------
Dashboard
+++++++++
Murano Dashboard can be reached after Fuel deployment as a link within Horizon
Dashboard. You may use the same credentials to log into Murano as you use for
Horizon (via Keystone). From the Murano Dashboard you can deploy configured
Windows images.
Murano API
++++++++++
The Murano API provides the ability manage Windows Services. For further
reading, refer to `Murano API Specification
<http://murano.mirantis.com/content/ch04.html>`_
Conductor
+++++++++
Conductor is the Murano orchestration engine that transformes objects sent by
REST API service (such as Dashboard) into a series of Heat and Murano API
commands.
.. index:: Murano: Troubleshooting
Troubleshooting Murano
----------------------
There are no known issues with deploying Murano at the time of this writing,
but some issues are documented in `Murano Troubleshooting
<http://murano-docs.github.io/0.2.11/getting-started/content/ch05.html>`_.

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

@ -138,148 +138,21 @@ 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
shows what test is used for each service:
includes the suite of sanity tests implemented:
.. topic:: Instance list availability
Test checks that Nova component can return list of instances.
Test scenario:
1. Request list of instances.
2. Check returned list is not empty.
.. topic:: Images list availability
Test checks that Glance component can return list of images.
Test scenario:
1. Request list of images.
2. Check returned list is not empty.
.. topic:: Volume list availability
Test checks that Swift component can return list of volumes.
Test scenario:
1. Request list of volumes.
2. Check returned list is not empty.
.. topic:: Snapshots list availability
Test checks that Glance component can return list of snapshots.
Test scenario:
1. Request list of snapshots.
2. Check returned list is not empty.
.. topic:: Flavor list availability
Test checks that Nova component can return list of flavors.
Test scenario:
1. Request list of flavors.
2. Check returned list is not empty.
.. topic:: Limits list availability
Test checks that Nova component can return list of absolute limits.
Test scenario:
1. Request list of limits.
2. Check response.
.. topic:: Services list availability
Test checks that Nova component can return list of services.
Test scenario:
1. Request list of services.
2. Check returned list is not empty.
.. topic:: User list availability
Test checks that Keystone component can return list of users.
Test scenario:
1. Request list of services.
2. Check returned list is not empty.
.. topic:: Check all the services execute normally
Test checks that all of the expected services are on, meaning the test will
fail if any of the listed services is in “XXX” status.
Test scenario:
1. Connect to a controller via SSH.
2. Execute nova-manage service list command.
3. Check there are no failed services.
.. topic:: Check Internet connectivity from a compute
Test checks that public Internet is available for compute hosts.
Test scenario:
1. Connect to a Compute node via SSH.
2. Execute ping command to IP 8.8.8.8.
3. Check ping can be successfully completed.
.. topic:: Check DNS resolution on a compute
Test checks that DNS is available for compute hosts.
Test scenario:
1. Connect to a Compute node via SSH.
2. Execute host command for the controller IP.
3. Check DNS name can be successfully resolved.
.. topic:: Networks availability
Test checks that Nova component can return list of available networks.
Test scenario:
1. Request list of networks.
2. Check returned list is not empty.
.. topic:: Ports availability
Test checks that Nova component can return list of available ports.
Test scenario:
1. Request list of ports.
2. Check returned list is not empty.
.. topic:: Savanna basic test
Test checks that Savanna can work with templates.
Test scenario:
1. Create a Nova flavor for Savanna VMs.
2. Create a node group template for the TaskTracker and DataNode processes.
3. Create a node group template for the TaskTracker process.
4. Create a node group template for the DataNode process.
5. Create a cluster template using the node group templates.
6. List current node group templates.
7. List current cluster templates.
8. Delete the created cluster template.
9. Delete the created node group templates.
10. Delete the created flavor.
For more information refer to nova cli reference.
* Instance list availability
* Images list availability
* Volume list availability
* Snapshots list availability
* Flavor list availability
* Limits list availability
* Services list availability
* User list availability
* Check all the services execute normally
* Check Internet connectivity from a compute
* Check DNS resolution on a compute
* Networks availability
* Ports availability
Smoke Tests Description
-----------------------
@ -296,225 +169,13 @@ is recommended to run all sanity checks prior to your smoke checks to determine
that all services are alive. This helps ensure that you don't get any false
negatives. The following is a description of each sanity test available:
.. topic:: Flavor creation
Test checks that low requirements flavor can be created.
Target component: Nova
Scenario:
1. Create small-size flavor.
2. Check created flavor has expected name.
3. Check flavor disk has expected size.
For more information refer to nova CLI documentation.
.. topic:: Volume creation
Test checks that a small-sized volume can be created.
Target component: Compute
Scenario:
1. Create a new small-size volume.
2. Wait for "available" volume status.
3. Check response contains "display_name" section.
4. Create instance and wait for "Active" status
5. Attach volume to instance.
6. Check volume status is "in use".
7. Get created volume information by its id.
8. Detach volume from instance.
9. Check volume has "available" status.
10. Delete volume.
If you see that created volume is in ERROR status, it can mean that you`ve
exceeded the maximum number of volumes that can be created. You can check it
on OpenStack dashboard. For more information refer to volume management
instructions.
.. topic:: Instance booting and snapshotting
Test creates a keypair, checks that instance can be booted from default
image, then a snapshot can be created from it and a new instance can be
booted from a snapshot. Test also verifies that instances and images reach
ACTIVE state upon their creation.
Target component: Glance
Scenario:
1. Create new keypair to boot an instance.
2. Boot default image.
3. Make snapshot of created server.
4. Boot another instance from created snapshot.
If you see that created instance is in ERROR status, it can mean that you`ve
exceeded any system requirements limit. The test is using a nano-flavor with
parameters: 64 RAM, 1 GB disk space, 1 virtual CPU presented. For more
information refer to nova cli reference, image management instructions.
.. topic:: Keypair creation
Target component: Nova.
Scenario:
1. Create a new keypair, check if it was created successfully
(check name is expected, response status is 200).
For more information refer to nova cli reference.
.. topic:: Security group creation
Target component: Nova
Scenario:
1. Create security group, check if it was created correctly
(check name is expected, response status is 200).
For more information refer to nova cli reference.
.. topic:: Network parameters check
Target component: Nova
Scenario:
1. Get list of networks.
2. Check seen network labels equal to expected ones.
3. Check seen network ids equal to expected ones.
For more information refer to nova cli reference.
.. topic:: Instance creation
Target component: Nova
Scenario:
1. Create new keypair (if it`s nonexistent yet).
2. Create new sec group (if it`s nonexistent yet).
3. Create instance with usage of created sec group and keypair.
For more information refer to nova cli reference, instance management
instructions.
.. topic:: Floating IP assignment
Target component: Nova
Scenario:
1. Create new keypair (if it`s nonexistent yet).
2. Create new sec group (if it`s nonexistent yet).
3. Create instance with usage of created sec group and keypair.
4. Create new floating IP.
5. Assign floating IP to created instance.
For more information refer to nova cli reference, floating ips management
instructions.
.. topic:: Network connectivity check through floating IP
Target component: Nova
Scenario:
1. Create new keypair (if it`s nonexistent yet).
2. Create new sec group (if it`s nonexistent yet).
3. Create instance with usage of created sec group and keypair.
4. Check connectivity for all floating IPs using ping command.
If this test failed, it`s better to run a network check and verify that all
connections are correct. For more information refer to the Nova CLI reference's
floating IPs management instructions.
.. topic:: User creation and authentication in Horizon
Test creates new user, tenant, user role with admin privileges and logs in
to dashboard.
Target components: Nova, Keystone
Scenario:
1. Create a new tenant.
2. Check tenant was created successfully.
3. Create a new user.
4. Check user was created successfully.
5. Create a new user role.
6. Check user role was created successfully.
7. Perform token authentication.
8. Check authentication was successful.
9. Send authentication request to Horizon.
10. Verify response status is 200.
If this test fails on the authentication step, you should first try opening
the dashboard - it may be unreachable for some reason and then you should
check your network configuration. For more information refer to nova cli
reference.
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. 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.2-vanilla-1.1.2-ubuntu-12.10.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.
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.2.2/>`_
* Flavor creation
* Volume creation
* Instance booting and snapshotting
* Keypair creation
* Security group creation
* Network parameters check
* Instance creation
* Floating IP assignment
* Network connectivity check through floating IP
* User creation and authentication in Horizon