Openstack services rely heavily on JSON for their interactions. Red Hat Enterprise Linux 6.5 still uses Python 2.6, which does not provide the 'json' module with major speed optimisations that can be found in Python 2.7+ and recent versions of 'simplejson' module. As a result, JSON operations took a lot of processing time and slowed down the whole service. 

With this update, OpenStack Networking (neutron) now uses the 'simplejson' library on Red Hat Enterprise Linux 6.5 to get access to JSON speed optimisations. The performance of JSON operations and the service as a whole is now significantly increased.

In Red Hat Enterprise Linux OpenStack Platform 5.0, OpenStack Networking notifies Compute about port status changes, and to do so it requires Identity credentials in the file neutron.conf.

Prior to this update, an instance's network ports were not created if the Compute (nova) API configuration was missing from neutron.conf.

This update addresses this issue by disabling 'nova-neutron' notifications by default in Red Hat Enterprise Linux OpenStack Platform 5.0.

As a result, instances will boot without dependency on the notification feature. Enabling Compute's notifications is recommended in order to mitigate race behavior issues. 

This is managed in the following neutron.conf parameters:
notify_nova_port_status_changes=true
notify_nova_on_port_data_changes=true
nova_url=http://[nova_api]:[nova_api_port]/v2
nova_admin_username=[admin_username]
nova_admin_password=[admin_password]
nova_admin_tenant_id=[admin_tenant_id]
nova_admin_auth_url=http://[keystone_service_ip]:[keystone_port]/v2.0

With this workaround in place, OpenStack Networking will correctly notify Compute of port changes.

An argument that would make the agent read the /etc/neutron/fwaas_driver.ini configuration file was missing in the previous release's neutron-vpn-agent service files. As a result, neutron-vpn-agent didn't apply configuration from the configuration file. At the same time, the L3 agent that is replaced by neutron-vpn-agent did read the file. This introduced inconsistency in how different L3 agents were configured.

The service files have been updated so that the configuration file is now read on agent startup, and configuration from the file is applied for neutron-vpn-agent.

Previously, the OpenStack Networking (neutron) package did not depend on the iproute2 version with network-namespace support. This meant that OpenStack Networking was installed, but failed to operate with network namespaces.

An explicit dependency has been added to either install or update iproute2 to a  version with network-namespace support. OpenStack Networking can now operate with network namespaces.

When deleting a port, under some circumstances a deadlock occurred when two inter-dependent threads attempted to access the same database row.

This resulted in the database library returning an OperationalError after a delay of approximately 50 seconds.

This has been fixed by moving notifications which could cause this type of conflict to outside the database transaction.

Now, these types deadlock do not occur.

With this release, openstack-neutron is now rebased to upstream version 2014.1.1. This rebase applies the following updates:

* OVS agent now handles 'openvswitch service restart' correctly.
* Querying for security groups is optimized.
* The router-list command performance is optimized, reducing the average time of the operation for 10-30%.
* Multiple updates to VMware NSX, Cisco N1KV, and other plugins.

The RHEL-OSP installer can now install the Nexus 1000v plugin on the OpenStack Networking (neutron) controller and the Nexus 1000v switch on compute and networking nodes.

Previously, to use Nexus 1000v, the Cisco Nexus 1000v plugin needed to be separately installed on the controller. This enhancement adds the support to configure plugin and related variables using the RHEL-OSP installer, which means that you can now install and configure the Nexus 1000v plugin and switch in the Red Hat Enterprise Linux OpenStack Platform environment.

Prior to this update, the Identity Service (keystone) did not automatically flush tokens. Instead, the expectation was that token flushing would be manually performed using the 'keystone-manage' command. If this action was not taken, the Identity Service would build up a large number of tokens, which used up space and potentially slowed performance.
With this update, a cron job is setup to flush tokens, and consequently, they do not accumulate and potentially affect Identity Service performance.

Previously, a misplaced puppet parameter would occur when selecting Qpid as the AMQP provider. As a result, the Qpid service would not install, and OpenStack Networking would fail to start.
With this update, the amqp_provider parameter is correctly passed through. Consequently, the Qpid server is installed on the controller, and OpenStack Networking services start as expected.

The RHEL-OSP installer can now deploy Ceph RADOS Block Devices (RBD) as a backend for the Image or Block Storage services. With this enhancement, Ceph configuration options can be specified using the installer (OpenStack configuration files on controller and compute nodes can use Ceph for the Image or Block Storage services).

With this enhancement, RHEL-OSP installer deployments create the Ceph key rings needed for Image Service images or Block Storage volumes (key rings no longer need to be manually configured).  RHEL-OSP installer deployments now ensure that the /etc/ceph/ceph.client.volumes.keyring and /etc/ceph/ceph.client.images.keyring files are consistent across HA controllers, compute nodes, and Ceph storage nodes.

To support non-default values for both PoC and production deployments, users can now configure the OSD (object storage daemon) pool default size or the OSD journal size. 
This allows PoC deployments with just one OSD.

When configuring Block Storage with multiple storage backends, users can now use volume types to specify which backend should be used when creating a volume. To use volume types, the create_volume_types parameter must set to 'true'.

Adding the Nexus 1000v support in the OpenStack HA installation via the OpenStack-Installer installed Nexus 1000v plugin on OpenStack Networking Controller and Nexus 1000v switch on the Compute and HA controller.

This update adds support to install and configure plugin and switch related variables via RHEL-OSP Installer. This enables to install and configure Nexus 100v plugin and switch in the OpenStack HA environment.

The N1KV VSM puppet module (Virtual Supervisor Module) has been integrated into the RHEL-OSP installer. With this enhancement, it is now possible to configure N1KV using the the RHEL-OSP installer.

The N1KV VEM puppet module (Virtual Ethernet Module) has been integrated into the RHEL-OSP installer. With this enhancement, it is now possible to configure N1KV using the the RHEL-OSP installer.

This enhancement allows Red Hat Enterprise Linux OpenStack Platform installer to deploy controllers on heterogeneous hardware. This was added to support environments without consistent hardware.
Consequently, users can now configure the NICs on each host individually, or on a group of hosts together if they have the same NIC layout. In addition, the user interface enforces that the hosts can only be configured if the NIC layouts match.

This enhancement includes sos components by default in deployed systems. This is intended to ease support and debugging activities.
As a result, the log collector tooling will now get Red Hat Enterprise Linux OpenStack Platform specific results.

Previously, GUID partition table (GPT) partitions greater than 2 TB required a BIOS boot partition which was not created. This meant that installing to disks larger that 2 TB would fail. With this update, if the disk is larger than 2TB, a BIOS boot partition is created, and nodes with disks larger than 2 TB will boot correctly.

A provisioning snippet in the Red Hat Enterprise Linux OpenStack Installer included a step to restart the network during a kickstart. This made it possible for an interface to be unavailable while it was still needed.

This update removes the step, thereby ensuring that all networkign interfaces are available during the kickstart.

In VLAN environments, the default gateway was not set properly. As a result, nodes would not have any default gateway configured resulting in networking issues. 

With this update, the kickstart was improved to handle the VLAN use case. As a result, environments with VLAN will get the correct default gateway.

During NIC assignment, the installer builds a list of available subnets by querying all the host's NICs for subnets that are currently unassigned. However, the query also incorrectly considered VIP interfaces as 'assigned', thereby filtering them out from the list (and, consequently, making them unavailable for assignment).

With this release, the query no longer filters out VIP interfaces.

When assigning a subnet to a NIC, the system would remove that subnet from all other NICs including the hidden VIP interfaces. As a result, assigning the Public API, Management and Admin API subnets to any non-provisioning subnet would wipe out the VIP addresses.

With this update, when assigning the subnet to a NIC, the subnet is removed from all other interfaces except the VIP interfaces and the VIP addresses remain available on the interfaces.

Previously, when deploying an High Availability (HA) environment, VIP interfaces were created with pre-defined MAC addresses. As a result, when a second HA environment was defined, the MAC addresses already existed causing an error.

With this update, the pre-defined MAC addresses are generated differently to prevent conflicts. As a result, multiple HA environments are now available.

With this update, a new feature adds the ability to configure the Cisco Nexus ML2 mechanism with the following additional fields: switch name, ip address, username, password, and ssh port.

Users can now configure network bonding of target hosts through the Red Hat Enterprise Linux OpenStack Platform Installer user interface.

Prior to this update, deployments would fail if tenant networks, external networks, and the provisioning network were configured to operate off the same subnet.
This update addresses the issue by enforcing the separation of these networks. As a result, users will be alerted if attempting to assign any of these networks to the same subnet.

Previously, it was possible to directly assign hosts to the deployment host groups created by the installer. This would cause problems when attempting to provision a Red Hat Enterprise Linux OpenStack Platform environment using hosts manually assigned to these host groups. With this update, deployment host groups are no longer visible in the user interface for the installer or the corresponding API, making it impossible to directly assign hosts to these host groups.

Prior to this update, the ceph.conf file was not automatically created on Ceph nodes.
Red Hat Enterprise Linux OpenStack Platform installer has been updated to correctly configure ceph.conf on the storage nodes.
Consequently, users are no longer required to manually configure the ceph.conf file.

Previously, the 'OSD Pool' default size was not visible in the Advanced Configuration of a deployment. As a result, the default pool size could not be set for Ceph.
With this update, the Ceph default pool size has been added to the Advanced Configuration screen and is available for modification.

Prior to this update, method used to override Red Hat Enterprise Linux OpenStack Platform installer views behaved differently in development and production environments.
As a result, an additional javascript file which enhanced the fencing tab on the hosts#edit form was missing in the production environment.
This update addresses this issue by changing the override rule. As a result, the javascript file is correctly included in the installer view.

The Red Hat Enterprise Linux OpenStack Platform Installer will now validate the configured range of fixed IPs for tenant networks before deploying OpenStack. If a user attempts to use ranges that would result in an error, the installer will now notify the user before proceeding with the deployment.

After a successful deployment, clicking the 'Access all details' button will now also display IP addresses on the Management, Public API, and Admin API networks.

This update fixes the indentation of the 'All details' screen (which becomes available after a successful deployment). With this fix, VIP names and their corresponding values no longer overlap.

Networks with no DHCP servers are no longer required to have a gateway. This requirement was enforced in previous releases, but has since been removed.

The API of the library used to override Foreman views have changed. The feature in Staypuft did not support both API versions. As a result, installations using the old version of the library did not display the network traffic type parameter.

With this update, Staypuft handles both versions of the API and the network traffic type is displayed regardless of the version of the library.

The 'multiple_backends' parameter for Block Storage on High Availability (HA) controller host group was set to 'false'. As a result, when a user checked for more than one backend in the installer wizard, only single backend configuration would get deployed.

With this update, the installer sets the 'multiple_backends' parameter to 'true' when more than one backend is checked in the configuration wizard. As a result, multiple Block Storage backends can be deployed with HA controller when using the installer wizard.

Sharing the 'Tenant' network type with other network types is supported on Neutron VXLAN and GRE. This update removes a UI-level validation step that incorrectly prevented the 'Tenant' network type from being shared at all.

Note, however, that with this update users can now attempt to incorrectly share the 'Tenant' network types on Nova networking or Neutron VLAN/Flat. Doing so is not supported.

Virtual serial console access has been added to OpenStack instances. A new package and service have been added to support this feature. The cloud administrator must install the openstack-nova-serialproxy package and start the openstack-nova-serialproxy service.

Previously, the Compute service incorrectly handled exceptions when migrating instances between different OpenStack versions. This meant that an instance migrated  from an older version would appear to hang forever in the migrating state.  With this update, the exception for a 'forbidden version' is now handled correctly, and migrations are properly disallowed.

Previously, the evacuate function did not consider RBD storage as shared and the evacuate procedure failed with RBD-backed instances. With this fix, RBD storage is now marked as shared, and the evacuate function handles the shared storage attribute and therefore now operates on RBD.

When Compute is configured to only set up VNC/SPICE servers on a specific network interface, the host's IP address is recorded in the libvirt guest XML. Previously, if the guest was migrated to a different host, the IP address of the source host remained in the guest XML and the guest failed to launch on the target host because the IP address was incorrect.

With this fix, the libvirt guest XML is now updated during migration to refer to the IP address of the target host. Migration can be performed for guests, even when the VNC/SPICE servers are configured to only bind to the IP address of a specific network interface.

The Compute service has been rebased to version: 2014.1.4

Important fixes and enhancements include:

* Security fixes. The websocket proxy of the Compute service console now verify the origin HTTP header to block cross-site attacks. CVE 2013-2255: Local CAs are now verified by default. By default, SSL certificate verifications are disabled. A new attestation_insecure_ssl option was added to enable verification by setting the option to False.

* Block device mapping retries are now configurable, with two new configuration
  options: block_device_allocate_retries (the number of block device
    mapping retries) and block_device_allocate_retries_interval (the time interval
    between consecutive retries).

* Two new configuration options have been added to control keep-alive and client connection
  timeout: wsgi_keep_alive option (default=True), client_socket_timeout option (default=0).

* Fixed issue with the Compute service not doing Image service server certificate validation.

* Fixed instance root-disk size restriction with QCOW2 images.

* Fixed the initialization sequence of nova-compute service to handle binding   failures of virtual interface. Failures are now logged when nova-compute starts. Before, nova-compute failed to start. 

* Set a check for minimum disk and RAM when booting from a volume. Previously,
  the minimum attributes were ignored.

* Fixed a multipath iSCSI sessions issue when connecting or disconnecting a
  volume.

* Fixed a race condition in the creation of security groups.

* Fixed the resource tracking and now updates the number of instance during delete
  instance.

* Fixed a Compute service evacuate issue with RDB.

* Fixed nova-compute start issue after evacuate.

* Fixed denial-of-service issue in instance-list IP filter.

* Now retry on closing of LUKS-encrypted volume in case device is busy.

* Now share OpenStack Networking admin authentication tokens resizing.

* Fixed a bug in cell management which prevented the start of the nova-cells service.

* Fixed instance cross-AZ check when attaching volumes.

* Now ignore errors when deleting non-existing VIFs so that instances are not left in the state of "Error(deleting)".

The previous setting of 'iscsi_use_multipath=true' in nova.conf meant that detaching a multipath iSCSI volume killed all iSCSI volumes visible from the Compute service's compute node.

There are two types of iSCSI multipath devices. One which shares the same IQN between multiple portals, and the other which uses different IQNs on different portals. With this update, connect_volume() now identifies the type by checking iscsiadm (the output is the IQN is used by multiple portals), and then connecting to the correct targets using connect_to_iscsi_portal().

A flaw was found in the OpenStack Compute (nova) VMWare driver, which could allow an authenticated user to delete an instance while it was in the resize state, causing the instance to remain on the back end. A malicious user could use this flaw to cause a denial of service by exhausting all available resources on the system.

A denial of service flaw was found in the way OpenStack Compute (nova) looked up VM instances based on an IP address filter. An attacker with sufficient privileges on an OpenStack installation with a large amount of VMs could use this flaw to cause the main nova process to block for an extended amount of time.

It was discovered that the OpenStack Compute (nova) console websocket did not correctly verify the origin header. An attacker could use this flaw to conduct a cross-site websocket hijack attack. Note that only Compute setups with VNC or SPICE enabled were affected by this flaw.