openstack/fuel-docs
Code Issues Proposed changes

Release Notes for 4.1.1

Browse Source 
Updated relnotes/conf.py and relnotes/index.rst for 4.1.1

Updated index.rst to say Release Notes 4.1.1

release-notes/v4-1-havana-full
- Rewrote intro following the 3.2.1 document
- Added 4.1.1 to table

release-notes/020-new-features - added "New Features in 4.1.1 section
that notes we upgraded the Havana release to 2013.2.3 and lists
HAProxy in its own namespace as a new feature.

release-notes/030-other-enhancements -- added note about Savanna/Sahara
issue

Changed 4.1 to 4.1.x as appropriate throughout

Added 042-resolved-issues -- LPs are annotated appropriately

Change-Id: I483d03f66137adca0f3d4801e00bde7f2b5f07fe
This commit is contained in:
Meg McRoberts 2014-06-03 13:39:43 -07:00
parent 2a80468b86
commit f031c5f182
9 changed files with 295 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
index.rst
View File

@ -34,7 +34,7 @@ The following Mirantis OpenStack documentation is available in PDF:
A deep dive into the structure of the Fuel OpenStack environment,
network considerations, and deployment options.
* `Release Notes 4.1 <pdf/Mirantis-OpenStack-4.1-RelNotes.pdf>`_
* `Release Notes 4.1.1 <pdf/Mirantis-OpenStack-4.1-RelNotes.pdf>`_
The Release Notes provide general information about new features,
fixed issues, and known limitations in Mirantis OpenStack |version|.

28
pages/release-notes/v4-1-havana-full.rst
View File

@ -3,30 +3,36 @@
.. _RelNotes_41:
Release Notes for Mirantis OpenStack 4.1
========================================
Release Notes for Mirantis OpenStack 4.1.1
==========================================
Mirantis, Inc. is releasing Mirantis OpenStack version 4.1.
Mirantis, Inc. is releasing Mirantis OpenStack version 4.1.1.
This version is a maintenance release to Mirantis OpenStack 4.1
and contains defect fixes and resolutions
for issues initially reported against version 4.1 or previous releases.
You do not need to install version 4.1 prior to installing 4.1.1
because the 4.1.1 release includes version 4.1.
This generally available version of Mirantis OpenStack
is based on the latest stable Havana release of OpenStack
and includes several important defect fixes to Mirantis OpenStack
as well as some minor enhancements.
is based on the latest stable Havana release of OpenStack.
These release notes supplement the product documentation and list
enhancements, resolved issues, and known issues in this version.
The following table lists the released revisions of this documentation:
+----------+-------------+--------------+
| Revision | Date | Description |
+==========+=============+==============+
| 4.1 | 07-Mar-2014 | Initial G.A. |
+----------+-------------+--------------+
+----------+--------------+---------------------+
| Revision | Date | Description |
+==========+=======+======+=====================+
| 4.1 | 07-Mar-2014 | Initial G.A. |
+----------+--------------+---------------------+
| 4.1.1 | 10-June-2014 | Maintenance Release |
+----------+--------------+---------------------+
.. include:: /pages/release-notes/v4-1/010-what-is-mirantis-openstack.rst
.. include:: /pages/release-notes/v4-1/020-new-features.rst
.. include:: /pages/release-notes/v4-1/030-other-enhancements.rst
.. include:: /pages/release-notes/v4-1/042-resolved-in-411-issues.rst
.. include:: /pages/release-notes/v4-1/040-resolved-issues.rst
.. include:: /pages/release-notes/v4-1/050-known-issues.rst
.. include:: /pages/release-notes/v4-1/060-obtain-the-product.rst

40
pages/release-notes/v4-1/020-new-features.rst
View File

@ -1,16 +1,42 @@
New Features in Mirantis OpenStack 4.1
======================================
New Features in Mirantis OpenStack 4.1.1
========================================
Mirantis OpenStack hardened packages support the latest stable OpenStack Havana maintenance release
---------------------------------------------------------------------------------------------------
The OpenStack core projects in the Mirantis OpenStack hardened packages
support the `OpenStack Havana 2013.2.2 <https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.2>`_ release.
Fuel 4.1 deploys this version of OpenStack on CentOS or Ubuntu.
support the `OpenStack Havana 2013.2.3 <https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.3>`_ release.
Fuel 4.1.1 deploys this version of OpenStack on CentOS or Ubuntu.
Fuel 4.1.0 deploys
the `OpenStack Havana 2013.2.2 <https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.2>`_ release.
HAProxy is relocated to its own namespace
-----------------------------------------
The HAProxy process
(which provides highly available load balancing
for TCP and HTTP-based applications)
is relocated to its own network namespace.
VIP (which specifies the virtual IP address and port
on which client traffic is received)
is created inside the HAProxy namespace.
This solves a number of network stability issues
that occured when Pacemaker moved VIP from one controller to another
and the Linux kernel did not drop
the corresponding TCP sessions on the controller
from which VIP was moved.
See the `HAProxy network namespace blueprint
<https://blueprints.launchpad.net/fuel/+spec/relocate-haproxy-to-its-own-network-namespace>`_.
New Features in Mirantis OpenStack 4.1
======================================
Deployments can be stopped prior to completion
----------------------------------------------
In Mirantis OpenStack 4.1,
In Mirantis OpenStack 4.1.x,
the deployment can be manually stopped prior to completion if necessary.
This is useful when a configuration mistake is recognized
or an unexpected error condition occurs within the environment.
@ -22,7 +48,7 @@ for more information.
Environments can be reset to pre-deployment state
-------------------------------------------------
Mirantis OpenStack 4.1 enables you to reset an existing environment
Mirantis OpenStack 4.1.x enables you to reset an existing environment
back to its pre-deployment state.
This returns the existing nodes to their pre-deployment bootstrap mode
but keeps them allocated to the environment
@ -36,7 +62,7 @@ for more information.
NIC Bonding is now configurable through the Fuel UI
---------------------------------------------------
Mirantis OpenStack 4.1 allows you to configure NIC Bonding
Mirantis OpenStack 4.1.x allows you to configure NIC Bonding
(also called “link aggregation”) through the Fuel UI
when configuring an environment utilizing Neutron as a network type.
In earlier releases, NIC bonding could only be configured by using the Fuel CLI.

13
pages/release-notes/v4-1/030-other-enhancements.rst
View File

@ -4,7 +4,7 @@ Other Enhancements
Murano has been updated to the latest version
---------------------------------------------
Mirantis OpenStack 4.1 includes version 0.4.1 of Murano,
Mirantis OpenStack 4.1.x includes version 0.4.1 of Murano,
an application catalog and data services lifecycle management addition for OpenStack.
This maintenance release of Murano includes several bug fixes
and the following enhancements:
@ -43,7 +43,7 @@ For detailed information, please refer to the
Savanna includes the Intel Distribution for Apache Hadoop plugin
----------------------------------------------------------------
The Savanna project provided with Mirantis OpenStack 4.1
The Savanna project provided with Mirantis OpenStack 4.1.x
includes the Intel Distribution for Apache Hadoop version 2.5.1.
This plug-in enables features such as:
@ -57,6 +57,15 @@ This plug-in enables features such as:
More information about this integration is available in the
`blueprint <https://blueprints.launchpad.net/savanna/+spec/idh-savanna-plugin>`_.
Note that the project formerly known as "Savanna"
is now called the "Sahara project";
this resolves a trademark infringement issue.
The change was made after the initial release
of Mirantis OpenStack 4.1
so the "Savanna" name is retained in
Mirantis OpenStack 4.1.1.
Additional information about Savanna can be found on the
`Savanna project home page <https://wiki.openstack.org/wiki/Savanna>`_.
Information about Intel Hadoop can be found at the

12
pages/release-notes/v4-1/040-resolved-issues.rst
View File

@ -1,5 +1,5 @@
Issues Resolved in Mirantis OpenStack 4.1
=========================================
Issues First Resolved in Mirantis OpenStack 4.1
===============================================
Ceph acting as a backend for ephemeral volumes is no longer experimental
------------------------------------------------------------------------
@ -20,7 +20,7 @@ could have led to a
`Ceph SEGV error <https://bugs.launchpad.net/fuel/+bug/1260911>`_
while extracting cloned images from RBD,
which left a small possibility that an ephemeral volume became corrupted.
This issue has been corrected in Mirantis OpenStack 4.1 and the feature is now fully supported.
This issue has been corrected in Mirantis OpenStack 4.1.x and the feature is now fully supported.
The Ceilometer section within Horizon is now enabled by default
---------------------------------------------------------------
@ -52,7 +52,7 @@ Ubuntu deployment no longer fails because of NIC ordering issues
Mirantis OpenStack sometimes failed to deploy on Ubuntu
because the Ubuntu kernel uses different ordering rules to detect NICS
compared to the CentOS kernel used by the Mirantis OpenStack bootstrap image.
This has been corrected in Fuel 4.1
This has been corrected in Fuel 4.1.x
by adding explicit interface ordering
and identifying the hardware address that correspond to the admin interface.
@ -71,7 +71,7 @@ mapping all hard drives on Vbox into a single address (sysfs PATH_ID).
When the udev daemon creates by-path links,
it rewrites the previous links with the new ones,
resulting in a single by-path link for each sdc hard drive.
Fuel 4.1 includes an internal workaround
Fuel 4.1.x includes an internal workaround
so that the number and sizes of the disk nodes match what is configured,
although the internal IDs are different after deployment.
See `LP1263648 <https://bugs.launchpad.net/fuel/+bug/1263648>`_.
@ -126,7 +126,7 @@ that was identified during the bootstrap discovery process.
Multiple network roles can share a single physical NIC
------------------------------------------------------
In Mirantis OpenStack 4.1,
In Mirantis OpenStack 4.1.x,
the earlier restrictions about networks sharing a physical NIC are removed.
One NIC can be used for all networks --
including Admin(PXE), Private, Storage, Management, and Public --

222
pages/release-notes/v4-1/042-resolved-in-411-issues.rst Normal file
View File

@ -0,0 +1,222 @@
Issues Resolved in Mirantis OpenStack 4.1.1
===========================================
Security Fixes
--------------
The following vulnerabilities are addressed:
- `LP1297848 <https://bugs.launchpad.net/fuel/+bug/1297848>`_.
Some disk drivers do not support a 4K sector size for XFS file systems
----------------------------------------------------------------------
To work around this issue,
we now use 512-byte sectors
when creating XFS file systems;
these are supported for all file system architectures.
See `LP1316266 <https://bugs.launchpad.net/fuel/+bug/1316266>`_.
Compute nodes with running instances can now be redeployed
----------------------------------------------------------
In earlier releases,
environments that contained Compute nodes with running instances
could not be redeployed
because the Puppet iptables-firewall module
did not correctly prefetch OpenStack firewall rules.
This was fixed by adding MAC match support to the firewall module,
which fixes parsing errors and allows for rules with MAC matches.
The neutron-ovs-agent on compute nodes is also notified
so it can delete saved rules from old and removed instances.
See `LP1308963 <https://bugs.launchpad.net/fuel/+bug/1308963>`_.
DHCP addresses are now valid after MySQL and Keystone failures
--------------------------------------------------------------
**dnsmasq** processes are not always terminated properly
when MySQL or Keystone fail.
This sometimes meant that DHCP addresses were not received properly
unless Pacemaker CRM restarted the neutron-dhcp-agent.
To solve this problem,
the CRM cleanup script for neutron-dhcp-agent has been modified
to inspect network namespaces on the node and react appropriately
rather than relying on information from the Neutron API.
See `LP1285929 <https://bugs.launchpad.net/fuel/+bug/1285929>`_.
Neutron agent failed if management VIP was recently moved
---------------------------------------------------------
The Pacemaker CRM start/stop/miration scripts
for Neutron L3 and DHCP agents
failed if the management VIP
(which specifies the virtual IP address and port
on which client traffic is received)
had recently been moved.
To solve this problem,
the CRM cleanup scripts for Neutron agents have been modified
to inspect network namespaces on the node and react appropriately
rather than relying on information from the Neutron API.
See `LP1287716 <https://bugs.launchpad.net/fuel/4.1.x/+bug/1287716>`_.
HAProxy sometimes failed to reload
----------------------------------
HAProxy sometimes failed to reload
because Pacemaker puppet provider returned immediately
rather than waiting for HAProxy to start on the node.
This has been fixed.
See `LP1306005 <https://bugs.launchpad.net/fuel/+bug/1306005>`_.
Heat API was not available on the public URL
--------------------------------------------
The Heat API could not be accessed over the public URL.
This was resolved by implementing proxy requests
from HAProxy to the Heat API.
See `LP1307503 <https://bugs.launchpad.net/fuel/+bug/1307503>`_.
IFUP ran prematurely when bonding NICs
--------------------------------------
IFUP (which brings a network interface up)
must run after at least one slave interface has been added;
in earlier releases, this was not guaranteed.
This has now been fixed.
See `LP1310661 <https://bugs.launchpad.net/fuel/+bug/1310661>`_
Swift rings built with wrong permissions
----------------------------------------
Swift rings were being built with root-only access permissions,
which meant that swift-proxy could not read them.
This has been fixed.
See `LP1311249 <https://bugs.launchpad.net/fuel/+bug/1311249>`_.
Neutron agents failed to start
------------------------------
The lock_path variable was not defined for Neutron agents,
which occasionally prevented them from starting.
This has been fixed.
See `LP1311634 <https://bugs.launchpad.net/fuel/+bug/1311634>`_
Neutron L3 agents could be moved unnecessarily
----------------------------------------------
Neutron L3 agents could be moved at random times,
causing outages.
This was fixed by setting stickiness=1
for the Pacemaker resource for Neutron and other services.
See `LP1312177 <https://bugs.launchpad.net/fuel/+bug/1312177>`_.
Notification for newly-spawned VMs could be broken by deployment ordering error
-------------------------------------------------------------------------------
The Neutron deployment script
sometimes tried to obtain a service tenant ID
before Kesometimes ystone was running and exposed via HAProxy.
This was fixed by ensuring that the Keystone service
and its HAProxy section are initialized
before the neutron-server is initialized.
See `LP1312614 <https://bugs.launchpad.net/fuel/+bug/1312614>`_.
Neutron L3 agent was not associated with Floating IP
----------------------------------------------------
The floating IP was sometimes not associated with the Neutron L3 agent
and so the Neutron server could not communicate with the Neutron agents.
This was because the report interval
was larger than the agent_down_time interval.
It was fixed by setting the report interval to be
one-third of the agent_down_time interval.
See `LP1315338 <https://bugs.launchpad.net/fuel/+bug/1315338>`_.
Shotgun cannot log into the host system
---------------------------------------
Shotgun (the tool used to collect information for the diagnostic snapshot)
was sometimes unable to log into deployed nodes.
This was resolved by copying the master node's public key
to its own keyring.
See `LP1316581 <https://bugs.launchpad.net/fuel/+bug/1316581>`_.
TTL has been increased for MCollective
--------------------------------------
TTL (Time To Live) has been increased for MCollective.
Previously, deployment of a new controller sometimes failed
with a message such as
"Node ... not answered by RPC, removing from db" or
"MCollective agents ... didn't respond within the alloted time."
See `LP1316720 <https://bugs.launchpad.net/fuel/+bug/1316720>`_.
Ceilometer logs were not stored on Fuel Master node
---------------------------------------------------
Ceilometer logs were not stored on the Fuel Master node
because debug logging was not implemented.
This has been fixed.
See `LP1317123 <https://bugs.launchpad.net/fuel/+bug/1317123>`_.
Debian installer truncated long log messages
--------------------------------------------
The Debian installer (used for Ubuntu nodes)
truncated long log messages
rather than splitting them into shorter messages that could all be logged.
This has been fixed.
See `LP1318747 <https://bugs.launchpad.net/fuel/+bug/1318747>`_.
Keystone deployment script sometimes failed to initialize Keystone database
---------------------------------------------------------------------------
The Keystone deployment script would sometimes try
to run the db_sync command to initialize the Keystone database
too early in the deployment process.
This was fixed by adding a retry mechanism
to ensure that the database is initialized
as soon as possible.
See `LP1319087 <https://bugs.launchpad.net/fuel/+bug/1319087>`_.
Predefined Neutron networks were not available in Horizon
---------------------------------------------------------
Horizon could not access the predefined Neutron networks
when the admin tenant name was changed to a value
other than the default "admin" name.
The correct admin tenant name is now used
to create predefined networks with Neutron.
See `LP1319942 <https://bugs.launchpad.net/fuel/+bug/1319942>`_.
Ubuntu provisioning sometimes failed
------------------------------------
Ubuntu provisioning sometimes failed
when Ceph OSD was placed on the Controller node
rather than on a separate Storage node.
This has been fixed so that Ceph OSD can run on a Controller node
for demonstration purposes.
However, even with this problem fixed,
placing Ceph OSD on Controllers
is highly unadvisable for production environments
because it can severely degrade the Controller's performance.
See `LP1319995 <https://bugs.launchpad.net/fuel/+bug/1319995>`_.
AMQP/RabbitMQ nodes are now shuffled for all OpenStack services
---------------------------------------------------------------
AMQP/RabbitMQ nodes are now assigned to non-compute nodes
using a Round Robin algorithm
to better balance network traffic and improve performance.
See `LP1320184 <https://bugs.launchpad.net/fuel/+bug/1320184>`_.
Savanna deployment sometimes failed
-----------------------------------
Savanna deployment sometimes failed
because Savanna set some filters
that conflicted with those set by the Nova scheduler.
These issues have been resolved.
See `LP1321284 <https://bugs.launchpad.net/fuel/+bug/1321284>`_.

4
pages/release-notes/v4-1/050-known-issues.rst
View File

@ -1,5 +1,5 @@
Known Issues in Mirantis OpenStack 4.1
======================================
Known Issues in Mirantis OpenStack 4.1.x
========================================
Murano OSTF test for Linux Apache Service fails
-----------------------------------------------

4
relnotes/conf.py
View File

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

2
relnotes/index.rst
View File

@ -3,7 +3,7 @@
.. cssclass:: header-table
+-------------------------------------+-----------------------------------+
| Mirantis OpenStack v4.1 | .. cssclass:: right|
| Mirantis OpenStack v4.1.1 | .. cssclass:: right|
| | |
| | Release Notes |
+-------------------------------------+-----------------------------------+