openstack/fuel-docs
Code Issues Proposed changes

Release Notes 5.1 -- additions

Browse Source 
Edited Known and Resolved issues sections.
Added lacking MOS and Fuel bugs.

Change-Id: I5b6158df132254406c6227232625117f0b7aa589
This commit is contained in:
Meg McRoberts
2014-08-27 17:49:02 -07:00
committed by Dmitry Borodaenko
parent 407490a35c
commit c3c76210b2
13 changed files with 1642 additions and 86 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
pages/operations/8500-ceilometer.rst
View File

@@ -38,7 +38,7 @@ that are currently implemented, see
For a complete list of Configuration Options, see
`<http://docs.openstack.org/developer/ceilometer/configuration.html>`_
.. ceilometer-api-ops:
.. _ceilometer-api-ops:
Performance and database backend
--------------------------------

5
pages/reference-architecture/network-concepts/6010-logical-networks.rst
View File

@@ -93,3 +93,8 @@ Private Network (Fixed network)
Just like the public network, the private network should be isolated from
other networks in the cluster for security reasons.
If you want to combine another network
with the Admin network on the same NIC,
you must leave the Admin network untagged.
This is the default configuration and cannot be changed in the Fuel UI
although you could modify it by manually editing configuration files.

13
pages/reference-architecture/neutron-intro/0200-neutron-tech-intro.rst
View File

@@ -10,13 +10,12 @@ created for a single tenant, forming an isolated L2 network called a
"private network". Each private network can support one or many IP subnets.
Private networks can be segmented using one of two different topologies:
* **VLAN segmentation** "Private network" traffic is managed by
Neutron by the use of a dedicated network adapter. This network adapter must be
attached to a untagged network port. This network segment also must be
reserved only for Neutron on each host (Computes and Controllers). You should
not use any other 802.1q VLANs on this network for other purposes.
Additionally, each private network requires its own dedicated VLAN, selected
from a given range configured in Fuel UI.
* **VLAN segmentation** Ideally, "Private network" traffic is located
on a dedicated network adapter that is attached to an untagged network port.
However, this network may share a network adapter with other networks.
In this case, you should use non-intersected VLAN-ID ranges
for "Private network" and other networks.
* **GRE segmentation** In this mode of operation, Neutron does not
require a dedicated network adapter. Neutron builds a mesh of GRE tunnels from
each compute node and controller nodes to every other node. Private networks

2
pages/release-notes/v5-1-icehouse-full.rst
View File

@@ -21,7 +21,7 @@ The following table lists the released revisions of this documentation:
+==========+===============+==============+
| 5.1 Beta | 26-Aug-2014 | Prelim info |
+----------+---------------+--------------+
| 5.1 | ??-Sep-2014 | Initial G.A. |
| 5.1 | 23-Sep-2014 | Initial G.A. |
+----------+---------------+--------------+
.. include:: /pages/release-notes/v5-1/010-what-is-mirantis-openstack.rst

10
pages/release-notes/v5-1/010-what-is-mirantis-openstack.rst
View File

@@ -47,6 +47,16 @@ through a simple-to-use graphical user experience. Baked into Fuel are:
This library also empowers organizations to fold additional drivers
or integrations into the deployed environment.
Mirantis OpenStack, by default, enables those features in the Fuel Project
that Mirantis has certified and confirmed as production ready.
However, it also includes some newer features
that are marked as "experimental";
they are less-hardened but are integrated into the product
for customers who can tolerate some risk.
These experimental features can be enabled for Mirantis OpenStack
before you install the Fuel Master Node;
see :ref:`experimental-features-op`.
Mirantis Support
----------------

2
pages/release-notes/v5-1/020-new-features.rst
View File

@@ -51,6 +51,8 @@ so Mirantis is offering the 5.0.2 release
to provide the fixes that can be applied to the existing architecture.
See :ref:`update-openstack-environ-ug` for instructions.
You can also use Fuel CLI to update the environment;
see :ref:`cli_usage` for details.
.. note::
If you are running Fuel 4.x or earlier,

33
pages/release-notes/v5-1/030-other-enhancements.rst
View File

@@ -95,14 +95,33 @@ Ceph storage platform has been updated to Firefly
Mirantis OpenStack 5.1 deploys the Ceph version 0.80.4 ("Firefly").
Previous versions of Mirantis OpenStack deployed the Ceph version 0.67.x ("Dumpling").
All upstream neutron packages are included in the 5.1 ISO file
--------------------------------------------------------------
Improvements to Pacemaker and Corosync
--------------------------------------
These packages are made available as a convenience;
Mirantis does not fully support these packages
or guarantee that they work.
A comparable set of packages are provided on the mirrors
for the 5.0.1 and 4.1.x releases of Mirantis OpenStack.
Structural changes have been implemented for Pacemaker and Corosync
to improve the stability, performance, and scalability
of highly available clusters.
These are detailed in `HA Improvements of pacemaker and corosync <https://blueprints.launchpad.net/fuel/+spec/ha-pacemaker-improvements>`_.
This resolves `LP1283062 <https://bugs.launchpad.net/fuel/+bug/1283062>`_,
`LP1312627 <https://bugs.launchpad.net/fuel/+bug/1312627>`_,
and other issues.
All upstream Neutron plugins are included in the 5.1 ISO file for 5.1 and 5.0.2
-------------------------------------------------------------------------------
Packages for all upstream Neutron plugins
are now included in the repositories on the Fuel Master node.
* These packages are made available as a convenience,
to enable users to customize their deployments.
Otherwise, customers would have to locate and use packages
that may not have been built from the same sources
and could cause problems.
* Mirantis does not fully support these packages
or guarantee that they work.
This resolves `LP1330610 <https://bugs.launchpad.net/fuel/+bug/1330610>`_.
Additional information
----------------------

8
pages/release-notes/v5-1/038-resolved-ha-issues.rst
View File

@@ -55,8 +55,8 @@ See `LP1297355 <https://bugs.launchpad.net/fuel/+bug/1297355>`_,
and `Reliable Galera OCF Script
<https://blueprints.launchpad.net/fuel/+spec/reliable-galera-ocf-script>`_.
Keystone performance issues if memcache instance fails [rewrite text -- In progress for 5.1]
--------------------------------------------------------------------------------------------
Keystone performance issues if memcache instance fails
------------------------------------------------------
When several OS controller nodes are used
with 'memcached' installed on each of them,
@@ -73,9 +73,7 @@ without such issues.
As a permanent workaround,
you can switch the Keystone token backend from `memcached` to MySQL.
See `LP1332058 <https://bugs.launchpad.net/keystone/+bug/1332058>`_
and `LP1340657 <https://bugs.launchpad.net/bugs/1340657>`_
(related to `LP1332058 <https://bugs.launchpad.net/keystone/+bug/1332058>`_).
and `LP1340657 <https://bugs.launchpad.net/fuel/+bug/1340657>`_
RabbitMQ Service now restarts properly after rebooting the primary Controller node
----------------------------------------------------------------------------------

1091
pages/release-notes/v5-1/040-resolved-issues.rst
View File

File diff suppressed because it is too large Load Diff

553
pages/release-notes/v5-1/050-known-issues.rst
View File

@@ -1,7 +1,6 @@
Known Issues in Mirantis OpenStack 5.1
========================================
======================================
This section is under development at this time.
For current information about Issues and Blueprints
for Mirantis OpenStack 5.1, see the
`Fuel for OpenStack 5.1 Milestone <https://launchpad.net/fuel/+milestone/5.1>`_
@@ -25,6 +24,22 @@ but it has some known limitations:
but you must select it on the Fuel :ref:`Settings<settings-storage-ug>` page.
See `LP1316377 <https://bugs.launchpad.net/fuel/+bug/1316377>`_.
* On CentOS in HA mode on vCenter's machine on primary controller OpenStack
deployment crashes because RabbitMQ can not connect to primary controller.
See `LP1370558 <https://bugs.launchpad.net/fuel/+bug/1370558>`_.
* NoVNCproxy does not work with vCenter.
See `LP1368745 <https://bugs.launchpad.net/fuel/+bug/1368745>`_.
* The default Ceilometer configuration
does not collect metering information for vCenter.
This also means that, when the vCenter installation is used with Heat,
autoscaling does not work as well
because the alarms sent to Heat are implemented with meters.
See `LP1370700 <https://bugs.launchpad.net/fuel/+bug/1370700>`_.
You can manually configure Ceilometer to collect vCenter metering;
see :ref:`ceilometer-ops` for instructions.
Known limitations for the VMware NSX integration
------------------------------------------------
@@ -39,15 +54,33 @@ but it has some known limitations:
register OpenvSwitches in NSX and 'br-int' bridges on nodes would not be
configured properly, because older ones with same names exist in NSX cluster.
* If NSX cluster resides in a separate network that has L3 connectivity with
* If the NSX cluster resides in a separate network that has L3 connectivity with
the OpenStack Public network, you must enable Public address assignment for all
nodes, see :ref:`neutron-nsx-arch`.
* In HA mode on NSX machine, OpenStack deployment crashes due to unavailable Neutron and Keystone services.
See `LP1369529 <https://bugs.launchpad.net/bugs/1369529>`_.
* When there are no NSX settings, Fuel UI allows clicking "Deploy changes".
Make sure that you have specified NSX settings.
See `LP1347682 <https://bugs.launchpad.net/bugs/1347682>`_.
VMDK requires operating systems that support SCSI adapters
----------------------------------------------------------
When using the VMDK driver,
instances must be deployed to use operating systems
that support SCSI adapter.
This means that the CirrOS image (which only supports IDE disks)
cannot be used with VMDK.
The `VMware vSphere documentation <http://docs.openstack.org/trunk/config-reference/content/vmware.html#VMware_converting_images>`_
contains more information.
See `LP1365468 <https://bugs.launchpad.net/bugs/1365468>`_.
Known limitations for the Mellanox SR-IOV plug-in
-------------------------------------------------
The Mellanox :ref:`sr-iov-term` plug-in is fully integrated
The Mellanox SR-IOV plug-in is fully integrated
into Mirantis OpenStack 5.1
but it has some known limitations:
@@ -62,21 +95,35 @@ but it has some known limitations:
you must make additional configuration changes manually
or through a script.
* 3rd party adapters based on Mellanox chipset may not have SR-IOV enabled
* 3rd party adapters based on the Mellanox chipset may not have SR-IOV enabled
by default. In such a case, please contact the device manufacturer for
configuration instructions and for the required firmware.
Mellanox provides additional information in their
`HowTo Install Mirantis Fuel 5.1 OpenStack with Mellanox Adapters Support
<http://community.mellanox.com/docs/DOC-1474>`_ document,
including example images to use with the Mellanox SR-IOV plugin
and advanced configuration instructions
(for example, instructions to increase the number of virtual functions).
* Mellanox OEM adapter cards may be burned with SR-IOV disabled.
In such cases,
you may need to burn a special firmware version
to enable SR-IOV.
* External network is not configured when changing the ML2 mechanism
to Mellanox and Open vSwitch.
When installing Centos HA with Neutron with VLAN
and changing the ML2 mechanism to Mellanox and Open vSwitch,
the external network is not configured after deployment.
See `LP1369988 <https://bugs.launchpad.net/bugs/1369988>`_.
* Mellanox provides additional information in their `HowTo Install Mirantis Fuel 5.1 OpenStack with
Mellanox Adapters Support
<http://community.mellanox.com/docs/DOC-1474>`_ document,
including example images to use with the Mellanox SR-IOV plugin
and advanced configuration instructions
(for example, instructions to increase the number of virtual functions).
and advanced configuration instructions.
Zabbix Issues
-------------
Phase I of Zabbix is included as an `experimental<experimental-features-term>` feature
Phase I of Zabbix is included as an
:ref:`Experimental<experimental-features-term>` feature
in Mirantis OpenStack 5.1.
This version has the following known issues:
@@ -87,23 +134,58 @@ This version has the following known issues:
to a remote (outside the current environment) Zabbix server
- Zabbix agents cannot be configured to report
to multiple Zabbix servers.
- There are false Zabbix issues after deploying with Nova-network.
This can be resolved via attaching "Template App OpenStack Nova Network" to compute nodes
instead of controller nodes. See `LP1365171 <https://bugs.launchpad.net/fuel/+bug/1365171>`_.
- List of "Zabbix monitoring items" is different from "Zabbix overview" list.
See `LP1352319 <https://bugs.launchpad.net/bugs/1352319>`_.
See :ref:`zabbix-plan` for more information.
RabbitMQ users may be lost
--------------------------
Additional MongoDB roles cannot be added to an existing deployment
------------------------------------------------------------------
Murano users may be lost
when the Primary Controller in an HA cluster is shut down.
This is because RabbitMQ does not handle Murano users correctly.
See `LP1372483 <https://bugs.launchpad.net/fuel/+bug/1372483>`_.
Fuel 5.0.1 installs :ref:`mongodb-term`
as a backend for :ref:`ceilometer-term`.
Any 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
(one for each Controller node is ideal)
during the initial deployment.
See `LP1308990 <https://bugs.launchpad.net/fuel/+bug/1308990>`_.
As a workaround, you can reset the RabbitMQ credentials
as follows:
#. Obtain the OS RabbitMQ credentials:
::
grep -E "(^rabbit_user|^rabbit_pass)" /etc/nova/nova.conf
rabbit_userid=USERNAME
rabbit_password=SOMEPASS
#. Edit the */etc/murano/murano.conf* file on all Controllers
in the deployed environment.
Add the values obtained above to the [DEFAULT] section of the file:
::
...
rabbit_userid=USERNAME
rabbit_password=SOMEPASS
...
#. Restart the **murano-api** and **murano-engine** services
on all Controllers in the deployed environment.
- For Ubuntu:
::
service murano-api restart
service murano-engine restart
- For CentOS:
::
service openstack-murano-api restart
service openstack-murano-engine restart
Fuel upgrade fails if custom python modules are installed as eggs
-----------------------------------------------------------------
@@ -113,13 +195,34 @@ using pip or easy_install
may cause the Fuel upgrade script to fail.
See `LP1341564 <https://bugs.launchpad.net/fuel/+bug/1341564>`_.
Network verification fails if a node is offline
-----------------------------------------------
Fuel uses ports that may be used by other services
--------------------------------------------------
Network verification can fail if a node is offline
because Astute runs network verification
but Astute does not know which nodes are online..
See `LP1318659 <https://bugs.launchpad.net/fuel/+bug/1318659>`_.
Fuel uses some high ports that may be used by other services
such as RPC, NFS, passfive FTP (ephemeral ports 49000-65535).
In some cases, this can lead to a port conflict during service restart.
To avoid this, issue the following command
so that ports above 49000 are not automatically assigned to other services:
`sysctl -w 'sys.net.ipv4.ip_local_reserved_ports=49000'`
See `LP116422/ <https://review.openstack.org/#/c/116422/>`_.
Docker is not updated
---------------------
The OpenStack update procedure does not update Docker.
This results in a number of issues; see
`LP1360161 <https://bugs.launchpad.net/fuel/+bug/1360161>`_
Network verification issues
---------------------------
* Network verification can fail if a node is offline
because Astute runs network verification
but Astute does not know which nodes are online..
See `LP1318659 <https://bugs.launchpad.net/fuel/+bug/1318659>`_.
* The network verification checker does not test OVS VLANs.
See `LP1350623 <https://bugs.launchpad.net/bugs/1350623>`_.
Multiple TestVM images may be created
-------------------------------------
@@ -143,6 +246,7 @@ Some UEFI chips (such as the Lenovo W520)
do not emulate legacy BIOS
in a way that is compatible with the grub settings
used for the Fuel Master node.
This issue also affects servers used
as Controller, Compute, and Storage nodes;
because they are booted from PXE rom
@@ -155,6 +259,8 @@ do not include UEFI images.
See `LP1291128 <https://bugs.launchpad.net/fuel/+bug/1291128>`_
and the `UEFI support blueprint <https://blueprints.launchpad.net/fuel/+spec/uefi-support>`_.
Fuel may not allocate enough IP addresses for expansion
-------------------------------------------------------
@@ -167,6 +273,7 @@ This may mean that the IP pool
is too small to support additional nodes
added to the environment
without redeploying the environment.
See `LP1271571 <https://bugs.launchpad.net/fuel/+bug/1271571>`_
for a detailed description of the issues
and pointers to blueprints of proposed solutions.
@@ -223,20 +330,42 @@ soft trunks and hard trunks:
you should use fewer than 50 VLANs in the Neutron VLAN mode.
Fuel also provides another option here:
using the experimental ?? kernel.
using the experimental Fedora long-term support 3.10 kernel.
This option has had minimal testing
and may invalidate your agreements with your hardware vendor.
But using this kernel may allow you to use VLAN tagged packets
without using VLAN splinters,
which can provide significant performance advantages.
See :ref:`ovs-arch`
for more information about using Open VSwitch.
Ceph nodes are not updated
--------------------------
When updating the environment from 5.0.x to 5.0.2,
the Ceph nodes are not updated.
You can update the Ceph nodes manually.
- Update the environment to 5.0.2.
- Restart the monitors.
- Run the **ceph pg dump** command
and check the output;
if unclean pages are found,
resolve these issues before updating the Ceph nodes.
- After all monitors are restarted,
update the code on the OSD nodes one by one,
restart the OSD service,
and wait until all OSD nodes have rebuilt cleanly.
See `LP1363983 <https://bugs.launchpad.net/fuel/+bug/1363983>`_.
Placing Ceph OSD on Controller nodes is not recommended
-------------------------------------------------------
Placing Ceph OSD on Controllers is highly discouraged because it can severely
Placing Ceph OSD on Controllers is highly unadvisable because it can severely
degrade controller's performance.
It is better to use separate storage nodes
if you have enough hardware.
@@ -250,8 +379,23 @@ 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>`_.
RAID-1 spans all configured disks on a node [Needs 5.1 clarification]
---------------------------------------------------------------------
HP BL120/320 RAID controller line is not supported
--------------------------------------------------
You should contact Mirantis to get a non-standard kernel ISO.
Note, that it is impossible to update the kernel if there are no drivers for this
version. This happens because the source code for the hpvsa module is not open and
HP issues the hpvsa binaries for specific kernel versions only.
They do not always coincide with the ones used in Fuel with Ubuntu.
Currently, no equipment for testing is available and the testing itself can not
be performed due to closed HP VSA source code. ISO may be assembled only for kernel
versions, provided by HP. See `LP1359331 <https://bugs.launchpad.net/bugs/1359331>`_.
For information on some kernel modules, compiled for specific kernels' versions,
see `HP storage <https://launchpad.net/~hp-iss-team/+archive/ubuntu/hp-storage>`_. and
`hpvsa update <https://launchpad.net/~hp-iss-team/+archive/ubuntu/hpvsa-update>`_.
RAID-1 spans all configured disks on a node
-------------------------------------------
RAID-1 spans all configured disks on a node,
putting a boot partition on each disk
@@ -267,12 +411,12 @@ This example is for a system that has three disks: sda, sdb, and sdc.
Fuel will provision sda and sdb as RAID-1 for OpenStack
but sdc will not be used as part of the RAID-1 array:
1. Use the Fuel CLI to obtain provisioning data:
#. Use the Fuel CLI to obtain provisioning data:
::
fuel provisioning --env-id 1 --default -d
2. Remove the drive which you do not want to be part of RAID:
#. Remove the drive which you do not want to be part of RAID:
::
- size: 300
@@ -284,12 +428,12 @@ but sdc will not be used as part of the RAID-1 array:
type: raid
3. Run deployment
#. Run deployment
::
fuel provisioning --env-id 1 -u
4. Confirm that your partition is not included in the RAID array:
#. Confirm that your partition is not included in the RAID array:
::
[root@node-2 ~]# cat /proc/mdstat
@@ -344,7 +488,303 @@ the controller node is unable to locate the HDD
and the environment cannot be redeployed.
See `LP1370006 <https://bugs.launchpad.net/fuel/+bug/1370006>`_.
Evacuate fails on Ceph backed volumes
-------------------------------------
VM instances that use ephermeral drives with Ceph RBD as the backend
cannot be evacuated using the **nova evacuate** command
because of an error in the instance rebuild logic.
To move such instances to another compute node,
use live migration.
In order to be able to rebuild VM instances
from a failed compute node,
use Cinder volume backed instances.
See `LP1367610 <https://bugs.launchpad.net/mos/+bug/1367610>`_
and the upstream `LP1249319 <https://bugs.launchpad.net/nova/+bug/1249319>`_.
Controller has unallocated space when Ceph is used as image backend
-------------------------------------------------------------------
When using Ceph as the backend for Glance image storage,
unallocated space is left on the Controller.
See `LP1295717 <https://bugs.launchpad.net/bugs/1295717>`_.
This is being addressed as part of the
`volume manager refactoring <https://blueprints.launchpad.net/fuel/+spec/volume-manager-refactoring>`_
that is under development.
Hypervisor summary displays incorrect total storage for Ceph ephemeral storage
------------------------------------------------------------------------------
The Horizon Admin/Hypervisors Disk Usage field
shows an incorrect value when Ceph is used as the back end for ephemeral storage.
The value show in a sum of all Ceph storage seen on each storage node
instead of the actual amount of Ceph storage.
See `LP1359989 <https://bugs.launchpad.net/bugs/1359989>`_.
Horizon falsely shows that the external gateway is down
-------------------------------------------------------
In OpenStack environments that use Neutron and Open vSwitch on the routers,
Horizon may show that the external gateway (router_gateway) is down
when all networking is functional.
This happens because Horizon and the Neutron client
query port status from the database
but the agents do not update this status.
When this happens, instances can access the outside world
and be accessed from the outside world by their floating IP addresses
so this error can be ignored.
See `LP1323608 <https://bugs.launchpad.net/bugs/1323608>`_.
Horizon asks for username and password twice after session timeout
------------------------------------------------------------------
Users have to log into Horizon twice after a session times out.
This happens when both the Keystone token
and the Horizon session expire at the same time.
Because the session has expired,
the token expiration cannot be checked when the user is logged out.
So the user logs into Horizon and then the session sees that the token has expired
so requires a second login for that.
See `LP1353544 <https://bugs.launchpad.net/bugs/1353544>`_.
Horizon filter displays long objects incorrectly
------------------------------------------------
Objects that are bigger than one page
may be displayed incorrectly in Horizon.
The amount of data Horizon displays per page can be modified
with **Settings->User Settings->Items Per Page**
When pagination is switched for any table.
See `LP1352749 <https://bugs.launchpad.net/bugs/1352749>`_.
Ceilometer does not correctly poll Ceph as a back-end for Swift
---------------------------------------------------------------
When Ceph and the Rados Gateway is used for Swift,
Ceilometer does not poll Ceph
because the endpoints between Swift and Ceph are incompatible.
See `LP1352861 <https://bugs.launchpad.net/bugs/1352861>`_.
Bulk operations are not supported for Swift using Ceph as a backend
-------------------------------------------------------------------
When Swift is used with Ceph Rados GW enabled as the backend,
bulk operations are not supported.
See `LP1361036 <https://bugs.launchpad.net/bugs/1361036>`_.
MongoDB cannot store dictionary objects with keys that use $ and . special characters
-------------------------------------------------------------------------------------
The special characters '.' and '$' are special characters for the MongoDB database
and so cannot be used as keys in dictionary objects.
When Ceilometer processes data samples
that contain these characters in the resource metadata
(for example, has tag names with dots in them),
the sample writing fails.
This usually occurs when metric data is collected
from images with special tags
(such as images Sahara creates with tags like '_sahara_tag_1.2.1').
All data samples that do not contain these forbidden symbols
are processed as usual without any problems.
Do not create images, VMs, and other cloud resources
that contain resource metadata keys that use the $ and . special characters.
See `LP1360240 <https://bugs.launchpad.net/bugs/1360240>`_.
Additional MongoDB roles cannot be added to an existing deployment
------------------------------------------------------------------
Fuel installs :ref:`mongodb-term`
as a backend for :ref:`ceilometer-term`.
Any 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
(one for each Controller node is ideal)
during the initial deployment.
See `LP1308990 <https://bugs.launchpad.net/fuel/+bug/1308990>`_.
Shotgun does not check available disk space before taking a diagnostic snapshot
-------------------------------------------------------------------------------
Shotgun does not ensure that adequate disk space is available
for the diagnostic snapshot.
Users should manually verify the disk space
before taking a diagnostic snapshot.
See `LP1328879 <https://bugs.launchpad.net/bugs/1328879>`_.
Diagnostic snapshot does not have /var/log/remote symlink
---------------------------------------------------------
The diagnostic snapshot skips the symbolic link
from */var/log/remote* to */var/log/docker-logs/remote*.
See `LP1340615 <https://bugs.launchpad.net/bugs/1340615>`_.
Spurious "Critical error" appears in neutron-openvswitch-agent.log
------------------------------------------------------------------
A Critical error is logged in the *neutron-openvswitch-agent.log*
on the Compute node.
It does not affect the behavior of Neutron networking
and can be ignored.
This is related to the upstream
`LP1246848 <https://bugs.launchpad.net/nova/+bug/1246848>`_.
* When ovs-agent is started, Critical error appears.
See `LP1347612 <https://bugs.launchpad.net/bugs/1347612>`_.
Fuel default disk partition scheme is sub-optimal
-------------------------------------------------
* All available hardware LUNs under LVM are used and spanned across;
for example, OpenStack and guest traffic are coupled.
See `LP1306792 <https://bugs.launchpad.net/bugs/1306792>`_.
* On target nodes that use Ubuntu as the operating system,
Ubuntu provisioning applies the default Base System partition
even if the user chose a different scheme.
Horizon performance is degraded when a node is down
---------------------------------------------------
Horizon uses memcached servers for caching
and it connects to each one directly.
If one of the nodes is down so that its memcached server does not respond,
Horizon operations may be delayed.
See `LP1367767 <https://bugs.launchpad.net/bugs/1367767>`_.
You can perform the following workaround:
To work around this, edit
the */etc/openstack-dashboard/local_settings* file
and temporarily remove the IP:PORT string from the LOCATION line
for the problem controller from the CACHE structure:
::
CACHES = {
'default': {
'BACKEND' : 'django.core.cache.backends.memcached.MemcachedCache',
'LOCATION' : "192.168.0.3:11211;192.168.0.5:11211;192.168.0.6:11211"
},
Then restart the Apache web server.
New node may not boot because of IOMMU issues
---------------------------------------------
A new node fails when trying to boot into bootstrap.
To fix this issue,
add the "intel_iommu=off" kernel parameter on the Fuel Master node
with the following console command on master node:
::
`dockerctl shell cobbler cobbler profile edit --name bootstrap --kopts="intel_iommu=off" --in-place`
See `LP1324483 <https://bugs.launchpad.net/bugs/1324483>`_.
Anaconda fails with LVME error on CentOS
----------------------------------------
Anaconda fails with LVME error: deployment was aborted by provisioning timeout,
because installation of CentOS failed on one of compute nodes.
See `LP1321790 <https://bugs.launchpad.net/bugs/1321790>`_.
This is related to known issues with Anaconda.
During traceback, and interface with an IP address on admin subnet is not found
-------------------------------------------------------------------------------
When traceback is in process, an interface with IP address
that belongs to administrator's subnet, can not be found.
This happens because the configuration was updated in the base
and the node still has out-of-date configuration.
See `LP1355237 <https://bugs.launchpad.net/bugs/1355237>`_.
Fuel GUI does not prevent overlapping IP ranges
-----------------------------------------------
Fuel menu allows IP ranges that overlap in PXE setup.
When configuring IP ranges, be very careful not to use DHCP addresses
that overlap the Static addresses used.
See :ref:`public-floating-ips-arch` for more information.
See `LP1365067 <https://bugs.launchpad.net/bugs/1365067>`_.
Invalid node status after restoring Fuel Master node from backup
----------------------------------------------------------------
Invalid node status for nodes modified since backup after restore.
Nodes added to an environment after a backup may be report as offline.
Reboot any bootstrapped nodes after restoring your Fuel Master from a backup.
See `LP1347718 <https://bugs.launchpad.net/bugs/1347718>`_.
Known Issues in Mirantis OpenStack 5.1 and 5.0.2
================================================
File injection fails when an instance launches
----------------------------------------------
Instances with file injection cannot be launched
after the OpenStack environment is launched.
Instances that do not require file injection can be launched.
As a workaround, execute the **update-guestfs-appliance** command
on each Compute node.
See `LP1335697 <https://bugs.launchpad.net/bugs/1335697>`_.
Some components are omitted when upgrading to Release 5.0.2
-----------------------------------------------------------
* Some packages are not updated on nodes after Fuel upgrade.
See `LP1364586 <https://bugs.launchpad.net/bugs/1364586>`_.
* The upgrade procedure does not update packages
that are part of the control plane rather than OpenStack.
This includes the Fuel agent, mcollective agent, and the network checker.
Not upgrading these components means
that bugs fixed in those packages are not applied
to environments that were previously deployed
and introduces some limitations
for the actions that can be added or modified
to the Astute network checker.
See `LP1343139 <https://bugs.launchpad.net/bugs/1343139>`_.
Timeout errors may occur when updating your environment from 5.0 to 5.0.2
-------------------------------------------------------------------------
When updating the environment from 5.0 to 5.0.2,
a "timeout exceeded" error may occur.
See `LP1367796 <https://bugs.launchpad.net/bugs/1367796>`_.
Glance API log contains "Container HEAD failed" errors
------------------------------------------------------
After a successful deployment,
the glance-api log reports errors.
See `LP1325917 <https://bugs.launchpad.net/bugs/1325917>`_.
OSTF (Health Check) issues
--------------------------
* Platform OSTF tests fail with "HTTP unauthorized" error.
See `LP1349408 <https://bugs.launchpad.net/bugs/1349408>`_.
* 'Create volume and attach it to instance' OSFT does not work.
See `LP1346133 <https://bugs.launchpad.net/bugs/1346133>`_.
* OSTF provides wrong failure message for ping probes.
See `LP1323433 <https://bugs.launchpad.net/bugs/1323433>`_.
* "Request image list" OSTF test fails for environment with 'error' status.
See `LP1330458 <https://bugs.launchpad.net/bugs/1330458>`_.
* During OSTF tests, "Time limit exceeded while waiting
for 'ping' command to finish" message appears.
See `LP1339691 <https://bugs.launchpad.net/bugs/1339691>`_.
* After update, Sahara OSTF tests are displayed in HA suite instead of Platform test.
See `LP1357330 <https://bugs.launchpad.net/bugs/1357330>`_.
* After resetting the environment, OSTF test results from the last
environment are still displayed.
See `LP1338669 <https://bugs.launchpad.net/bugs/1338669>`_.
Other limitations
@@ -377,6 +817,19 @@ Other limitations
* Some OSTF tests do not give descriptive message when they fail.
See `LP1371051 <https://bugs.launchpad.net/fuel/+bug/1371051>`_.
* **Murano changes deployment status to "successful" when Heat stack failed.**
Murano uses Heat to allocate OpenStack resources;
therefore one of the first steps of Environment
deployment is creation of stack. Creation of stack may
fail due to various reasons but unfortunately this failure
will not be detected by Murano and overall Environment
deployment will be reported as successful.
See `LP1353589 <https://bugs.launchpad.net/bugs/1353589>`_.
* L3 agent takes more than 30 seconds
to failover to a standby controller
when a controller node fails.
See `LP1328970 <https://bugs.launchpad.net/bugs/1328970>`_.
* Deployments done through the Fuel UI
create all of the networks on all servers
@@ -399,12 +852,6 @@ Other limitations
Please check to see if this has happened prior to deployment
by clicking on the “Verify Networks” button on the Networks tab.
* When configuring disks on nodes where Ubuntu has been selected as the host OS,
the Base System partition modifications are not properly applied.
The default Base System partition
is applied regardless of the user choice
due to limitations in Ubuntu provisioning.
* The Fuel Master node services (such as PostgrSQL and RabbitMQ)
are not restricted by a firewall.
The Fuel Master node should live in a restricted L2 network
@@ -429,3 +876,19 @@ Other limitations
* Docker loads images very slowly on the Fuel Master Node.
See `LP1333458 <https://bugs.launchpad.net/bugs/1333458>`_.
* When using Ubuntu, in rare cases some nodes may stay
on the grub prompt. It may occur more frequently if the node is power-cycled
during the boot process. You should press Enter to continue booting.
See `LP1356278 <https://bugs.launchpad.net/bugs/1356278>`_.
* :ref:`Fuel CLI<cli_usage>` can not be run by a non-root user.
See `LP1355876 <https://bugs.launchpad.net/bugs/1355876>`_.
* Large number of disks may fail Ubuntu installation.
See `LP1340414 <https://bugs.launchpad.net/bugs/1340414>`_.
* IP ranges can not be updated for management and storage networks.
See `LP1365368 <https://bugs.launchpad.net/bugs/1365368>`_.

6
pages/release-notes/v5-1/060-obtain-the-product.rst
View File

@@ -7,4 +7,8 @@ if you deploy it using the Mirantis OpenStack hardened packages.
The ISO and IMG files are available in the Mirantis OpenStack download section
of the `Mirantis Portal <http://software.mirantis.com>`_.
Here, you will also find the Oracle VirtualBox scripts
to enable quick and easy deployment of a multi-node OpenStack cloud for evaluation purposes.
to enable quick and easy deployment of a multi-node OpenStack cloud for evaluation purposes;
see the `0 to OpenStack in 60 Minutes or less
<https://software.mirantis.com/quick-start/>`_.
`Mirantis OpenStack Express <https://express.mirantis.com/home>`_
is a hosted private cloud available on a subscription basis.

2
pages/release-notes/v5-1/070-support.rst
View File

@@ -10,5 +10,7 @@ Mirantis, Fuel, the Mirantis logos and other Mirantis marks are trademarks or
registered trademarks of Mirantis, Inc. in the U.S. and/or certain other countries.
Ubuntu is a registered trademark of Canonical Ltd.
VirtualBox is a registered trademark of Oracle Corporation.
VMware, NSX, vCenter, and ESXi are trademarks or registered trademarks of VMware, Inc.
Mellanox and ConnectX are reigstered trademarks of Mellanox Technologies.
All other registered trademarks or trademarks belong to their respective companies.
Copyright 2014 Mirantis, Inc. All rights reserved.

1
release-notes.rst
View File

@@ -5,7 +5,6 @@
=============
Release Notes
=============
.. contents:: :local:
:depth: 1