Release Notes for 4.1.1
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
parent
2a80468b86
commit
f031c5f182
@ -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|.
|
||||
|
||||
@ -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. |
|
||||
+----------+-------------+--------------+
|
||||
+----------+--------------+---------------------+
|
||||
| 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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
222
pages/release-notes/v4-1/042-resolved-in-411-issues.rst
Normal 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>`_.
|
||||
|
||||
@ -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
|
||||
-----------------------------------------------
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
.. cssclass:: header-table
|
||||
|
||||
+-------------------------------------+-----------------------------------+
|
||||
| Mirantis OpenStack v4.1 | .. cssclass:: right|
|
||||
| Mirantis OpenStack v4.1.1 | .. cssclass:: right|
|
||||
| | |
|
||||
| | Release Notes |
|
||||
+-------------------------------------+-----------------------------------+
|
||||
|
||||
Loading…
Reference in New Issue
Block a user