openstack
/
fuel-docs
Code Issues Proposed changes

Release Notes and Supported Software for 5.0.1 

Release Notes
- Add 5.0.1 to preface.rst
- Updated title in 040-resolved-issues.rst and 050-known-issues.rst
- Add 019-new-features-501.rst with contents
- 030-other-enhancements -- moved note about Ubuntu version so it follows
  note about CentOS version, before note about Heartbleed
- Add 039-resolved-issues-501.rst with contents

Release/date control files -- updated for 5.0.1

Planning Guide -- updated "Supported Software" list for:
- Icehouse 2014.1.1
- Ceph 0.67.9 "Dumpling"

Change-Id: Icc29422aae2ec2a9380e2076bc0d639364966f02
This commit is contained in:
Meg McRoberts 2014-07-01 18:32:33 -07:00 committed by Dmitry Borodaenko
parent 7a53bf335f
commit 3a64ff0d83
11 changed files with 611 additions and 190 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
common_conf.py
View File

@ -58,10 +58,10 @@ copyright = u'2014, Mirantis Inc.'
# built documents.
#
# The short X.Y version.
version = '5.0'
version = '5.0.1'
# The full version, including alpha/beta/rc tags.
release = '5.0'
release = '5.0.1'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.

8
pages/planning-guide/0025-supported-software-list.rst
View File

@ -14,7 +14,7 @@ Supported Software
* **OpenStack Core Projects**
* Icehouse release 2014.1
* Icehouse release 2014.1.1
* Nova (OpenStack Compute)
* Swift (OpenStack Object Storage)
@ -26,14 +26,14 @@ Supported Software
* **OpenStack Core Integrated Projects**
* Icehouse release 2014.1
* Icehouse release 2014.1.1
* Ceilometer (OpenStack Telemetry)
* Heat (OpenStack Orchestration)
* **OpenStack Incubated Projects**
* Icehouse release 2014.1
* Icehouse release 2014.1.1
* Sahara (OpenStack Data Processing)
@ -63,6 +63,6 @@ Supported Software
* **MongoDB** 2.4.6
* **Ceph** (v0.67.5 "Dumpling")
* **Ceph** v0.67.9 "Dumpling"
* **MySQL** 5.5.28 (CentOS), 5.5.37 (Ubuntu)

2
pages/preface/preface.rst
View File

@ -27,3 +27,5 @@ The following table lists the released revisions of this documentation:
+====================+============================+
|May, 2014 |5.0 GA |
+--------------------+----------------------------+
|August, 2014 |5.0.1 GA |
+--------------------+----------------------------+

21
pages/release-notes/v5-0-icehouse-full.rst
View File

@ -2,15 +2,20 @@
.. _RelNotes-5-0:
Release Notes for Mirantis OpenStack 5.0
========================================
Release Notes for Mirantis OpenStack 5.0.1
==========================================
Mirantis, Inc. is releasing Mirantis OpenStack version 5.0.
Mirantis, Inc. is releasing Mirantis OpenStack version 5.0.1.
This version is a maintenance release for Mirantis OpenStack 5.0
and contains defect fixes and resolutions
for issues initially reported against version 5.0
or previous releases.
You do not need to install version 5.0
prior to installing 5.0.1
because the 5.0.1 release includes version 5.0.
This generally available version of Mirantis OpenStack
is based on the latest stable Icehouse release of OpenStack
and includes several important defect fixes to Mirantis OpenStack
as well as some minor enhancements.
is based on the latest stable Icehouse release of OpenStack.
These release notes supplement the product documentation and list
enhancements, resolved issues, and known issues in this version.
@ -22,10 +27,14 @@ The following table lists the released revisions of this documentation:
+==========+=============+==============+
| 5.0 | 27-May-2014 | Initial G.A. |
+----------+-------------+--------------+
| 5.0.1 | 15-Aug-2014 | 5.0.1 G.A. |
+----------+-------------+--------------+
.. include:: /pages/release-notes/v5-0/010-what-is-mirantis-openstack.rst
.. include:: /pages/release-notes/v5-0/019-new-features-501.rst
.. include:: /pages/release-notes/v5-0/020-new-features.rst
.. include:: /pages/release-notes/v5-0/030-other-enhancements.rst
.. include:: /pages/release-notes/v5-0/039-resolved-issues-501.rst
.. include:: /pages/release-notes/v5-0/040-resolved-issues.rst
.. include:: /pages/release-notes/v5-0/050-known-issues.rst
.. include:: /pages/release-notes/v5-0/060-obtain-the-product.rst

50
pages/release-notes/v5-0/010-what-is-mirantis-openstack.rst
View File

@ -3,48 +3,56 @@ What is Mirantis OpenStack?
Mirantis OpenStack is made up of three components:
* Fuel for OpenStack
* Mirantis OpenStack hardened packages
* Fuel for OpenStack
* Mirantis Support
Mirantis OpenStack hardened packages
------------------------------------
The Mirantis OpenStack hardened packages
include the core OpenStack projects,
updated with each stable release of OpenStack,
and supporting a broad range of operating systems,
hypervisors, and deployment topologies.
Also included are:
* Packages to ensure High Availability.
* Fixes for defects reported by our customers
that may not yet have been merged into the community source.
* Mirantis-driven premium OpenStack projects
such as Sahara (which provides a simple means to provision
a Hadoop cluster on top of OpenStack)
and Murano (an application catalog that can be used
to publish apps and compose reliable environments out of them.)
* Mirantis-certified partner plug-ins, drivers, and integrations.
Fuel for OpenStack
------------------
Fuel is a lifecycle management application that deploys multiple
`OpenStack <https://www.openstack.org/>`_ clouds
from a single interface and then enables you to manage those clouds post deployment.
from a single interface and then enables you
to manage those clouds post deployment.
You can add nodes, remove nodes, or even remove clouds,
restoring those resources to the available resources pool.
Fuel also eases the complexities of network and storage configurations
through a simple-to-use graphical user experience. Baked into Fuel are:
* Mirantis reference architectures that we have tested and certified
to ensure that your deployed clouds are scalable, reliable, and production quality.
* An open and flexible library that enables customers to make configuration changes
to ensure that your deployed clouds are scalable, reliable,
and 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,
and supporting a broad range of operating systems, hypervisors, and deployment topologies.
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
such as Sahara (which provides a simple means to provision a Hadoop cluster on top of OpenStack)
and Murano (application catalog that can be used to publish apps and compose reliable
environments out of them.)
* Mirantis-certified partner plug-ins, drivers, and integrations.
Mirantis Support
----------------
Mirantis OpenStack offers a subscription to our world-class support
with defined service level agreements based on the severity of your issue.
For example, the premium support guarantees a one-hour response for severity 1 issues.
For example, the premium support guarantees
a one-hour response for severity 1 issues.

40
pages/release-notes/v5-0/019-new-features-501.rst Normal file
View File

@ -0,0 +1,40 @@
New Features in Mirantis OpenStack 5.0.1
========================================
Support for the latest stable OpenStack IceHouse release
--------------------------------------------------------
Mirantis OpenStack 5.0.1 provides hardened packages
of the core OpenStack components
that are included in the
`OpenStack Icehouse 2014.1.1 <https://wiki.openstack.org/wiki/ReleaseNotes/2014.1.1>`_ release.
Fuel 5.0.1 can deploy this version of OpenStack on either CentOS or Ubuntu.
The Fuel Master Node is upgradable
----------------------------------
If you are running a Mirantis OpenStack 5.0 environment,
you can upgrade to Fuel 5.0.1
but leave your OpenStack 5.0 environment in place.
After the upgrade,
the Fuel Master Node will be able to deploy
either a Mirantis OpenStack 5.0 or 5.0.1 environment.
It can add and delete nodes
and perform other operational functions
such as log management and Health Checks
on either a 5.0.1 environment
or a 5.0 environment.
See :ref:`upgrade-ug` for details and instructions.
.. Note:: This only upgrades the Fuel Master Node.
It does not patch or update the OpenStack environment.
The ability to patch and update OpenStack environments
is planned for a future release.
After the upgrade,
you can deploy a Mirantis OpenStack 5.0 environment from the Fuel 5.0.1 dashboard
by choosing one of the 2014.1 distros for the environment
on the :ref:`name-distro-ug` screen.

49
pages/release-notes/v5-0/020-new-features.rst
View File

@ -1,42 +1,14 @@
New Features in Mirantis OpenStack 5.0
======================================
Features First Released in Mirantis OpenStack 5.0
=================================================
Support for the latest stable OpenStack IceHouse release
--------------------------------------------------------
Support for the initial OpenStack IceHouse release
-----------------------------------------------------
The OpenStack core projects in the Mirantis OpenStack hardened packages
support the
`OpenStack IceHouse 2014.1 <https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse#OpenStack_2014.1_.28Icehouse.29_Release_Notes>`_ release.
`OpenStack Icehouse 2014.1 <https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse#OpenStack_2014.1_.28Icehouse.29_Release_Notes>`_ release.
Fuel 5.0 deploys this version of OpenStack on either CentOS or Ubuntu.
The Fuel Master Node is now upgradable
--------------------------------------
Mirantis OpenStack 5.0 includes architectural changes
to the Fuel Master Node
that will enable the master node to be upgraded in place to future releases.
This will enable customers to more easily upgrade
to new versions of the software
and take advantage of new capabilities present
in newer versions of the Fuel project and Mirantis OpenStack.
The Fuel Master Node can manage multiple version of Mirantis OpenStack
----------------------------------------------------------------------
Architectural changes to the Fuel Master node
will make it possible for one Fuel Master node
to manage environments that are running
different versions of Mirantis OpenStack.
In other words, when the next release of Mirantis OpenStack is released,
you can upgrade to the new Fuel version
and deploy a new environment with the new version,
but leave your OpenStack 5.0 environment in place;
the Fuel Master Node will be able to add and delete nodes
and perform other operational functions
such as log management and Health Checks
on both the newly deployed
and your existing OpenStack 5.0 environments.
vCenter can provide access to compute resources from attached ESXi servers
--------------------------------------------------------------------------
@ -50,17 +22,22 @@ with the VMWare vCenter server driver activated onto a controller node.
This service then communicates directly with vCenter
so that the OpenStack scheduler can create
VM instances on ESXi servers.
See :ref:`vcenter-plan`
for information about planning your vSphere integration
and links to instructions for setting up and installing your environment.
MongoDB is now the default database for OpenStack Telemetry (Ceilometer)
------------------------------------------------------------------------
Mirantis OpenStack 5.0 now defaults to installing MongoDB
Mirantis OpenStack 5.0 now defaults to installing :ref:`MongoDB<mongodb-term>`
as the recommended back-end database
for OpenStack Telemetry (Ceilometer).
When deploying your OpenStack environment with Fuel,
you must deploy MongoDB in order to install Ceilometer.
you must deploy MongoDB roles in order to install Ceilometer;
you should deploy an odd number of MongoDB roles,
preferably one per Controller node.
This resolves the Ceilometer performance issues caused
by the volume of concurrent read/write operations.
It is possible (although highly **not** recommended)
to revert to using MySQL as the database for Ceilometer
to manually revert to using MySQL as the database for Ceilometer
after the environment is deployed.

49
pages/release-notes/v5-0/030-other-enhancements.rst
View File

@ -1,27 +1,26 @@
Other Enhancements
==================
Other 5.0 Enhancements
======================
The CentOS 6.5 operating system is included
-------------------------------------------
Mirantis OpenStack 5.0 includes CentOS 6.5,
Mirantis OpenStack 5.x includes CentOS 6.5,
which can be used as the operating system for the Fuel Master Node
or the Host Operating System for OpenStack nodes.
The Ubuntu 12.04.4 operating system is included
-----------------------------------------------
Mirantis OpenStack 5.x includes Ubuntu 12.04.4,
which can be used as the Host operating system
for OpenStack nodes.
The supplied operating systems are protected against the “Heartbleed” defect in OpenSSL
---------------------------------------------------------------------------------------
While the standard distribution of CentOS 6.5 and Ubuntu 12.04.4 were
vulnerable to the Heartbleed defect in OpenSSL, the Mirantis OpenStack 5.0
packages have been updated with the patched 1.0.1g version and are thus
protected against the vulnerability.
Ubuntu 12.04.4 operating system is included
-------------------------------------------
Mirantis OpenStack 5.0 includes Ubuntu 12.04.4,
which can be used as the Host operating system
for OpenStack nodes.
While the standard distribution of CentOS 6.5 and Ubuntu 12.04.4 are
vulnerable to the Heartbleed defect in OpenSSL, the Mirantis OpenStack 5.x
packages have been patched and are protected against this vulnerability.
Filter Scheduler improves how compute requests are dispatched
-------------------------------------------------------------
@ -34,9 +33,10 @@ to make better decisions
than the older scheduler.
Users can, however, select the traditional ("naive") scheduler
from the Fuel "Settings" page.
This is discussed more in the :ref:`scheduler-term` article.
This is discussed more in the :ref:`Scheduler, Nova<scheduler-term>` article.
See `Some improvements in Nova Scheduler config
<https://blueprints.launchpad.net/fuel/+spec/scheduler-config-improvements>`_.
<https://blueprints.launchpad.net/fuel/+spec/scheduler-config-improvements>`_
for background information.
Overcommit ratio allows better resource allocation
--------------------------------------------------
@ -47,7 +47,7 @@ than is physically available on the Compute nodes.
This allows you to better utilize the available resources
because most instances are not fully active at the same time.
See :ref:`overcommit-term` for information about
See :ref:`Overcommit ratio<overcommit-term>` for information about
modifying the overcommit ratio for your environment
by manually editing a configuration file.
The overcommit ratio is not configurable from the Fuel UI; see
@ -56,7 +56,7 @@ The overcommit ratio is not configurable from the Fuel UI; see
Sahara (Savanna) has been updated to the latest Icehouse version
----------------------------------------------------------------
The Sahara project provided with Mirantis OpenStack 5.0
The Sahara project provided with Mirantis OpenStack 5.x
has been updated to the Icehouse version.
This major release of Sahara includes several bug fixes
and the following enhancements:
@ -72,13 +72,15 @@ Note that what was previously known as the Savanna project
is now called the Sahara project;
this resolves a trademark infringement issue.
See :ref:`Planning a Sahara Deployment<sahara-plan>`
to get started implementing Sahara on Mirantis OpenStack.
Additional information about Sahara can be found on the
`Sahara project web page <https://wiki.openstack.org/wiki/Sahara>`_.
Murano has been updated to the latest Icehouse version
------------------------------------------------------
Mirantis OpenStack 5.0 includes
Mirantis OpenStack 5.x includes
`version 0.5 <https://launchpad.net/murano/+milestone/0.5>`_
of `Murano <https://wiki.openstack.org/wiki/Murano>`_,
an application catalog and data services lifecycle management addition
@ -94,13 +96,16 @@ and the following enhancements:
- An improved UI
- Application statistics that can be used for billing purposes
For detailed information, please refer to the `Release Notes for Murano
version 0.5 <https://wiki.openstack.org/wiki/Murano/ReleaseNotes_v0.5>`_.
For detailed information about Murano,
see the `Release Notes for Murano version 0.5
<https://wiki.openstack.org/wiki/Murano/ReleaseNotes_v0.5>`_.
For information about deploying Murano with Fuel,
see :ref:`Murano Deployment Notes<Murano-deployment-notes>`.
Addition of "Live Migrate" option in Horizon
--------------------------------------------
The Icehouse version of Horizon that is included in Mirantis OpenStack 5.0
The Icehouse version of Horizon that is included in Mirantis OpenStack 5.x
includes a "Live Migrate" option.
This solves some issues that occurred in earlier versions
when migrating instances using Horizon.

220
pages/release-notes/v5-0/039-resolved-issues-501.rst Normal file
View File

@ -0,0 +1,220 @@
Issues Resolved in Mirantis OpenStack 5.0.1
===========================================
Bootstrap kernel supports additional hardware
---------------------------------------------
The bootstrap image shipped with earlier versions of Mirantis OpenStack
omitted some firmware files,
which led to issues with some hardware configurations
(e.g. Dell R410/R610s and other servers with Broadcom NetXteme II NICs).
The bootstrap image shipped with Mirantis OpenStack 5.0.1
has been updated to include these firmware files.
See `LP1323354 <https://bugs.launchpad.net/fuel/+bug/1323354>`_
for details.
AMQP heartbeat and other HA improvements
----------------------------------------
Heartbeat mechanism is added to the oslo.messaging library (used for
AMQP based RPC between OpenStack components) to detect and drop hung
RabbitMQ sessions and force a reconnect to a healthy controller.
The AMQP heartbeat has to be enabled because the interaction between
Linux TCP/IP stack, AMQP protocol, its implementation in pyamqp and
kombo libraries for Python, OpenStack oslo.messaging library, and the
Eventlet networking library for Python can result in hung RabbitMQ
sessions when a controller node goes offline.
When that happens, RPC fails for one or more OpenStack components and
major areas of functionality, such as provisioning instances or
attaching volumes, are blocked. Without the heartbeat, you would have to
restart the affected services to recover.
See `LP1341656 <https://bugs.launchpad.net/mos/+bug/1341656>`_.
Syslog log rotation on the Fuel Master Node
-------------------------------------------
Multiple inconsistencies in the syslog rotation implementation
are fixed:
- The syslog log rotation on the Fuel Master Node
has been reimplemented to integrate docker logs with other logs,
to add audit logs to the rotation,
and to split client logs from server logs.
See `LP1316957 <https://bugs.launchpad.net/fuel/+bug/1316957>`_.
- Issues that caused duplicated entries in syslog
and that prevented the log rotation scheme from clearing these logs
could cause the logs to grow to the point
where they filled the file system on the Fuel Master Node.
These have been fixed.
See `LP1329991 <https://bugs.launchpad.net/bugs/1329991>`_.
Health Check sometimes returned false positive error
----------------------------------------------------
In earlier releases, the Fuel Health Check sometimes
erroneously reported an error
when checking connectivity using a floating IP.
This was fixed by increasing the maximum number of ping probes
to allow at least three answers for up to ten requests,
increasing the interval between connectivity checks
from thirty seconds to sixty seconds,
and checking the command result rather than its output.
A retry is also implemented
when the ping command returns with an error code.
See `LP1322102 <https://bugs.launchpad.net/fuel/+bug/1322102>`_.
Stopping deployment could damage filesystem
-------------------------------------------
Clicking the "Stop Deployment" button when modifying
a provisioned node sometimes destroyed the nodes's filesystem.
This happened because Astute removed the node from Cobbler,
making the node's hostname unresolvable.
It was fixed by modifying the stop_provisioning task
to use the node's IP address rather than hostname.
See `LP1316583 <https://bugs.launchpad.net/fuel/+bug/1316583>`_.
Unable to restart deployment
----------------------------
If you stopped deployment when a controller node
was partially deployed,
restarting the deployment raised a 400 error
with the "No changes to deploy" text.
After a few minutes, the node's status would change
to "discovered" although the pending_addition flag was not set.
This was because Nailgun was not sent all the information
it needed to continue the deployment.
This problem has been fixed.
See `LP1319823 <https://bugs.launchpad.net/bugs/1319823>`_.
Cobbler sometimes ran out of resources when redeploying environment
-------------------------------------------------------------------
Redeploying an OpenStack environment
requires that Cobbler delete existing nodes
and then redeploy them,
which sometimes caused Cobbler to run out of resources.
To fix this problem,
nodes are now split into smaller groups
which are processed in order
with some lag time (configurable, default 10 seconds)
between the processing of the groups.
See `LP1339024 <https://bugs.launchpad.net/fuel/+bug/1339024>`_.
Race condition in Nailgun may hang Fuel UI
------------------------------------------
A race condition in Nailgun
could cause the UI to freeze
and Fuel CLI and API to start reporting Internal Server Error
as a response to any command.
Upgrading the Fuel Master Node to 5.0.1
unfreezes the environment
and prevents it from happening again for a new environment.
See `LP1328200 <https://bugs.launchpad.net/fuel/+bug/1328200>`_.
Instance console sometimes failed to connect
--------------------------------------------
For cloud environments with multiple Controller nodes,
the first attempt to access the Horizon Instance console
sometimes failed
although subsequent attempts to connect were successful.
The solution was to use the Nova memcached_servers configuration option
to ensure that authentication tokens used to connect to instance consoles
are shared properly across all Controller nodes.
See `LP1323705 <https://bugs.launchpad.net/bugs/1323705>`_.
Ceilometer performance issues
-----------------------------
The method used to do reverse DNS lookups for Ceilometer
was inappropriate, which caused serious latency issues.
This has been resolved.
See `LP1330951 <https://bugs.launchpad.net/fuel/+bug/1330951>`_,
`LP1324140 <https://bugs.launchpad.net/bugs/1324140>`_,
and `LP1291229 <https://bugs.launchpad.net/ceilometer/+bug/1291229>`_.
Problems deploying Ceph OSD nodes when redeploying environment
--------------------------------------------------------------
LVM metadata was sometimes retained
when a new OpenStack cloud environment was deployed
using the same hardware and the same partition layout as the old environment;
this prevented Ceph OSD nodes from deploying correctly.
LVM metadata is now explicitly erased from all partitions
after the partitions are created
during the provisioning of a node for the new environment;
this solves the problem.
See `LP1323707 <https://bugs.launchpad.net/bugs/1323707>`_.
Deployment failed because of unnecessary HAProxy backend status check on secondary controller
---------------------------------------------------------------------------------------------
HAProxy backend status is only necessary on the primary controller.
When run on a secondary controller,
the check may run at the wrong time and report a failure,
which caused the deployment of the whole environment to fail.
In 5.0.1, HAProxy backend check
runs only during deployment of primary controller.
See `LP1329780 <https://bugs.launchpad.net/bugs/1329780>`_.
Rebooting Fuel Master Node from installation media silently deleted partitions on target nodes
----------------------------------------------------------------------------------------------
If the Fuel Master Node was accidentally rebooted
from the installation media after deployment,
it silently wiped the partition table on the target nodes.
In 5.0.1, Fuel asks for confirmation before
wiping the disks on the target nodes.
See `LP1325068 <https://bugs.launchpad.net/fuel/+bug/1325068>`_.
Number of Ceph OSD Journal Partitions is no longer limited
----------------------------------------------------------
In earlier releases,
double-digit partitions (10 and up)
on the Ceph OSD Journal device
could not be allocated to Ceph OSDs.
This limitation has been removed.
See `LP1339833 <https://bugs.launchpad.net/fuel/+bug/1339833>`_.
The network settings tab disappeared intermittently on a VirtualBox deployment
------------------------------------------------------------------------------
The Network Settings tab sometimes disappeared
from the Fuel UI screen on a VirtualBox deployment
and then reappeared.
This has been fixed.
See `LP1323269 <https://bugs.launchpad.net/bugs/1323269>`_.
Murano Health Check no longer downloads images for testing
----------------------------------------------------------
Before running the Murano Health Check,
you should manually download the image
as documented in :ref:`murano-test-prepare`.
In earlier versions of Fuel,
if the image was not present,
the software would attempt to download the image
from a standard site and generate an error when it was not found.
Now the test fails if the image is not available on the target.
See `LP1327290 <https://bugs.launchpad.net/bugs/1327290>`_.
Live Migration now works when the instance has floating IP assigned
-------------------------------------------------------------------
In previous releases,
the migration process failed when the instance
had a floating IP address assigned.
This was due to incorrect type handling
for a floating IP object in Nova;
the problem has now been fixed.
See `LP1334164 <https://bugs.launchpad.net/fuel/+bug/1334164>`_.

16
pages/release-notes/v5-0/040-resolved-issues.rst
View File

@ -1,5 +1,5 @@
Issues Resolved in Mirantis OpenStack 5.0
=========================================
Issues First Resolved in Mirantis OpenStack 5.0
===============================================
Sahara logging now works correctly
----------------------------------
@ -137,7 +137,7 @@ See `LP1274784 <https://bugs.launchpad.net/fuel/+bug/1274784>`_.
Nailgund now scales better for large environments
-------------------------------------------------
The nailgund daemon has been redesigned to better accomodate
The nailgund daemon has been redesigned to better accommodate
environments with more than 50 nodes.
See `LP1274614 <https://bugs.launchpad.net/fuel/+bug/1274614>`_.
Additional improvements to the scalability of nailgund
@ -168,15 +168,15 @@ Fuel Master Node now runs on HP systems with Smart Array RAID hardware
See `LP1312311 <https://bugs.launchpad.net/fuel/+bug/1312311>`_.
Fuel UI now represents multiple disks correctly for Ubuntu on Vbox
------------------------------------------------------------------
Fuel UI now represents multiple SATA disks correctly for Ubuntu
---------------------------------------------------------------
This bug occurred because the Ubuntu kernel maps all hard drives on Vbox
This bug occurred because the Ubuntu kernel maps all SATA drives
into one address (sysfs PATH_ID)
so, when multiple disks were configured,
all the links were mapped to this one address.
The solution was to rewrite Fuel so it identifies disks
by ID and path rather than using the path that Vbox populates.
The solution was to change Fuel provisioning script to identify disks
by ID and path rather than using the sysfs PATH_ID.
See `LP1263648 <https://bugs.launchpad.net/fuel/+bug/1263648>`_.
Disk partitions are now unmounted before partitions are updated

342
pages/release-notes/v5-0/050-known-issues.rst
View File

@ -1,56 +1,224 @@
Known Issues in Mirantis OpenStack 5.0
======================================
Known Issues in Mirantis OpenStack 5.0.1
========================================
Known limitations for the vCenter integration
---------------------------------------------
The vCenter integration with Mirantis OpenStack 5.0 is fully supported,
The vCenter integration with Mirantis OpenStack 5.x is fully supported,
but it has some known limitations:
* vCenter integration can be enabled
only if Nova-network is the network type.
* The only network topology that can be used with vCenter
is Nova-network with FlatDHCP.
vCenter integration is not yet supported with the Neutron network type.
* vCenter integration does not provide high availability
for the Nova-compute service.
Only one compute service is enabled
for the Nova-compute and Nova-network services.
Only one compute service and one network service are enabled
and, if the service or the controller on which the service is deployed fail,
OpenStack is unable to access the ESXi server resources
OpenStack is unable to access the vCenter server resources
for scheduling the VMs.
See `LP1312653 <https://bugs.launchpad.net/fuel/+bug/1312653>`_.
* When vCenter is selected as the hypervisor,
all Ceph, Cinder, and Nova options are disabled
in the storage settings.
It is possible to use Ceph as the storage backend for Glance
and for Swift/S3 object storage,
but it must be configured .
See `LP1316377 <https://bugs.launchpad.net/fuel/+bug/1316377>`_.
* The Fuel UI allows you to select Cinder LVM
as a storage option for vCenter on the Settings page.
although VMDK is the only Cinder backend that is supported for vCenter.
If you configure Cinder LVM,
you will get an error when you try to create a volume
and attach it to a running instance.
See `LP1352401 <https://bugs.launchpad.net/fuel/+bug/1352401>`_.
* The Fuel UI allows you to deploy your vCenter environment
without setting the vCenter credentials;
this results in an unworkable OpenStack environment.
When vCenter is selected as the hypervisor option,
be sure to set the vCenter access credentials on the Settings page
before deploying the environment.
See `LP1314613 <https://bugs.launchpad.net/fuel/+bug/1314613>`_.
Additional MongoDB roles cannot be added to an existing deployment
------------------------------------------------------------------
Any number of MongoDB roles (or standalone nodes)
Fuel 5.0.1 installs :ref:`mongodb-term`
as a backend for :ref:`ceilometer-term`.
When installing OpenStack in HA mode,
Fuel does not force the user to set up multiple MongoDB roles
although you should have one MongoDB role for each Controller node.
As a result, a user can set up a single MongoDB role for Ceilometer,
which is inadequate for an HA environment.
See `LP1338486 <https://bugs.launchpad.net/bugs/1338486>`_.
Any odd number of MongoDB roles (or standalone nodes)
can initially be deployed into an OpenStack environment
but, after the environment is deployed,
additional MongoDB roles cannot be added.
Be sure to deploy an adequate number of MongoDB
roles during the initial deployment.
Be sure to deploy an adequate number of MongoDB roles
(one for each Controller node is ideal)
during the initial deployment.
See `LP1308990 <https://bugs.launchpad.net/fuel/+bug/1308990>`_.
Network verification does not check OVS and bonding
Fuel upgrade fails if custom python modules are installed as eggs
-----------------------------------------------------------------
Installing additional python modules on the Fuel Master node
using pip or easy_install
may cause the Fuel upgrade script to fail.
See `LP1341564 <https://bugs.launchpad.net/fuel/+bug/1341564>`_.
Upgrade does not put a new fuelclient on Master Node
----------------------------------------------------
The Fuel upgrade procedure does not put
a new fuelclient on the Master Node.
This is because the Puppet manifests
include a hard-coded path to the RPM versions
and so do not detect the new versions.
See `LP1346247 <https://bugs.launchpad.net/fuel/+bug/1346247>`_.
Upgrade may not remove all iptables rules from the docker chain
---------------------------------------------------------------
The 5.0.1 upgrade scripts may not properly remove
stale iptables rules from the docker chain.
This can cause the Fuel Master node to redirect requests to dead containers,
which breaks some Fuel services.
To fix this,
you will need to remove old rules from the Fuel Master node
using the **iptables** command:
::
iptables-save | egrep -v "(DNAT --to-destination|-o docker0.*--dport)" | \
iptables-restore
Afterwards, reboot the Fuel Master node. The appropriate iptables rules will be
regenerated. See `LP1349287 <https://bugs.launchpad.net/fuel/+bug/1349287>`_.
Some services fail to connect after upgrade
-------------------------------------------
Docker 0.10 contains a bug in its IP address allocation logic which sometimes
allocates IP addresses incorrectly. This occasionally causes two Docker
containers to occupy the same internal Docker IP address. If services fail to
work after upgrade, reboot and try again.
See `LP1357357 <https://bugs.launchpad.net/fuel/+bug/1357357>`_.
Network verification fails if a node is offline
-----------------------------------------------
Network verification can fail if a node is offline
because network verification is managed by Astute service,
and Astute does not track which nodes are online.
See `LP1318659 <https://bugs.launchpad.net/fuel/+bug/1318659>`_.
Volume creation may fail after primary Controller node is rebooted
------------------------------------------------------------------
The volume creation process may hang
after rebooting the primary Controller node.
The nova.compute.log on the Compute node
includes an error message referencing a Broken pipe.
To recover, restart the Cinder services
then force-delete and recreate the affected volumes.
See `LP1355792 <https://bugs.launchpad.net/mos/+bug/1355792>`_.
Sahara platform test fails in HA mode when primary controller node is offline
-----------------------------------------------------------------------------
The Sahara platform test fails in HA mode
when the primary controller node is offline.
This is because the SSH method chooses the controller
from the list of configured nodes
rather than a list of online nodes.
See `LP1346864 <https://bugs.launchpad.net/fuel/+bug/1346864>`_.
Multiple TestVM images may be created
-------------------------------------
Multiple TestVM images may be created
and will appear on the Horizon dashboard.
Any of the images can be used.
See `LP1342039 <https://bugs.launchpad.net/fuel/+bug/1342039>`_.
Fuel is not enforcing quorum on Controller clusters
---------------------------------------------------
The Fuel "Verify Networks" functionality
does not check :ref:`ovs-term` and :ref:`bonding-term` connections.
See the `Network checks for Neutron blueprint <https://blueprints.launchpad.net/fuel/+spec/network-checker-neutron-vlan>`_.
In order to incrementally add Controllers into the cluster,
Fuel temporarily sets the **no-quorum-policy="ignore"** property
in the :ref:`crm<crm-term>` configuration
but is not resetting this property to activate the quorum
after the environment is deployed.
Consequently, in Controller clusters of three or more nodes,
restarting the Management network
results in no L3 agents running on any of the nodes in the cluster.
The work-around is to follow the instructions in
`Setting Basic Cluster Properties <http://docs.openstack.org/high-availability-guide/content/_setting_basic_cluster_properties.html>`_
to unset this property.
See `LP1348548 <https://bugs.launchpad.net/fuel/+bug/1348548>`_.
Controllers are deployed sequentially rather than in parallel
-------------------------------------------------------------
Adding HA Controllers one-by-one may fail
-----------------------------------------
Multiple controllers are deployed sequentially
rather than in parallel.
This increases the deployment time,
but does not otherwise adversely affect the environment.
See `LP1310494 <https://bugs.launchpad.net/fuel/+bug/1310494>`_.
Adding HA Controllers one-by-one may fail
because each environment must have an odd number of controllers.
When replacing a single controller,
you should delete the old node
and then add in the new node before deploying the changes.
See `LP1350266 <https://bugs.launchpad.net/fuel/+bug/1350266>`_.
Cobbler fails to provision more than 10 nodes at a time
-------------------------------------------------------
When installing Ubuntu on more than 10 nodes in parallel,
Cobbler can take too long to generate preseed data for all nodes,
and some of the nodes will fail to provision.
Adding no more than 10 nodes at a time to the environment
mitigates this problem.
See `LP1355347 <https://bugs.launchpad.net/fuel/+bug/1355347>`_.
Intermittent Pacemaker upgrade failures
---------------------------------------
Puppet intermittently fails to update Corosync cluster information Base
because of shadow CIB commit conflicts.
See `LP1283062 <https://bugs.launchpad.net/fuel/+bug/1283062>`_
for a description of the problem;
see `HA Improvements of pacemaker and corosync <https://blueprints.launchpad.net/fuel/+spec/ha-pacemaker-improvements>`_
for a description of structural changes
for Pacemaker deployment and configuration
that are needed to address this problem.
RabbitMQ Service may not start after rebooting the primary Controller node
--------------------------------------------------------------------------
The RabbitMQ Service may not start
after the primary Controller node is rebooted,
which means that the node status is "offline".
This is because of flaws in the RabbitMQ clustering mechanism
which are under investigation.
In the meantime, you must manually bring down the RabbitMQ server
and rejoin it to the cluster following the instructions in
:ref:`restart-rabbitmq-ops`.
See `LP1318936 <https://bugs.launchpad.net/fuel/+bug/1318936>_`.
Some logs are excluded from the Diagnostic Snapshot
---------------------------------------------------
The diagnostic snapshot does not include all the logs.
The logs are available under the */var/log* directory,
but some logs in this directory are symlinks
and the diagnostic snapshot does not capture them.
See `LP1323436 <https://bugs.launchpad.net/bugs/1323436>`_
and `LP1318514 <https://bugs.launchpad.net/bugs/1318514>`_.
"Deassociate Floating IP" button may disappear from Horizon menu
----------------------------------------------------------------
The "Deassociate Floating IP" button may disappear
from the Horizon menu when using Neutron network topologies.
As a work around, use the "Disassociate Floating IP" action
from the Access and Security -> Floating IPs.
See `LP1325575 <https://bugs.launchpad.net/bugs/1325575>`_.
RAID-1 spans all configured disks on a node
-------------------------------------------
@ -100,7 +268,8 @@ but sdc will not be used as part of the RAID-1 array:
super 1.0 [2/2] [UU]
See `LP1267569 <https://bugs.launchpad.net/fuel/+bug/1267569>`_.
See `LP1267569 <https://bugs.launchpad.net/fuel/+bug/1267569>`_
and `LP1258347 <https://bugs.launchpad.net/fuel/+bug/1258347>`_.
Some UEFI hardware cannot be used
---------------------------------
@ -161,15 +330,6 @@ you can use the :ref:`Fuel CLI<cli_usage>` to use other physical interfaces
when you configure your environment.
See `LP1285059 <https://bugs.launchpad.net/fuel/+bug/1285059>`_.
CentOS issues booting on Dell servers
-------------------------------------
Because of a CentOS bug
(see `CentOS6492 <http://bugs.centos.org/view.php?id=6492>`_),
kernel parameters must be adjusted
to allow OpenStack to be provisioned on Dell servers.
See `LP1312671 <https://bugs.launchpad.net/fuel/+bug/1312671>`_.
CentOS does not support some newer CPUs
---------------------------------------
@ -189,10 +349,12 @@ such as QEMU or KVM, to emulate an older CPU on such systems.
Note that VirtualBox has no CPU model emulation feature.
See `LP1322502 <https://bugs.launchpad.net/fuel/+bug/1322502>`_.
CentOS kernel issues on certain hardware
----------------------------------------
CentOS issues booting on some servers
-------------------------------------
Deployments that use CentOS as the host OS on the OpenStack nodes
Because of a CentOS bug
(see `CentOS6492 <http://bugs.centos.org/view.php?id=6492>`_),
deployments that use CentOS as the host OS on the OpenStack nodes
may get stuck at the very beginning of the provisioning stage
because of boot issues on some hardware.
To resolve this situation,
@ -210,39 +372,6 @@ Then run this command in the Fuel Master node shell:
See `LP1312671 <https://bugs.launchpad.net/fuel/+bug/1312671>`_.
Bootstrap kernel issues on certain hardware
-------------------------------------------
The bootstrap image shipped with Mirantis OpenStack
is based on a 3.10 kernel with firmware built from
the in-kernel tree.
This can lead to issues with some hardware configurations,
(including some Dell R410/R610s servers).
See `LP1323354 <https://bugs.launchpad.net/fuel/+bug/1323354>`_
for details.
As a workaround, use `bootstrap image with 2.6 kernel <http://9f2b43d3ab92f886c3f0-e8d43ffad23ec549234584e5c62a6e24.r60.cf1.rackcdn.com/bootstrap-5.0-kernel-2.6.zip>`_.
Copy the downloaded zip archive to the Fuel master node
::
scp bootstrap-5.0-kernel-2.6.zip root@10.20.0.2:/root/
Log in to Fuel master node and run the following commands to install new bootstrap:
::
cd /root/
yum -y install unzip
unzip bootstrap-5.0-kernel-2.6.zip
cp -b linux /var/www/nailgun/bootstrap/
chmod +x /var/www/nailgun/bootstrap/linux
chmod -w /var/www/nailgun/bootstrap/linux
cp -b initramfs.img /var/www/nailgun/bootstrap/
cobbler sync
.. note:: Existing bootstrap files will be renamed to linux~ and initramfs.img~.
To apply changes to already bootstrapped nodes, simply reboot the
affected nodes to boot with the 2.6 kernel.
Bootstrap does not see Brocade NICs
-----------------------------------
@ -287,7 +416,7 @@ soft trunks and hard trunks:
This provides the least amount of performance overhead
but the traffic may not be passed onto the OVS bridge in some edge cases.
* The **hard trunks mode** also configureS OVS to enable splinters
* The **hard trunks mode** also configures OVS to enable splinters
but uses an explicitly defined list of all VLANs across all interfaces.
This should prevent the occasional failures associated with the soft mode
but requires that corresponding tags be created on all of the interfaces.
@ -297,6 +426,24 @@ soft trunks and hard trunks:
See :ref:`ovs-arch`
for more information about using Open VSwitch.
Keystone performance issues if memcache instance fails
------------------------------------------------------
When several OS controller nodes are used
with 'memcached' installed on each of them,
each 'keystone' instance is configured
to use all of the 'memcached' instances.
Thus, if one of the controller nodes became inaccessible,
then whole cluster may cease to be workable
because of delays in the memcached backend.
This behavior is the way the python memcache clients themselves work.
There is currently no acceptable workaround
that would allow the use all available 'memcached' instances
without such issues.
See `LP1332058 <https://bugs.launchpad.net/keystone/+bug/1332058>`_
and `LP1340657 <https://bugs.launchpad.net/bugs/1340657>`_.
Placing Ceph OSD on Controller nodes is not recommended
-------------------------------------------------------
@ -317,6 +464,25 @@ arbitrary orders of shutdown and startup,
which will fix this issue.
See `LP1297355 <https://bugs.launchpad.net/fuel/+bug/1297355>`_.
Controller cluster may fail if one MySQL instance fails
-------------------------------------------------------
If the MySQL instance on one Controller node fails,
the entire Controller cluster may be inaccessible
whereas it should just disable the Controller node where MySQL failed
and continue to run with the remaining Controller nodes.
See `LP1326829 <https://bugs.launchpad.net/bugs/1326829>`_.
Management network may not restart correctly
--------------------------------------------
If br-mgmt (the bridge for the Management logical network
on the Neutron topology) is shut down from the main Controller node,
the Controller cluster may not be reachable.
Shutting down this bridge means that that Controller node
cannot communicate with any other node over the Management network.
See `LP1323277 <https://bugs.launchpad.net/fuel/+bug/1323277>`_.
Corosync is not fully scalable
------------------------------
@ -332,20 +498,6 @@ so notifications such as "image.update" and "image.upload"
are not reported in the "ceilometer meter-list" output.
See `LP1314196 <https://bugs.launchpad.net/fuel/+bug/1314196>`_.
Stopping deployment in VirtualBox may damage filesystem
-------------------------------------------------------
Clicking the "Stop Deployment" button when modifying
a provisioned node may destroy the nodes's filesystem
when running OpenStack on VirtualBox.
See `LP1316583 <https://bugs.launchpad.net/fuel/+bug/1316583>`_.
Live Migration does not work if the instance has floating IP assigned
---------------------------------------------------------------------
The migration process will fail if the instance has a floating IP
address signed.
Other limitations
-----------------
@ -369,7 +521,7 @@ Other limitations
* **Murano requires the Neutron network type.**
If you choose nova-network as the network type during deployment,
the option to install the Murano project is greyed out.
the option to install the Murano project is grayed out.
This is a design decision made by the OpenStack community;
it allows us to focus our efforts on Neutron,
and we see little demand for Murano support on Nova-network.
@ -379,7 +531,7 @@ Other limitations
For example, a Cinder node has VLANs created
and addresses obtained from the public network.
* Some of OpenStack’s services listen to all of the interfaces,
* Some OpenStack services listen to all of the interfaces,
a situation that may be detected and reported
by third-party scanning tools not provided by Mirantis.
Please discuss this issue with your security administrator
@ -389,8 +541,8 @@ Other limitations
to be automatically installed on VirtualBox
create separate host interfaces.
If a user associates logical networks
to different physical interfaces on different nodes,
it causes to network connectivity issues between OpenStack components.
with different physical interfaces on different nodes,
it causes 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 Networks tab.
@ -400,7 +552,7 @@ Other limitations
is applied regardless of the user choice
due to limitations in Ubuntu provisioning.
* The Fuel Master node services (such as PostgrSQL and RabbitMQ)
* The Fuel Master node services (such as PostgreSQL and RabbitMQ)
are not restricted by a firewall.
The Fuel Master node should live in a restricted L2 network
so this should not create a security vulnerability.
@ -416,3 +568,11 @@ Other limitations
service ceph-radosgw start
See `LP1287166 <https://bugs.launchpad.net/fuel/+bug/1287166>`_.
* We could improve performance significantly by upgrading
to a later version of the CentOS distribution
(using the 3.10 kernel or later).
See `LP1322641 <https://bugs.launchpad.net/bugs/1322641>`_.
* Docker loads images very slowly on the Fuel Master Node.
See `LP1333458 <https://bugs.launchpad.net/bugs/1333458>`_.