Merge pull request #37 from SvetlanaS/oct18

Added the release notes .rst.
This commit is contained in:
Mike Scherbakov 2013-10-20 10:35:16 -07:00
commit e7eea89b61
11 changed files with 534 additions and 31 deletions

View File

@ -11,13 +11,16 @@
viewBox="0.0 0.0 677.0 617.0"
stroke-miterlimit="10"
id="svg2"
inkscape:version="0.48.4 r9939"
inkscape:version="0.48+devel r12685"
width="100%"
height="100%"
sodipodi:docname="how-it-works_o.svg"
sodipodi:docname="how-it-works.svg"
stroke-linecap="square"
stroke="none"
fill="none">
fill="none"
inkscape:export-filename="C:\Users\Svetlana\Documents\mirantis16 oct\fuel-docs\_images\how-it-works_svg.png"
inkscape:export-xdpi="90"
inkscape:export-ydpi="90">
<metadata
id="metadata189">
<rdf:RDF>
@ -26,7 +29,7 @@
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
@ -42,14 +45,14 @@
inkscape:pageopacity="0"
inkscape:pageshadow="2"
inkscape:window-width="1366"
inkscape:window-height="749"
inkscape:window-height="706"
id="namedview185"
showgrid="false"
inkscape:zoom="0.76499189"
inkscape:cx="154.87188"
inkscape:cy="449.33982"
inkscape:window-x="-4"
inkscape:window-y="-4"
inkscape:window-x="-8"
inkscape:window-y="-8"
inkscape:window-maximized="1"
inkscape:current-layer="g7" />
<clipPath
@ -564,7 +567,7 @@
y="256.44772">RHEL 6.4</tspan></text>
<text
xml:space="preserve"
style="font-size:20px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:PT Sans;-inkscape-font-specification:PT Sans;font-stretch:normal;font-variant:normal"
style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:PT Sans;-inkscape-font-specification:PT Sans"
x="244.35773"
y="293.8266"
id="text3192"
@ -572,7 +575,8 @@
sodipodi:role="line"
id="tspan3194"
x="244.35773"
y="293.8266">RHOS 3.0</tspan></text>
y="293.8266"
style="font-size:17.5px">Ubuntu 12.04</tspan></text>
<text
xml:space="preserve"
style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:PT Sans;-inkscape-font-specification:PT Sans Bold"

Before

Width:  |  Height:  |  Size: 43 KiB

After

Width:  |  Height:  |  Size: 43 KiB

View File

@ -27,6 +27,11 @@ The following Fuel documentation is available in PDF:
A deep dive into the structure of the Fuel OpenStack environment,
network considerations, and deployment options.
* `Release Notes 3.2 <../pdf/Fuel-for-OpenStack-3.2-RelNotes.pdf>`_
The Release Notes provide general information about new features,
fixed issues, and known limitations in Fuel 3.2.
Download an ISO
--------------------------
Use the following link to download the latest Fuel ISO:

View File

@ -19,8 +19,6 @@ Fuel eliminates the need to study these processes. With Fuel, system
administrators can provision an OpenStack single node, as well as
clustered cloud in terms of minutes.
The following diagram describes how Fuel functions:
Deployment Modes
-----------------------------
You can use Fuel for OpenStack to create virtually any OpenStack
@ -56,29 +54,37 @@ You can use Fuel to quickly deploy and manage the OpenStack environment.
Fuel includes the following components:
* **Master Node**
The Fuel Master Node is the lifecycle management application for
deployment and managing OpenStack. It sits outside the OpenStack
environment and services as a control plane for multiple Openstack
envionments.
* **Controller Node**
A controller node that manages the OpenStack environment including
deployment of additional controller and compute nodes, configuring
network settings, and so on. For HA deployments, Mirantis recommends
to deploy at least 3 controller nodes.
* **Compute Node(s)**
A compute node is a server where you run virtual machines and
applications.
* **Storage Node(s)**
Optional component. You can deploy a separate Swift storage node
Mirantis recommends to deploy standalone storage nodes for high
Optional component. You can deploy a separate Swift or Ceph storage
node. Mirantis recommends to deploy standalone storage nodes for high
availability environments.
Fuel Installation Procedures
----------------------------
You must complete the following tasks to install Fuel:
You must complete the following tasks to use Fuel to deploy OpenStack
clouds:
1. Install the Fuel Master Node on physical or virtual hardware using
the Fuel installation image
2. Power on the other nodes to make them accessible for Fuel Master node
3. Deploy the OpenStack environment on the discovered nodes using Fuel
2. Set the other nodes to boot from the network and power them on
to make them accessible for Fuel Master node
3. Assign your desired roles to the discovered nodes using Fuel
UI or CLI.
Fuel is designed to maintain the OpenStack environment while providing

View File

@ -14,12 +14,11 @@ web-site <http://fuel.mirantis.com/redirect-page/>`_.
Fuel supports the following OpenStack releases:
* **Essex**
* **Folsom**
* **Grizzly**
Fuel Master node, CentOS & Ubuntu operating systems for deployment as
an OpenStack nodes host OS, and the Mirantis OpenStack hardened packages.
Fuel provides the following installation options:
* **ISO image**

View File

@ -133,8 +133,8 @@ Mapping logical networks to physical interfaces on servers
Fuel allows you to use different physical interfaces to handle different
types of traffic. When a node is added to the environment, click at the bottom
line of the node icon. In the detailed information window, click the "Network
Configuration" button to open the physical interfaces configuration screen.
line of the node icon. In the detailed information window, click the "Configure
Interfaces" button to open the physical interfaces configuration screen.
.. image:: /_images/network-settings.jpg
:align: center
@ -162,7 +162,8 @@ First of all, you should configure access ports to allow non-tagged PXE booting
connections from all Slave nodes to the Fuel node. We refer this network
as the Fuel network.
By default, the Fuel Master node uses the `eth0` interface to serve PXE
requests on this network.
requests on this network, but this can be changed :ref:`during installation
<Network_Install>` of the Fuel Master node.
So if that's left unchanged, you have to set the switch port for `eth0` of Fuel
Master node to access mode.
We recommend that you use the `eth0` interfaces of all other nodes for PXE booting

View File

@ -8,6 +8,9 @@ Object Storage Deployment
.. TODO(mihgen): we need to rewrite this and add info about Ceph
Fuel currently supports several scenarios to deploy the object storage:
**Glance + Ceph**
Ceph can be used as an object storage option for Glance.
**Glance + filesystem**
By default, Glance uses the file system backend to store virtual machine images.
In this case, you can use any of shared file systems supported by Glance.

View File

@ -0,0 +1,477 @@
.. index:: Release Notes: Fuel 3.2
.. _RelNotes_3.2:
Release Notes for Mirantis OpenStack version 3.2
================================================
.. contents:: :local:
:depth: 1
:backlinks: none
Overview
---------
Mirantis, Inc. is releasing version 3.2 of Mirantis OpenStack.
Mirantis OpenStack is a complete solution that includes three
major components:
* Fuel lifecycle management application
* Mirantis OpenStack hardened packages
* Mirantis Support
These release notes supplement the product documentation and list
enhancements, resolved issues and known issues in this version.
What is Mirantis OpenStack?
------------------------------
Mirantis OpenStack is made up of three items:
* **Fuel for OpenStack**
Fuel is our lifecycle management application that deploys multiple
OpenStack clouds from a single interface and then enables you to
manage those clouds post-deployment. You can add nodes, remove
nodes or even remove an entire cloud and return the resources to
the pool of available resources. Fuel also eases the complexities
of network and storage configuration through an simple to use
graphical user experience. Baked into Fuel are:
* Mirantis reference architectures that weve tested and certified
to ensure that your deployed cloud can scale, is reliable and is
production quality.
* An open and flexible library that enables customers to make
configuration changes that may be more advanced or focused than
the default choices within Fuel. This library also empowers
organizations to fold additional drivers or integrations into
the deployed environment.
* **Mirantis OpenStack hardened packages**
These packages include the core OpenStack projects, updated with
each stable release of OpenStack. Also included are:
* Packages to ensure high availability
* Any defect fixes reported by our customers that may not yet
have been merged into the community source.
* Mirantis driven premium OpenStack projects (e.g. Savanna and Murano)
* Mirantis certified partner plug-ins, drivers and integrations
Another benefit you get from Mirantis OpenStack as compared to some
competitors is our broad support for operating systems, hypervisors
and deployment topologies. We dont restrict your choices to one
OS or one hypervisor type like some of our competitors. In addition,
you can choose the OpenStack roles you want on each available node.
* **Mirantis Support**
In addition, Mirantis OpenStack offers a subscription to our
world-class support with defined service level agreements based on
the severity of your issue. For example, with premium support we
guarantee a response in one hour for severity 1 issues.
New Features in Mirantis OpenStack 3.2
--------------------------------------
* Expanded choice of Ubuntu, CentOS or Red Hat Enterprise Linux as
the host Operating System
* Mirantis OpenStack hardened packages synchronized with latest stable
OpenStack Grizzly maintenance release
* Guided deployment wizard to simplify environmental configuration
* Ability to combine multiple roles onto a single node for HW consolidation
* Inclusion of Inktanks Ceph software-defined storage system in the
hardened packages and the ability to deploy Ceph via Fuel
* Neutron (Quantum) as a deployment choice from the Fuel UI
* Inclusion of the OpenStack Savanna and Murano projects in the
hardened packages and the ability to deploy them via Fuel
* Published API to Fuel for Create, Read, Update & Delete (CRUD)
operations
* Additional High Availability tests added to OpenStack Health Check
* Ability to register Fuel from within the UI
* Extended configuration menu during Fuel Master Node install for
network settings
* Pre-deployment check for conflicting DHCP servers in network
* Expansion of log management to include OpenStack logs and configurations
* Reporting of node usage and assigned roles
* Increase security with dynamic and unique SSH keys for VM Migration
Expanded choice of Ubuntu, CentOS or Red Hat Enterprise Linux as the host Operating System
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Fuel 3.2 has added support for deploying the Mirantis OpenStack
hardened packages onto Ubuntu 12.04 as a host Operating System for
the OpenStack nodes. The Ubuntu 12.04 operating system is included
in the ISO for Mirantis OpenStack, so you can select Ubuntu from
the Releases window and deploy without requiring Internet access or
downloading additional software. This expands your choices for
deployment to Centos with Mirantis OpenStack hardened packages, Red
Hat Enterprise Linux with Red Hat Open Stack or Ubuntu with Mirantis
OpenStack hardened packages.
Mirantis OpenStack hardened packages synchronized with latest stable OpenStack Grizzly maintenance release
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The OpenStack core projects in the Mirantis OpenStack hardened
packages have been synchronized with the OpenStack Grizzly 2013.1.3
bug fix update. Fuel 3.2 will deploy this 2013.1.3 version of Grizzly
when deploying an OpenStack environment on CentOS or Ubuntu.
Guided deployment wizard to simplify environmental configuration
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New in Fuel 3.2 is a guided deployment wizard that will walk you
through the major decisions regarding your desired OpenStack
configuration prior to deployment. This wizard will enable you to
make a choice about:
* Operating System and distribution combination
* Reference architecture
* Hypervisor
* Networking service
* Storage backend for Cinder
* Storage backend for Glance
* Installation of Savanna premium project (Hadoop for OpenStack)
* Installation of Murano premium project (Windows data services for OpenStack)
Your decisions about hypervisor, network, storage backends and premium
project installation can be reviewed and changed on the Settings tab
prior to deployment. If you wish to change your choice regarding OS,
distribution, network service or reference architecture you will need
to delete your proposed environment and restart the wizard.
Ability to combine multiple roles onto a single node for HW consolidation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
To provide additional flexibility and options during deployment of
your OpenStack Cluster, Fuel 3.2 now enables certain roles to be
combined together onto a single node. Previously, for example, Cinder
could only be deployed as a standalone node from the Fuel UI. Now,
Cinder can be combined with a Controller or Compute node or Ceph can be
combined with a Controller or Compute node.
To make this process even easier, weve added the ability to assign the
same roles to multiple nodes in a single operation. Just select the
unallocated nodes that you want to share a common role, choose the role
and then apply. You can also group nodes by similar hardware types,
allowing you to select all the nodes of a particular hardware configuration
for role assignment with one click.
Once assigned, you can review the nodes and roles assigned to those
nodes by grouping in a similar manner - either by roles or by hardware
configuration.
In addition to role assignment, you can also configure the network
interfaces or disk configuration for a set of nodes from the Fuel UI.
Once youve selected one or more allocated nodes, the Configure Disks and
Configure Interfaces buttons will become active if the nodes youve
selected share a similar disk configuration or number and type of network
interfaces.
Inclusion of Inktanks Ceph software-defined storage system in the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hardened packages and the ability to deploy Ceph via Fuel
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Included now in the Mirantis Openstack hardened packages is Inktanks
Ceph software-defined storage system. Ceph can be used either as an
object storage option for Glance or as a block storage option for Cinder.
As you define an OpenStack environment through the Fuel UI, you may
choose to use Ceph for one, both or neither of these functions. In
addition, you may choose where to install the Ceph roles - either as
a standalone node or combined with a Controller or Compute node.
Neutron (Quantum) as a deployment choice from the Fuel UI
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Previous versions of Fuel enabled deployment of Neutron (Quantum)
through the Fuel CLI Library. In Fuel 3.2, the ability to deploy
Neuton as the network component for OpenStack has been elevated to
the Fuel UI as well. Neutron can be configured to use Generic
Routing Encapsulation (GRE) segmentation or VLAN segmentation from
the deployment wizard. Additional settings can be through the Network
settings tab prior to deploying the OpenStack environment.
Inclusion of the OpenStack Savanna and Murano projects in the hardened
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
packages and the ability to deploy them via Fuel
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Savanna and Murano are related Openstack projects initially led by
Mirantis. Savanna enables on demand provisioning of Hadoop clusters
that can run on top of OpenStack. Savanna includes support for many
different distributions of Hadoop including Hortonworks, Cloudera and
even Intel. This empowers Big Data solutions to take full advantage of
the elastic nature of OpenStack. Savanna is currently a project thats
in incubation, but were confident that it will become a full project
in OpenStack in a future release of OpenStack.
Murano enables windows based services to be deployed on top of
OpenStack. These datacenter services include Active Directory, IIS,
Microsoft SQL and ASP.NET. This enables companies to provide
developers or end users with Windows based services that they either
depend on, or as a tool for transitioning them away from legacy
dependencies toward open source or other offerings.
Both of these projects are now included in the Mirantis OpenStack
packages and can be configured for deployment on top of OpenStack
through Fuel. Initial configuration is done via the Fuel UI but
Savanna and Murano also integrated into Horizon, enabling further
configuration to be done natively from the OpenStack dashboard.
In addition to the ability to deploy Savanna or Murano, additional
tests have been added to the OpenStack Health Check to confirm the
successful deployment and operational status of Savanna and Murano.
Published API to Fuel for Create, Read, Update & Delete (CRUD) operations
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The API originally created between the Fuel UI and Fuel CLI Library is
now public and available in Fuel 3.2. This RESTful API enables
auxiliary applications to activate standard CRUD operations (Create,
Read, Update, Delete) to manage your cloud infrastructure through
Fuel. Using Fuel you could, for example, create a cloud on demand,
remove a cloud that was no longer needed or add and remove nodes from
an existing cloud. This could be done either from a self-service
portal or by your cloud operations staff. In addition to cloud
deployment operations, you can also run the health checks on demand
or collect log information for troubleshooting. Details on commands
that can be executed through the API can be found in the extended
documentation.
Additional High Availability tests added to OpenStack Health Check
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
To confirm that a highly available deployment is configured properly
and running as expected, an additional test module has been added to
the OpenStack Health Check within Fuel. This group of tests can be
run separately or along with the other post-deployment health checks
and can be activated via the API for automated confirmation of high
availability.
Ability to register Fuel from within the UI
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
To ensure that self-evaluating customers get the support they need
when they need it, an option has been added to the Support window
in the Fuel UI that enables registration of Fuel once it has been
installed. This registration activates the 30 day complimentary
basic subscription support, enabling evaluation customers to contact
Mirantis world-class support via the Mirantis support portal with
questions or issues.
Extended configuration menu during Fuel Master Node install for network settings
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Advanced customers deploying the Fuel master node into their own
network setups with unique network parameters may need to specify a
broader set of network settings (e.g. interfaces to use for PXE booting,
IP address ranges, network masks, etc). Incorrect settings could result
in permanent problems that are not easily corrected later. To ensure
that these critical parameters are set appropriately for the Fuel master
node, a full featured configuration menu is now available during
installation of the Fuel master node.
To access this advanced menu, you may optionally press a key when
prompted during the first boot of Fuel Master Node. If a key is not
pressed, the installation will continue automatically and the default
values for parameters will be used.
This menu, once activated, enables configuration of the managed network,
network interfaces, DNS settings and access to the operating system
through a shell login. Once the parameters are saved, the installation
continues.
Pre-deployment check for conflicting DHCP servers in network
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
To ensure your network is configured properly, the Verify Networks
option in the Networks tab has been enhanced to check for conflicting
DHCP servers. Since the Fuel master node acts as a DHCP and PXE boot
server for available nodes, a conflict would cause the deployment to
fail.
Expansion of log management to include OpenStack logs and configurations
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The types of logs collected by Fuel from the Logs tab has been
increased to include the logs from OpenStack services. In addition,
OpenStack configuration files are now downloaded when collecting the
logs from remote nodes onto the Fuel Master Node. This collection is
initiated from the Support screen on the main page of the Fuel UI.
Reporting of node usage and assigned roles
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
To better manage your resources and assist with capacity planning,
Fuel now tracks your node usage across all of your deployed clouds
and makes that information available in a single report. This report
can be launched from within the Fuel UI or accessed as a CSV formatted
file on the Fuel Master Node. The report indicates the following:
* The environment name of deployed clouds
* The Node count for each cloud
* The total number of deployed nodes across all clouds
* The total number of discovered, unallocated nodes
* The number of nodes for each (combined) role configuration
Increase security with dynamic and unique SSH keys for VM Migration
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In previous versions of Fuel, SSH-keys were hard coded and non-unique
for services using SSH as a communication protocol for VM migration
and mysql replication. In Mirantis OpenStack 3.2, unique SSH keys
are generated per managed environment when that environment is deployed.
Resolved Issues in Mirantis OpenStack 3.2
------------------------------------------
Fuel doesn't work when the configured DHCP interface is not eth0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In previous releases, the Fuel master node was configured by default
to use the eth0 interface for DHCP and this settings was not easily
changed. The interface for DHCP can now be configured during the
installation of the Fuel Master Node by utilizing the new Extended
configuration menu during Fuel Master Node install for network settings.
OpenStack nodes won't boot if the boot order of the disks changed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Previously, after deployment of a OpenStack node, if the boot order
of the disks was changed, the node would not boot properly. This issue
has been corrected in Mirantis OpenStack 3.2.
Glance cache is not properly cleaned up after deployment
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The cache for Glance is located at /var/lib/glance/image-cache by
default. In simple deployment mode Fuel creates a special Logical
Volume Manager (LVM) for /var/lib/glance, to serve as a place for
images (/var/lib/glance/images) and image-cache. Previously, this
area was not cleaned up after deployment, so the initial size of
images would take twice the required amount of space. In the case
of High Availability (HA) situations, Swift is used for storage but
the cache is still in /var/lib/glance/image-cache. In this case, the
LVM is not installed (because Swift is used instead) so the image
cache is written to the root partition. Since the root partition is
very small, it fills up quickly.
In Mirantis OpenStack 3.2, these storage areas are properly cleaned up.
The KVM or QEMU hypervisors crashed due to incorrect disk cache mode
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If the parameter cache was set to 'none' in libvirt xml, the
hypervisors could crash when launched on a compute node. To correct
this issue, the parameter disk_cachemodes is now set to
"file=writethrough" in nova.conf, which protects the hypervisor from
crashing in this scenario.
Namespaces support in CentOS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Previously, deployments using CentOS as the host operating system did
not have default support for network namespaces. In this release,
CentOS deployments have network namespaces support built-in as provided
by upstream fixes to the Linux kernel contributed by Mirantis. This
built-in support allows greater flexibility with Neutron configurations
for tenant networks.
Known Issues in Mirantis OpenStack 3.2
--------------------------------------
Support for OpenStack Grizzly
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The following improvements in Grizzly are not currently supported
directly by Fuel:
* Nova Compute
* Cells
* Availability zones
* Host aggregates
* Neutron (formerly Quantum)
* LBaaS (Load Balancer as a Service)
* Multiple L3 and DHCP agents per cloud
* Keystone
* Multi-factor authentication
* PKI authentication
* Swift
* Regions
* Adjustable replica count
* Cross-project ACLs
* Cinder
* Support for FCoE
* Support for LIO as an iSCSI backend
* Ceilometer
It is expected that these capabilities will be supported in a future
release of Mirantis OpenStack.
In addition, support for High Availability of Neutron (Quantum)
on Red Hat Enterprise Linux (RHEL) is not available due to a limitation
within the RHEL kernel. It is expected that this issue will addressed
by a patch to RHEL in late 2013. This issue does not affect the CentOS
or Ubuntu distributions included in the Mirantis OpenStack hardened
packages.
Ability to deploy Swift as a standalone node is limited to Fuel Library
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
At this time, customers wishing to deploy Swift as a standalone node
will need to do so through the Fuel Library. An option to deploy
these components as standalone nodes is not currently present in the
Fuel UI. It is expected that a future release will enable this
capability.
Ability to add new nodes without redeployment
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Its possible to add new compute and Cinder nodes to an existing
OpenStack environment. However, this capability can not be used yet
to deploy additional controller nodes in HA mode.
Ability to deploy properly in networks that are not utilizing VLAN tagging
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
While included in Fuel and fully supported, network environments can
be complex and Mirantis has not exhaustively identified all of the
configurations where this feature works properly. Fuel does not
prevent the user from creating an environment that may not work
properly, although the Verify Networks function will confirm necessary
connectivity. As Mirantis discovers environments where a lack of VLAN
tagging causes issue, they will be further documented. Currently, a
known limitation is that untagged networks should not be mapped to
the physical network interface that is used for PXE provisioning.
Other Limitations
^^^^^^^^^^^^^^^^^^
* The Fuel master node is installed with CentOS as the host Operating
System. While OpenStack nodes can be installed with Ubuntu, Red Hat
Enterprise Linux or CentOS as the host OS, the Fuel master node is
only supported on CentOS.
* When using the Fuel UI, IP addresses for slave nodes (but not the
master node) are assigned via DHCP during PXE booting from the
master node. Because of this, even after installation, the Fuel
master node must remain available and continue to act as a DHCP
server.
* When using the Fuel UI, the floating VLAN and public networks must
use the same L2 network and L3 Subnet. In the UI, these two
networks are locked together, and can only run via the same physical
interface on the server. This is due to a limitation in Neutron.
* Deployments done through the Fuel UI creates all networks on all
servers, even if they are not required by a specific role (e.g. A
Cinder node will have VLANs created and addresses obtained from
the public network).
* Some of OpenStack services listen on all interfaces, which may be
detected and reported by security audits or scans. Please discuss
this issue with your security administrator if it is of concern in
your organization.
* The provided scripts that enable Fuel to be automatically installed
on VirtualBox will create separated host interfaces. If a user
associates logical networks to different physical interfaces on
different nodes, it will lead to network connectivity issues between
OpenStack components. Please check to see if this has happened prior
to deployment by clicking on the “Verify Networks” button on the
networking tab.
* The networks tab was redesigned to allow the user to provide IP
ranges instead of CIDRs, however not all user input is properly
verified. Entering a wrong value may cause failures in deployment.
* When configuring disks on nodes where Ubuntu has been selected as
the host OS, the Base System partition modifications will not properly
take effect. The default Base System partition will be applied
regardless of user choice due to limitations in Ubuntu provisioning.
How to obtain the product
-------------------------
Mirantis OpenStack is distributed as a self-contained ISO that, once
downloaded, does not require Internet access to provision OpenStack
nodes if deploying using the Mirantis OpenStack hardened packages.
This ISO is available in the Fuel Download section of the Mirantis
Portal. Here you will also find the Oracle VirtualBox scripts to
enable quick and easy deployment of a multi-node OpenStack cloud for
evaluation purposes.
Contacting Support
------------------
You can contact support online, through E-mail, or by phone.
Instructions on how to use any of these contact options can be found
here: https://mirantis.zendesk.com/home.

View File

@ -179,3 +179,9 @@ negatives. The following is a description of each sanity test available:
* Floating IP assignment
* Network connectivity check through floating IP
* User creation and authentication in Horizon
Additional Checks
-----------------
If you have installed OpenStack as a High Availability (HA) architecture
or have installed related OpenStack projects like Savanna or Murano,
additional tests will be shown.

View File

@ -9,9 +9,11 @@ Release Notes
contents:: :local:
:depth: 1
.. include:: /pages/release-notes/v3-1-grizzly.rst
.. include:: /pages/release-notes/v3-2-grizzly-full.rst
.. include /pages/release-notes/v3-1-grizzly.rst
.. include /pages/release-notes/v3-0-grizzly.rst
.. include /pages/release-notes/v2-1-folsom.rst
.. include /pages/release-notes/v2-0-folsom.rst
.. include /pages/release-notes/v1-0-essex.rst

View File

@ -58,10 +58,10 @@ copyright = u'2013, Mirantis Inc.'
# built documents.
#
# The short X.Y version.
version = '3.1'
version = '3.2'
# The full version, including alpha/beta/rc tags.
release = '3.1'
release = '3.2'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
@ -281,7 +281,7 @@ nwdiag_antialias = True
extensions += ['rst2pdf.pdfbuilder']
pdf_documents = [
('relnotes/index', u'Fuel-for-OpenStack-3.1-RelNotes', u'Release Notes',
('relnotes/index', u'Fuel-for-OpenStack-3.2-RelNotes', u'Release Notes',
u'2013, Mirantis Inc.')
# (master_doc, project, project, copyright),
]

View File

@ -3,7 +3,7 @@
.. cssclass:: header-table
+-------------------------------------+-----------------------------------+
| Fuel™ 3.1 for Openstack | .. cssclass:: right|
| Fuel 3.2 for Openstack | .. cssclass:: right|
| | |
| | Release Notes |
+-------------------------------------+-----------------------------------+
@ -22,5 +22,5 @@
PageBreak oneColumn
.. include:: /pages/release-notes/v3-1-grizzly-full.rst
.. include:: /pages/release-notes/v3-2-grizzly-full.rst