Imported Release Notes
This commit is contained in:
parent
861cbf8154
commit
f78e212cd4
|
@ -1,90 +1,333 @@
|
||||||
.. index:: Release Notes; v3.1-grizzly
|
.. index:: Release Notes: Fuel 3.1
|
||||||
|
|
||||||
.. _RelNotes_3.1:
|
.. _RelNotes_3.1:
|
||||||
|
|
||||||
v3.1-grizzly
|
|
||||||
============
|
|
||||||
|
|
||||||
New Features in Fuel 3.1
|
New Features in Fuel 3.1
|
||||||
-------------------------
|
========================
|
||||||
|
|
||||||
.. contents :local:
|
.. contents:: :local:
|
||||||
|
:depth: 1
|
||||||
|
|
||||||
* Combined Fuel library and Fuel Web products
|
Fuel 3.1 with Integrated Graphical and Command Line controls
|
||||||
* Option to deploy Red Hat Enterprise Linux® OpenStack® Platform
|
------------------------------------------------------------
|
||||||
* Mirantis OpenStack Health Check
|
|
||||||
* Ability to deploy properly in networks that are not utilizing VLAN tagging
|
|
||||||
* Integrated ability to connect to remote nodes via SSH
|
|
||||||
* Improved High Availability resiliency
|
|
||||||
* Horizon password entry can be hidden
|
|
||||||
|
|
||||||
Fuel 3.1 with Integrated Graphical and Command Line Controls
|
In earlier releases, Fuel was distributed as two packages – ``Fuel Web`` for
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
graphical workflow, and ``Fuel Library`` for command-line based manipulation.
|
||||||
|
|
||||||
In earlier releases, Fuel was distributed as two packages – “Fuel Web” for
|
|
||||||
graphical workflow, and “Fuel Library” for command-line based manipulation.
|
|
||||||
Starting with this 3.1 release, we’ve integrated these two capabilities into
|
Starting with this 3.1 release, we’ve integrated these two capabilities into
|
||||||
a single offering, referred to simply as Fuel. If you used Fuel Web, you’ll
|
a single offering, referred to simply as Fuel. If you used Fuel Web, you’ll
|
||||||
see that capability along with its latest improvements to that capability in
|
see that capability along with its latest improvements to that capability in
|
||||||
the the Fuel User Interface (UI), providing a streamlined, graphical console
|
the the Fuel User Interface (UI), providing a streamlined, graphical console
|
||||||
that enables a point-and-click experience for the most commonly deployed
|
that enables a point-and-click experience for the most commonly deployed
|
||||||
configurations. Advanced users with more complex environmental needs can
|
configurations. Advanced users with more complex environmental needs can
|
||||||
still get command-line access to the underlying deployment engine (aka “Fuel
|
still get command-line access to the underlying deployment engine (aka ``Fuel
|
||||||
Library”).
|
Library``).
|
||||||
|
|
||||||
Option to Deploy Red Hat Enterprise Linux® OpenStack® Platform
|
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
Mirantis Fuel now includes the ability to deploy the Red Hat Enterprise
|
Option to deploy Red Hat Enterprise Linux® OpenStack® Platform
|
||||||
Linux OpenStack Platform (a solution that includes both Red Hat Enterprise
|
--------------------------------------------------------------
|
||||||
Linux and the Red Hat OpenStack distribution). During the definition of a
|
|
||||||
new environment, the user will be presented with the option of either
|
Mirantis Fuel now includes the ability to deploy the Red Hat Enterprise Linux®
|
||||||
installing the Mirantis provided OpenStack distribution onto CentOS powered
|
OpenStack® Platform (a solution that includes both Red Hat Enterprise Linux®
|
||||||
nodes or installing the Red Hat provided OpenStack distribution onto Red Hat
|
and the Red Hat OpenStack® distribution). During the definition of a new
|
||||||
Enterprise Linux powered nodes.
|
environment, the user will be presented with the option of either installing
|
||||||
|
the Mirantis-provided OpenStack distribution onto CentOS-powered nodes or
|
||||||
|
installing the Red Hat provided OpenStack distribution onto Red Hat Enterprise
|
||||||
|
Linux® powered nodes.
|
||||||
|
|
||||||
.. note:: A Red Hat subscription is required to download and deploy Red Hat
|
.. note:: A Red Hat subscription is required to download and deploy Red Hat
|
||||||
Enterprise Linux OpenStack Platform.
|
Enterprise Linux® OpenStack® Platform.
|
||||||
|
|
||||||
Mirantis OpenStack Health Check
|
Mirantis OpenStack Health Check
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
-------------------------------
|
||||||
|
|
||||||
New in this release is the Mirantis OpenStack Health Check which can be
|
New in this release is the Mirantis OpenStack Health Check which can be
|
||||||
accessed through a tab in the Fuel UI. The OpenStack HealthCheck is a
|
accessed through a tab in the Fuel UI. The OpenStack HealthCheck is a battery
|
||||||
battery of tests that can be run against an OpenStack deployment to ensure
|
of tests that can be run against an OpenStack deployment to ensure that it is
|
||||||
that it is installed properly and operating correctly. The suite of tests
|
installed properly and operating correctly. The suite of tests exercise not
|
||||||
exercise not only the core components within OpenStack, but also the added
|
only the core components within OpenStack, but also the added packages included
|
||||||
packages included in the Mirantis OpenStack distribution. Tests can be run
|
in the Mirantis OpenStack distribution. Tests can be run individually or in
|
||||||
individually or in groups. A full list of available tests can be found in
|
groups. A full list of available tests can be found in the documentation.
|
||||||
the documentation.
|
|
||||||
|
|
||||||
Ability to deploy properly in networks that are not utilizing VLAN tagging
|
Ability to deploy properly in networks that are not utilizing VLAN tagging
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
--------------------------------------------------------------------------
|
||||||
|
|
||||||
In some environments, it may not be possible or desired to utilize VLANs to
|
In some environments, it may not be possible or desired to utilize VLANs to
|
||||||
segregate network traffic. In these networks, Fuel can now be configured
|
segregate network traffic. In these networks, Fuel can now be configured
|
||||||
through the Fuel UI to disable the need for VLAN tagging. This
|
through the Fuel UI to disable the need for VLAN tagging. This configuration
|
||||||
configuration option is available through the Network Settings tab.
|
option is available through the Network Settings tab.
|
||||||
|
|
||||||
Integrated ability to connect to remote nodes via SSH
|
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
The ability to connect to a remote node via SSH is now available from the
|
|
||||||
machine details screen. SSH key management is automatically handled by
|
|
||||||
Fuel, so the user need only click on she SSH Console button to connect.
|
|
||||||
|
|
||||||
Improved High Availability resiliency
|
Improved High Availability resiliency
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
-------------------------------------
|
||||||
|
|
||||||
To improve the resiliency of the Mirantis OpenStack High Availability
|
To improve the resiliency of the Mirantis OpenStack High Availability reference
|
||||||
reference architecture, Fuel now deploys all HA services under Pacemaker, a
|
architecture, Fuel now deploys all HA services under Pacemaker, a scalable
|
||||||
scalable cluster resource manager developed by ClusterLabs. Additional
|
cluster resource manager developed by Clusterlabs.
|
||||||
options in the Fuel Library have also been added to Corosync to enable more
|
|
||||||
granular tuning.
|
|
||||||
|
|
||||||
Horizon password entry can now be hidden
|
Horizon password entry can be hidden
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
------------------------------------
|
||||||
|
|
||||||
In the OpenStack settings tab, the input of the password used for Horizon
|
In the OpenStack settings tab, the input of the password used for Horizon
|
||||||
access can now be hidden by clicking on the "Eye" icon to the left of the
|
access can now be hidden by clicking on the eye icon to the left of the field.
|
||||||
field. The icon is a simple toggle that turns the feature on and off.
|
This icon acts as a toggle between hidden and visible input modes.
|
||||||
|
|
||||||
|
Resolved Issues in Fuel 3.1
|
||||||
|
===========================
|
||||||
|
|
||||||
|
Disk Configuration now displays proper size and validates input
|
||||||
|
---------------------------------------------------------------
|
||||||
|
|
||||||
|
Previously, the `Total Space` displayed in the `Disk Configuration` screen was
|
||||||
|
slightly larger than what was actually available. This has now been corrected
|
||||||
|
to be accurate. In addition, user input validation has been improved when
|
||||||
|
making changes to ensure that space is not incorrectly allocated. And finally,
|
||||||
|
the unit of measure has been changed to MB from GB in the `Disk Configuration`
|
||||||
|
screen.
|
||||||
|
|
||||||
|
Improved behavior for allocating space
|
||||||
|
--------------------------------------
|
||||||
|
|
||||||
|
In Fuel 3.0.x, users were forced to manually zero out fields in the
|
||||||
|
`Disk Configuration` screen if the total allocated space exceeded the total
|
||||||
|
disk size before the "USE ALL UNALLOCATED SPACE" option could be utilized.
|
||||||
|
Now you can now enter a value above the maximum available for a volume group
|
||||||
|
(as long as it does not exceed total disk size), select "USE ALL UNALLOCATED
|
||||||
|
SPACE" for a second volume group and that group will be assigned the available
|
||||||
|
space up to the maximum disk size. In addition, the current allocated sizes
|
||||||
|
are reflected graphically in the bars above the volume group.
|
||||||
|
|
||||||
|
Eliminated the need to specify a bootable disk
|
||||||
|
----------------------------------------------
|
||||||
|
|
||||||
|
Previously, the `Disk Configuration` screen had a special `Make bootable`
|
||||||
|
option. This release of Fuel makes the option unnecessary because Fuel now has
|
||||||
|
a Master Boot Record (MBR) and boot partition installed on all hard drives.
|
||||||
|
BIOS can now be configured to load from any disk and the node will boot the
|
||||||
|
operating system. Because of this, the `Make bootable` option has been removed.
|
||||||
|
|
||||||
|
Floating IP allocation speed increased
|
||||||
|
--------------------------------------
|
||||||
|
|
||||||
|
In Fuel 3.0.x, the step of floating IP allocation was taking significant time.
|
||||||
|
During cluster provisioning, it was taking up to 8 minutes for creating the
|
||||||
|
pool of 250 floating IP addresses. This has now been reduced down to seconds
|
||||||
|
instead of minutes.
|
||||||
|
|
||||||
|
Ability to map logical networks to physical interfaces
|
||||||
|
------------------------------------------------------
|
||||||
|
|
||||||
|
With the introduction of the ability to deploy properly in networks that are
|
||||||
|
not utilizing VLAN tagging, it is now possible to map logical OpenStack
|
||||||
|
networks to physical interfaces without using VLANs.
|
||||||
|
|
||||||
|
Separate Logical Volume Manager (LVM) now used for Glance storage
|
||||||
|
-----------------------------------------------------------------
|
||||||
|
|
||||||
|
Glance storage was previously configured to use a root partition on a
|
||||||
|
controller node. Because of this, in HA mode, Swift was configured to use
|
||||||
|
only 5 Gb of storage. A user was unable to load large images into Glance in
|
||||||
|
HA mode and could receive an out of space error message if a small root
|
||||||
|
partition were used. This situation has been corrected by creating special LVM
|
||||||
|
for Glance storage. You can modify the size of this partition in the `Disk Configuration` screen.
|
||||||
|
|
||||||
|
Memory leaks in nailgun service
|
||||||
|
-------------------------------
|
||||||
|
|
||||||
|
Nailgun is the RESTful API backend service that is used in Fuel. In 3.0.1 an
|
||||||
|
increase in memory consumption could occur over time. This has now been fixed.
|
||||||
|
|
||||||
|
Network Verification failures
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
In some cases, the "Verify Networks" option in the `Network configuration` tab
|
||||||
|
reported a connectivity problem, however manual checks confirmed that the
|
||||||
|
connection was fine. The problem was identified as a loss of packets when a
|
||||||
|
particular Python library was used. That library has been replaced and
|
||||||
|
verification now functions properly.
|
||||||
|
|
||||||
|
Installing Fuel Master node onto a system with em# network interfaces
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
|
||||||
|
In Fuel 3.0.1 a fix was included to recognize network interfaces that start
|
||||||
|
with `em` (meaning "embedded") instead of `eth`. However the fix only applied
|
||||||
|
to the Slave nodes used to deploy OpenStack components. The Fuel Master node
|
||||||
|
was still affected. This has now been corrected and Fuel can be deployed on
|
||||||
|
machines where the operating systems uses the prefix of `em` instead of `eth`.
|
||||||
|
|
||||||
|
Provisioning failure on large hard drives
|
||||||
|
-----------------------------------------
|
||||||
|
|
||||||
|
In previous releases, when ext4 was used as a file system for a partition,
|
||||||
|
provisioning would fail for for large volumes (larger than 16 Tb) in some
|
||||||
|
cases. Ext4 has been replaced by the xfs file system which works well on large
|
||||||
|
volumes.
|
||||||
|
|
||||||
|
Access to OpenStack API or VNC console in Horizon when running in VirtualBox
|
||||||
|
----------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Previously it was impossible to access the OpenStack API or VNC console in
|
||||||
|
Horizon when running the OpenStack environment created in VirtualBox by the
|
||||||
|
Mirantis demo VirtualBox. This was caused by an inability to create a route
|
||||||
|
to the OpenStack public network from a host system due to a lack of VLAN tags.
|
||||||
|
With the introduction of the ability to deploy properly in networks that are
|
||||||
|
not utilizing VLAN tagging, it is now possible to create the route.
|
||||||
|
Information on how to create this route is documented in the user guide.
|
||||||
|
|
||||||
|
Other resolved issues
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
If CPU speed could not be determined through an operating system level query on
|
||||||
|
a slave node, that node would not register properly with the Fuel Master node.
|
||||||
|
This issue has been corrected to register the node even if some information
|
||||||
|
about the node is unavailable.
|
||||||
|
|
||||||
|
Known Issues in Fuel 3.1
|
||||||
|
========================
|
||||||
|
|
||||||
|
Support for OpenStack Grizzly
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
The following improvements in Grizzly are not currently supported directly by
|
||||||
|
Fuel:
|
||||||
|
- Nova Compute
|
||||||
|
- Cells
|
||||||
|
- Availability zones
|
||||||
|
- Host aggregates
|
||||||
|
- Neutron (formerly Quantum)
|
||||||
|
- LBaaS (Load Balancer as a Service)
|
||||||
|
- Multiple L3 and DHCP agents per cloud
|
||||||
|
- Keystone
|
||||||
|
- Multi-factor authentication
|
||||||
|
- PKI authentication
|
||||||
|
- Swift
|
||||||
|
- Regions
|
||||||
|
- Adjustable replica count
|
||||||
|
- Cross-project ACLs
|
||||||
|
- Cinder
|
||||||
|
- Support for FCoE
|
||||||
|
- Support for LIO as an iSCSI backend
|
||||||
|
- Support for multiple backends on the same manager
|
||||||
|
- Ceilometer
|
||||||
|
- Heat
|
||||||
|
|
||||||
|
It is expected that these capabilities will be supported in a future release
|
||||||
|
of Fuel.
|
||||||
|
|
||||||
|
In addition, support for High Availability of Neutron (Quantum) on Red Hat
|
||||||
|
Enterprise Linux® (RHEL) is not available due to a limitation within the
|
||||||
|
Red Hat kernel. It is expected that this issue will be addressed by a patch to
|
||||||
|
RHEL in late 2013.
|
||||||
|
|
||||||
|
Ability to deploy Swift and Neutron (Quantum) is limited to Fuel CLI
|
||||||
|
--------------------------------------------------------------------
|
||||||
|
|
||||||
|
At this time, customers wishing to deploy Swift or Neutron (Quantum) will need
|
||||||
|
to do so through the Fuel Library. An option to deploy these components as
|
||||||
|
standalone nodes is not currently present in the Fuel UI. It is expect that
|
||||||
|
a near future release will enable this capability.
|
||||||
|
|
||||||
|
Ability to add new nodes without redeployment
|
||||||
|
---------------------------------------------
|
||||||
|
|
||||||
|
It’s possible to add new compute and Cinder nodes to an existing OpenStack
|
||||||
|
environment. However, this capability can not be used yet to deploy additional
|
||||||
|
controller nodes in HA mode.
|
||||||
|
|
||||||
|
Ability to deploy properly in networks that are not utilizing VLAN tagging
|
||||||
|
--------------------------------------------------------------------------
|
||||||
|
|
||||||
|
While included in Fuel and fully supported, network environments can be complex
|
||||||
|
and Mirantis has not exhaustively identified all of the configurations where
|
||||||
|
this feature works properly. Fuel does not prevent the user from creating an
|
||||||
|
environment that may not work properly, although the `Verify Networks` function
|
||||||
|
will confirm necessary connectivity. As Mirantis discovers environments where a
|
||||||
|
lack of VLAN tagging causes issue, they will be further documented.
|
||||||
|
Currently, a known limitation is that untagged networks should not be mapped to
|
||||||
|
the physical network interface that is used for PXE provisioning. Another known
|
||||||
|
situation occurs when the user separates the public and floating networks onto
|
||||||
|
different physical interfaces without VLAN tagging, which will cause deployment
|
||||||
|
to fail.
|
||||||
|
|
||||||
|
Time synchronization failures in a VirtualBox environment
|
||||||
|
---------------------------------------------------------
|
||||||
|
|
||||||
|
If the ntpd service fails on the Fuel master node, desynchronization of nodes
|
||||||
|
in the environment will occur. OpenStack identifies services as broken if the
|
||||||
|
time synchronization is broken, which will cause the "Services list
|
||||||
|
availability" test in the Mirantis OpenStack HealthCheck to fail. In addition,
|
||||||
|
instances may fail to boot. This issue appears to be limited to VirtualBox
|
||||||
|
environments as it could not be replicated on KVM and physical hardware
|
||||||
|
deployments.
|
||||||
|
|
||||||
|
If a controller’s root partition runs out of space, the controller fails to operate
|
||||||
|
-----------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Logging is configured to send most of messages over rsyslog, and disk space
|
||||||
|
consuming services use their own logical volumes (such as Cinder, Compute).
|
||||||
|
However, if processes write to the root partition and the root partition runs
|
||||||
|
out of disk space, the controller will fail.
|
||||||
|
|
||||||
|
The "Create instance volume" test in the Mirantis OpenStack Healthcheck tab has a wrong result for attachment volumes
|
||||||
|
---------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
The "Create instance volume" test is designed to confirm that a volume can be
|
||||||
|
created. However, even if OpenStack fails to attach the volume to the VM, the
|
||||||
|
test still passes.
|
||||||
|
|
||||||
|
Other Limitations:
|
||||||
|
------------------
|
||||||
|
|
||||||
|
- When using the Fuel UI, IP addresses for Slave nodes (but not the Master node)
|
||||||
|
are assigned via DHCP during PXE booting from the master node. Because of
|
||||||
|
this, even after installation, the Fuel Master node must remain available
|
||||||
|
and continue to act as a DHCP server.
|
||||||
|
|
||||||
|
- When using the Fuel UI, the floating VLAN and public networks must use the
|
||||||
|
same L2 network. In the UI, these two networks are locked together, and can
|
||||||
|
only run via the same physical interface on the server.
|
||||||
|
|
||||||
|
- Deployments done through the Fuel UI creates all networks on all servers,
|
||||||
|
even if they are not required by a specific role (e.g. A Cinder node will
|
||||||
|
have VLANs created and addresses obtained from the public network).
|
||||||
|
|
||||||
|
- Some of OpenStack services listen on all interfaces, which may be detected
|
||||||
|
and reported by security audits or scans. Please discuss this issue with
|
||||||
|
your security administrator if it is of concern in your organization.
|
||||||
|
|
||||||
|
- The provided scripts that enable Fuel to be automatically installed on
|
||||||
|
VirtualBox will create separated host interfaces. If a user associates
|
||||||
|
logical networks to different physical interfaces on different nodes, it
|
||||||
|
will lead to network connectivity issues between OpenStack components.
|
||||||
|
Please check to see if this has happened prior to deployment by clicking on
|
||||||
|
the `Verify Networks` button on the networking tab.
|
||||||
|
|
||||||
|
- The networks tab was redesigned to allow the user to provide IP ranges
|
||||||
|
instead of CIDRs, however not all user input is properly verified. Entering
|
||||||
|
a wrong wrong value may cause failures in deployment.
|
||||||
|
|
||||||
|
- Fuel UI may not reflect changes in NICs or disks after initial discovery,
|
||||||
|
and it can lead to failure in deployment. In other words, if user powers on
|
||||||
|
the node, it gets discovered, and then some disks are replaced or network
|
||||||
|
cards added or removed, rediscovering of changed hardware may not be done
|
||||||
|
correctly. For example, the `Total Space` displayed in the `Disk
|
||||||
|
Configuration` screen may be different than the actual size of the disk.
|
||||||
|
|
||||||
|
- Neutron (Quantum) Metadata API agents in High Availability mode are only
|
||||||
|
supported for Compact and Full scenarios if network namespaces (netns) is
|
||||||
|
not used.
|
||||||
|
|
||||||
|
- The Neutron (Quantum) namespace metadata proxy is not supported unless netns
|
||||||
|
is used.
|
||||||
|
|
||||||
|
- Neutron (Quantum) multi-node balancing conflicts with pacemaker, so the two
|
||||||
|
should not be used together in the same environment.
|
||||||
|
|
||||||
|
- When deploying Neutron (Quantum) with the Fuel Library and when virtual
|
||||||
|
machines need to have access to internet and/or external networks you need
|
||||||
|
to set the floating network prefix and public_address so that they do not
|
||||||
|
intersect with the network external interface to which it belongs. This is
|
||||||
|
due to specifics of how Neutron(Quantum) sets Network Address Translation
|
||||||
|
(NAT) rules and a lack of namespaces support in CentOS 6.4.
|
||||||
|
|
||||||
|
- In environments with a large number of tenant networks, e.g. over 300,
|
||||||
|
network verification may stop responding. In these cases, the networks
|
||||||
|
themselves are unaffected and it is only the test that ceases to function
|
||||||
|
correctly.
|
||||||
|
|
Loading…
Reference in New Issue