6.2. RHEA-2015:1549 — Red Hat Enterprise Linux OpenStack Platform director Release

A missing dependency on PyYAML from diskimage-builder caused image builds to fail. This fix adds the dependency. Now image builds are successful.

A missing dependency on PyYAML from diskimage-builder caused image builds to fail. This fix adds the dependency. Now image builds are successful.

The deploy-baremetal-overcloudrc file is no longer used in the deployment process. Deployments now use the "openstack overcloud deploy" command and the associated command line arguments.

The deploy-baremetal-overcloudrc file is no longer used in the deployment process. Deployments now use the "openstack overcloud deploy" command and the associated command line arguments.

A duplicate line in the RabbitMQ configuration caused the Undercloud installation to fail. This fix removes the duplicate line and the Undercloud installation is now successful.

A duplicate line in the RabbitMQ configuration caused the Undercloud installation to fail. This fix removes the duplicate line and the Undercloud installation is now successful.

The openstack-ironic-discoverd service would check for openstack-ironic-api's presence on start up. Due to start up ordering, openstack-ironic-discoverd failed to detect openstack-ironic-api on reboot. This fix removes the need to check for openstack-ironic-api's presence from openstack-ironic-discoverd start up code. All services start successfully now on reboot.

The openstack-ironic-discoverd service would check for openstack-ironic-api's presence on start up. Due to start up ordering, openstack-ironic-discoverd failed to detect openstack-ironic-api on reboot. This fix removes the need to check for openstack-ironic-api's presence from openstack-ironic-discoverd start up code. All services start successfully now on reboot.

A transient error in the Ironic/Heat systemd service file incorrectly redirected the logs. This fix corrects the Ironic/Heat service file and the logs redirect to the correct file.

A transient error in the Ironic/Heat systemd service file incorrectly redirected the logs. This fix corrects the Ironic/Heat service file and the logs redirect to the correct file.

The edeploy plugin for ironic-discoverd collected too much information to store in a SQL blob. Discovery failed when edeploy data was posted to Ironic because the column would overflow. This fix changes the edeploy plugin to stores data in a Swift object on the Undercloud. Discovery no longer fails when using the edeploy plugin.

The edeploy plugin for ironic-discoverd collected too much information to store in a SQL blob. Discovery failed when edeploy data was posted to Ironic because the column would overflow. This fix changes the edeploy plugin to stores data in a Swift object on the Undercloud. Discovery no longer fails when using the edeploy plugin.

Hostnames were inappropriately configured on the Overcloud nodes. This meant Pacemaker could not resolve the cluster member's name. This fix shortens the hostnames, which means Nova and Neutron now do not append invalid domain names.

Hostnames were inappropriately configured on the Overcloud nodes. This meant Pacemaker could not resolve the cluster member's name. This fix shortens the hostnames, which means Nova and Neutron now do not append invalid domain names.

With this release, a new enhancement allows allocating specific IP address ranges for isolated networks.

As a result, it is now possible to specify IP address allocation by setting the following parameters in the Overcloud Orchestration template:

* InternalApiAllocationPools
* StorageAllocationPools
* StorageMgmtAllocationPools
* TenantAllocationPools
* ExternalAllocationPools

With this release, a new enhancement allows allocating specific IP address ranges for isolated networks.

As a result, it is now possible to specify IP address allocation by setting the following parameters in the Overcloud Orchestration template:

* InternalApiAllocationPools
* StorageAllocationPools
* StorageMgmtAllocationPools
* TenantAllocationPools
* ExternalAllocationPools

With this release, you can now configure the Compute VNC proxy network. This allows you to isolate various networks and specify which services run where.

As a result, it is now possible to specify which network to use for the Compute VNC proxy by setting the ServiceNetMap -> NovaVncProxyNetwork parameter in the Overcloud Orchestration template.

With this release, you can now configure the Compute VNC proxy network. This allows you to isolate various networks and specify which services run where.

As a result, it is now possible to specify which network to use for the Compute VNC proxy by setting the ServiceNetMap -> NovaVncProxyNetwork parameter in the Overcloud Orchestration template.

This enhancement add VLAN identifiers and OVS bond options to Heat templates. This reduces the amount of duplicate configuration. The Heat templates now contain the following parameters: BondInterfaceOvsOptions, StorageNetworkVlanID, StorageMgmtNetworkVlanID, InternalApiNetworkVlanID, TenantNetworkVlanID, ExternalNetworkVlanID,

This enhancement add VLAN identifiers and OVS bond options to Heat templates. This reduces the amount of duplicate configuration. The Heat templates now contain the following parameters: BondInterfaceOvsOptions, StorageNetworkVlanID, StorageMgmtNetworkVlanID, InternalApiNetworkVlanID, TenantNetworkVlanID, ExternalNetworkVlanID,

HAProxy failed to configure the Horizon listener, which caused unavailability of Horizon on the public VIP. This fix eanbles the HAProxy Horizon listener and the Horizon dashboard is now available on the public VIP.

HAProxy failed to configure the Horizon listener, which caused unavailability of Horizon on the public VIP. This fix eanbles the HAProxy Horizon listener and the Horizon dashboard is now available on the public VIP.

Ceilometer uses an incorrect redis VIP for its backend_url. This fix sets the Ceilometer backend_url to one that Heat provides and not constructed during deployment. Ceilometer now uses the correct IP address.

Ceilometer uses an incorrect redis VIP for its backend_url. This fix sets the Ceilometer backend_url to one that Heat provides and not constructed during deployment. Ceilometer now uses the correct IP address.

The novncproxy service failed to start due to socket binding conflicts. This meant novncproxy service would not be available. This fix configures the novncproxy serviceto bind only on the controller internal_api address. The novncproxy now starts successfully.

The novncproxy service failed to start due to socket binding conflicts. This meant novncproxy service would not be available. This fix configures the novncproxy serviceto bind only on the controller internal_api address. The novncproxy now starts successfully.

Previously, a race condition occurred during the initialization of the neutron database when neutron-server was first run. This error was seen when two controllers happened to start neutron-server simultaneously. Subsequently, the startup of neutron-server and agents failed on the controller node that lost the race, and as a consequence, Neutron services failed to start on the affected controller nodes. Errors in the logs look like the following:

    DBDuplicateEntry: (IntegrityError) (1062, "Duplicate entry 'datacentre-1' for key 'PRIMARY'") 'INSERT INTO ml2_vlan_allocations (physical_network, vlan_id, allocated) VALUES (%s, %s, %s)' (('datacentre', 1, 0),

With this release, the Neutron server is momentarily started and then stopped on one node, the pacemaker master, allowing this initial database setup to happen, before allowing the rest of the puppet or pacemaker configuration to happen. As a result, Neutron services are brought up on all controllers nodes without error.

Previously, a race condition occurred during the initialization of the neutron database when neutron-server was first run. This error was seen when two controllers happened to start neutron-server simultaneously. Subsequently, the startup of neutron-server and agents failed on the controller node that lost the race, and as a consequence, Neutron services failed to start on the affected controller nodes. Errors in the logs look like the following:

    DBDuplicateEntry: (IntegrityError) (1062, "Duplicate entry 'datacentre-1' for key 'PRIMARY'") 'INSERT INTO ml2_vlan_allocations (physical_network, vlan_id, allocated) VALUES (%s, %s, %s)' (('datacentre', 1, 0),

With this release, the Neutron server is momentarily started and then stopped on one node, the pacemaker master, allowing this initial database setup to happen, before allowing the rest of the puppet or pacemaker configuration to happen. As a result, Neutron services are brought up on all controllers nodes without error.

The mongodb node list would only build correctly on one Controller node, which meant all other Controller nodes had Ceilometer configured with an empty list of mongodb nodes. This fix corrects the mongodb node list on all Controller nodes. Ceilometer has a properly populated list of mongodb nodes.

The mongodb node list would only build correctly on one Controller node, which meant all other Controller nodes had Ceilometer configured with an empty list of mongodb nodes. This fix corrects the mongodb node list on all Controller nodes. Ceilometer has a properly populated list of mongodb nodes.

An incorrect configuration of the HAProxy backend caused HAProxy to forward requests for the glance-registry service to offline nodes. This fix monitors the glance-registry service for updates to ensure offline nodes are detected.

An incorrect configuration of the HAProxy backend caused HAProxy to forward requests for the glance-registry service to offline nodes. This fix monitors the glance-registry service for updates to ensure offline nodes are detected.

The HAProxy listener for Galera would bind on the ctlplane address. This meant clients could not reach the Galera service when using an Overcloud with network isolation. This fix changes the binding address of the HAProxy Galera listener to the VIP in the internal_api network. Clients now can reach the Galera service on Overclouds with network isolation.

The HAProxy listener for Galera would bind on the ctlplane address. This meant clients could not reach the Galera service when using an Overcloud with network isolation. This fix changes the binding address of the HAProxy Galera listener to the VIP in the internal_api network. Clients now can reach the Galera service on Overclouds with network isolation.

HAProxy did not use clustercheck to check MariaDB's backends status. This caused HAProxy to forward requests to MariaDB nodes responsive at the TCP check but not in synchronization with the Galera cluster. This fix now uses clustercheck to check MariaDB's backends status. HAProxy now forwards requests to MariaDB nodes correctly.

HAProxy did not use clustercheck to check MariaDB's backends status. This caused HAProxy to forward requests to MariaDB nodes responsive at the TCP check but not in synchronization with the Galera cluster. This fix now uses clustercheck to check MariaDB's backends status. HAProxy now forwards requests to MariaDB nodes correctly.

The distro-specific hieradata file did not apply onto the Overcloud nodes. This fix provides the static RedHat.yaml for distribution on all Overcloud nodes.

The distro-specific hieradata file did not apply onto the Overcloud nodes. This fix provides the static RedHat.yaml for distribution on all Overcloud nodes.

The mariadb service started on boot, which caused Pacemaker's mariadb resource to fail after a reboot. This fix disables the mariadb service from automatically starting on boot. This means mariadb is fully controlled as a Pacemaker resource.

The mariadb service started on boot, which caused Pacemaker's mariadb resource to fail after a reboot. This fix disables the mariadb service from automatically starting on boot. This means mariadb is fully controlled as a Pacemaker resource.

The Keystone service started through Pacemaker and as a systemd dependency of the Ceilometer resource in Pacemaker. This caused conflicts between the two versions of the Keystone service starting that produced failures for the Pacemaker Keystone resource to start. This fix adds a Pacemaker constraint to halt the Ceilometer resource until the Keystone resource starts. Keystone starts before Ceilometer and the Keystone service does not start through systemd.

The Keystone service started through Pacemaker and as a systemd dependency of the Ceilometer resource in Pacemaker. This caused conflicts between the two versions of the Keystone service starting that produced failures for the Pacemaker Keystone resource to start. This fix adds a Pacemaker constraint to halt the Ceilometer resource until the Keystone resource starts. Keystone starts before Ceilometer and the Keystone service does not start through systemd.

Deployments with the director plans behaved differently to Heat template-based deployments due to a missing ControlPlaneNetwork  parameter. This caused plan-based Overcloud deployments to fail when using network isolation. This fix includes a patch to include the ControlPlaneNetwork parameter. Now the Overcloud deploys properly.

Deployments with the director plans behaved differently to Heat template-based deployments due to a missing ControlPlaneNetwork  parameter. This caused plan-based Overcloud deployments to fail when using network isolation. This fix includes a patch to include the ControlPlaneNetwork parameter. Now the Overcloud deploys properly.

Heat services restarted on unrelated redis VIP relocation. In Pacemaker, the Heat resource failed to restart due to dependencies on the Ceilometer resource, which failed to restart on relocation of the redis VIP due to clustering failures. This fix stops Heat from restarting when Ceilometer restarts.

Heat services restarted on unrelated redis VIP relocation. In Pacemaker, the Heat resource failed to restart due to dependencies on the Ceilometer resource, which failed to restart on relocation of the redis VIP due to clustering failures. This fix stops Heat from restarting when Ceilometer restarts.

On Overclouds with network isolation enabled, Pacemaker set the redis master to a hostname on a network where the master was unreachable. This meant redis nodes failed to join the cluster. This fix  resolves Pacemaker hostnames against the internal_api addresses when deploying with network isolation.

On Overclouds with network isolation enabled, Pacemaker set the redis master to a hostname on a network where the master was unreachable. This meant redis nodes failed to join the cluster. This fix  resolves Pacemaker hostnames against the internal_api addresses when deploying with network isolation.

Previously, OpenStack was using the NeutronScale puppet resource that was enabled on controller nodes and tasked with rewriting the neutron agents' "host" entries to look like "neutron-n-0" on controller 0 or "neutron-n-1" on controller 1. This renaming was done toward the end of the deployment, when the corresponding neutron-scale resource was started by pacemaker. Mostly reported in VM environments, neutron would subsequently complain about not having enough L3 agents for L3 HA, and there would be inconsistency in the overcloud neutron agent-list. Consequently, in some cases, the error manifested itself in an error message from Neutron that there were not enough L3 agents to provide HA (the default minimum of 2). The "neutron agent-list" command on the overcloud would show inconsistency in the agents; for example, duplicate entries for each agent with both the original agent on host "overcloud-controller-1.localdomain" (typically shown "XXX") and the "newer" agent on host "neutron-n-1" (alive status ":-)"). In other cases, agent renaming would cause one of the neutron agents, openvswitch, to fail when there was only one controller, and then the rest of the agents under it would also fail to start as they were chained, resulting in no L3, metadata, or dhcp agents.

This problem has been fixed by ensuring that the native neutron L3 High Availability is used, and that enough DHCP agents per network are enabled for native neutron HA. The latter is a needed addition as it was previously statically set at two in all cases. This was added as a configurable parameter in the tripleo heat templates with a default value of '3' and also wired up to deploy in the oscplugin. The NeutronScale resource itself has been removed from the tripleo heat templates where the overcloud controller puppet manifest is kept. As a result, deployments made after this fix will not have the neutron-scale resource on controller nodes, which can be verified by the following commands:

1. On a controller node:
# pcs status | grep -n neutron -A 1

You should not see any "neutron-scale" clone set or resource definition.

2. On the undercloud:
$ source overcloudrc
$ neutron agent-list

All the neutron agents should be reported as being on a host with a name like "overcloud-controller-0.localdomain" or "overcloud-controller-2.localdomain" but not "neutron-n-0" or "neutron-n-2".

Previously, OpenStack was using the NeutronScale puppet resource that was enabled on controller nodes and tasked with rewriting the neutron agents' "host" entries to look like "neutron-n-0" on controller 0 or "neutron-n-1" on controller 1. This renaming was done toward the end of the deployment, when the corresponding neutron-scale resource was started by pacemaker. Mostly reported in VM environments, neutron would subsequently complain about not having enough L3 agents for L3 HA, and there would be inconsistency in the overcloud neutron agent-list. Consequently, in some cases, the error manifested itself in an error message from Neutron that there were not enough L3 agents to provide HA (the default minimum of 2). The "neutron agent-list" command on the overcloud would show inconsistency in the agents; for example, duplicate entries for each agent with both the original agent on host "overcloud-controller-1.localdomain" (typically shown "XXX") and the "newer" agent on host "neutron-n-1" (alive status ":-)"). In other cases, agent renaming would cause one of the neutron agents, openvswitch, to fail when there was only one controller, and then the rest of the agents under it would also fail to start as they were chained, resulting in no L3, metadata, or dhcp agents.

This problem has been fixed by ensuring that the native neutron L3 High Availability is used, and that enough DHCP agents per network are enabled for native neutron HA. The latter is a needed addition as it was previously statically set at two in all cases. This was added as a configurable parameter in the tripleo heat templates with a default value of '3' and also wired up to deploy in the oscplugin. The NeutronScale resource itself has been removed from the tripleo heat templates where the overcloud controller puppet manifest is kept. As a result, deployments made after this fix will not have the neutron-scale resource on controller nodes, which can be verified by the following commands:

1. On a controller node:
# pcs status | grep -n neutron -A 1

You should not see any "neutron-scale" clone set or resource definition.

2. On the undercloud:
$ source overcloudrc
$ neutron agent-list

All the neutron agents should be reported as being on a host with a name like "overcloud-controller-0.localdomain" or "overcloud-controller-2.localdomain" but not "neutron-n-0" or "neutron-n-2".

Controller nodes did not share consoleauth tokens, which caused failures with parts of authentication requests. This fix incorporates memcached to share consoleauth tokens. Authentication requests are now successful.

Controller nodes did not share consoleauth tokens, which caused failures with parts of authentication requests. This fix incorporates memcached to share consoleauth tokens. Authentication requests are now successful.

This release allows you to configure the neutron_tunnel_id_ranges and neutron_vni_ranges parameters, which govern the GRE or VXLAN tunnel IDs respectively. These are to be made available for overcloud tenant networks by overcloud Neutron. As an example, you can specify:

# openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 1  --neutron-tunnel-id-ranges "1:1111,2:2222" --neutron-vni-ranges "3:33,5:55,100:999" --neutron-tunnel-types "gre,vxlan"

If not specified, tunnel_id_ranges and neutron_vni_ranges both default to "1:1000", which may be unsuitable or restrictive for some deployment scenarios.

If deploying as shown in the example above, you can inspect and verify the relevant neutron configuration files on a controller node (post deploy), for instance:

# grep -rni 'vni_ranges\|id_ranges\|tunnel_types' /etc/neutron/*
/etc/neutron/plugin.ini:78:tunnel_id_ranges =1:1111,2:2222
/etc/neutron/plugin.ini:85:vni_ranges =3:33,5:55,100:999
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:77:tunnel_types =gre,vxlan
/etc/neutron/plugins/ml2/ml2_conf.ini:78:tunnel_id_ranges =1:1111,2:2222
/etc/neutron/plugins/ml2/ml2_conf.ini:85:vni_ranges =3:33,5:55,100:999

You can also test by creating an overcloud network (again, post-deploy), for instance:

# source overcloudrc # from the undercloud box for example
# neutron net-create --provider:network_type "vxlan" "foo"

This will create a vxlan type network. On inspection you can verify that this received a segmentation ID from the specified vni_ranges:

# neutron net-show foo
| provider:network_type     | vxlan
| provider:segmentation_id  | 3

Likewise, you can verify an appropriate segmentation ID is assigned for GRE networks.

This release allows you to configure the neutron_tunnel_id_ranges and neutron_vni_ranges parameters, which govern the GRE or VXLAN tunnel IDs respectively. These are to be made available for overcloud tenant networks by overcloud Neutron. As an example, you can specify:

# openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 1  --neutron-tunnel-id-ranges "1:1111,2:2222" --neutron-vni-ranges "3:33,5:55,100:999" --neutron-tunnel-types "gre,vxlan"

If not specified, tunnel_id_ranges and neutron_vni_ranges both default to "1:1000", which may be unsuitable or restrictive for some deployment scenarios.

If deploying as shown in the example above, you can inspect and verify the relevant neutron configuration files on a controller node (post deploy), for instance:

# grep -rni 'vni_ranges\|id_ranges\|tunnel_types' /etc/neutron/*
/etc/neutron/plugin.ini:78:tunnel_id_ranges =1:1111,2:2222
/etc/neutron/plugin.ini:85:vni_ranges =3:33,5:55,100:999
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:77:tunnel_types =gre,vxlan
/etc/neutron/plugins/ml2/ml2_conf.ini:78:tunnel_id_ranges =1:1111,2:2222
/etc/neutron/plugins/ml2/ml2_conf.ini:85:vni_ranges =3:33,5:55,100:999

You can also test by creating an overcloud network (again, post-deploy), for instance:

# source overcloudrc # from the undercloud box for example
# neutron net-create --provider:network_type "vxlan" "foo"

This will create a vxlan type network. On inspection you can verify that this received a segmentation ID from the specified vni_ranges:

# neutron net-show foo
| provider:network_type     | vxlan
| provider:segmentation_id  | 3

Likewise, you can verify an appropriate segmentation ID is assigned for GRE networks.

Previously, uncoordinated creation of the overcloud Keystone admin tenant caused errors in a deployment with more than one controller. As a consequence, Heat stack creation failed on the ControllerNodesPostDeployment resource, and Keystone returned a 409 ERROR: openstack Conflict occurred attempting to store project - Duplicate Entry (HTTP 409). The Puppet run failed at that point. The fix for this problem includes the creation of the admin tenant on the pacemaker master node first. As a result, deployments with more than one controller correctly create the overcloud keystone admin user. After a successful deployment you can verify this by interacting with any of the overcloud services as the admin user:

# on the undercloud system, for example:
$ source overcloudrc
$ keystone user-list

Previously, uncoordinated creation of the overcloud Keystone admin tenant caused errors in a deployment with more than one controller. As a consequence, Heat stack creation failed on the ControllerNodesPostDeployment resource, and Keystone returned a 409 ERROR: openstack Conflict occurred attempting to store project - Duplicate Entry (HTTP 409). The Puppet run failed at that point. The fix for this problem includes the creation of the admin tenant on the pacemaker master node first. As a result, deployments with more than one controller correctly create the overcloud keystone admin user. After a successful deployment you can verify this by interacting with any of the overcloud services as the admin user:

# on the undercloud system, for example:
$ source overcloudrc
$ keystone user-list

Tuskar modified the names of the top level parameters in the Heat stack when deploying an Overcloud. This caused an error during stack validation from Heat:

ERROR: The Parameter (NeutronExternalNetworkBridge) was not defined in template.

As a workaround, use "tuskar plan-update" to modify the parameter, or use the modified parameter name in the environment file:

parameters:
  Controller-1::NeutronExternalNetworkBridge: "''"

Overcloud deploys using the correct parameter value.

Note: the parameter needs to be defined in the "parameters:" section, not the "parameter_defaults:" section. Otherwise, the value set in Tuskar's exported environment.yaml overrides the value.

Tuskar modified the names of the top level parameters in the Heat stack when deploying an Overcloud. This caused an error during stack validation from Heat:

ERROR: The Parameter (NeutronExternalNetworkBridge) was not defined in template.

As a workaround, use "tuskar plan-update" to modify the parameter, or use the modified parameter name in the environment file:

parameters:
  Controller-1::NeutronExternalNetworkBridge: "''"

Overcloud deploys using the correct parameter value.

Note: the parameter needs to be defined in the "parameters:" section, not the "parameter_defaults:" section. Otherwise, the value set in Tuskar's exported environment.yaml overrides the value.

Compute nodes queried Keystone for the Cinder publicurl endpoint, regardless of whether they had connectivity. This meant dedicated Compute nodes failed to interact with Cinder API. This fix changes the publicurl endpoint to the internalurl endpoint, which Compute nodes can access.

Compute nodes queried Keystone for the Cinder publicurl endpoint, regardless of whether they had connectivity. This meant dedicated Compute nodes failed to interact with Cinder API. This fix changes the publicurl endpoint to the internalurl endpoint, which Compute nodes can access.

Cinder Storage nodes queried Keystone for the Nova and Swift publicurl endpoints, regardless of  whether they had access. This meant dedicated Cinder Storage nodes could not interact with Nova and Swift APIs. This fix changes the publicurl endpoints to internalurl endpoints, and Cinder Storage nodes now communicate with Nova and Swift APIs successfully.

Cinder Storage nodes queried Keystone for the Nova and Swift publicurl endpoints, regardless of  whether they had access. This meant dedicated Cinder Storage nodes could not interact with Nova and Swift APIs. This fix changes the publicurl endpoints to internalurl endpoints, and Cinder Storage nodes now communicate with Nova and Swift APIs successfully.

Prior to this release, the allow_overlapping_ips Neutron setting was left at default. As a consequence, allow_overlapping_ips in Neutron was disabled, preventing definition of multiple networks with the same ranges. This problem has been fixed by setting allow_overlapping_ips to "true", and as a result, networks with overlapping ranges can be defined.

Prior to this release, the allow_overlapping_ips Neutron setting was left at default. As a consequence, allow_overlapping_ips in Neutron was disabled, preventing definition of multiple networks with the same ranges. This problem has been fixed by setting allow_overlapping_ips to "true", and as a result, networks with overlapping ranges can be defined.

Previously, the default Ceph scale was set to 1, resulting in a Ceph node being created even if the user did not want to create one.

With this release, the default Ceph scale setting has been changed to 0. As a result, Ceph is not deployed by default anymore.

Previously, the default Ceph scale was set to 1, resulting in a Ceph node being created even if the user did not want to create one.

With this release, the default Ceph scale setting has been changed to 0. As a result, Ceph is not deployed by default anymore.

The os-apply-config command created /etc/puppet/hieradata with open permissions. The files in this directory contained passwords and tokens that could provide unauthorized access to the OpenStack installation. This fix sets /etc/puppet/hieradata as a root-owned directory with 0700 permissions. Only the root user can access /etc/puppet/hieradata, which provides a more secure installation.

The os-apply-config command created /etc/puppet/hieradata with open permissions. The files in this directory contained passwords and tokens that could provide unauthorized access to the OpenStack installation. This fix sets /etc/puppet/hieradata as a root-owned directory with 0700 permissions. Only the root user can access /etc/puppet/hieradata, which provides a more secure installation.

Overcloud nodes contained incorrectly synchronized system times. This resulted in various errors across the HA Controller cluster. As a workaround, pass the --ntp-server command line argument when running the "openstack overcloud deploy" command. This argument configures the ntp server in /etc/ntp.conf on each Overcloud node and starts the ntpd service. This produces properly synchronized system times and a successful Overcloud deployment.

Overcloud nodes contained incorrectly synchronized system times. This resulted in various errors across the HA Controller cluster. As a workaround, pass the --ntp-server command line argument when running the "openstack overcloud deploy" command. This argument configures the ntp server in /etc/ntp.conf on each Overcloud node and starts the ntpd service. This produces properly synchronized system times and a successful Overcloud deployment.

Previously, migration to a puppet deployment meant that the boot-stack tripleo-image-element was no longer creating the initial Tuskar database. Consequently, after successful installation of the undercloud, the Tuskar service was not correctly configured. This release ensures that Tuskar is properly installed and configured for the undercloud. As a result, after successful installation of the undercloud, you can interact with the Tuskar service.

Previously, migration to a puppet deployment meant that the boot-stack tripleo-image-element was no longer creating the initial Tuskar database. Consequently, after successful installation of the undercloud, the Tuskar service was not correctly configured. This release ensures that Tuskar is properly installed and configured for the undercloud. As a result, after successful installation of the undercloud, you can interact with the Tuskar service.

The tuskar service configuration parameter auth_strategy defaulted to "noauth". This allowed unrestricted access to the tuskar management plan and roles, including templates and any set sensitive parameters like passwords. This fix sets the default to keystone authentication. Now non-authenticated http requests to the tuskar service will return a HTTP 401 Unauthorized error. Use the following command to verify from the Undercloud:

$ curl -v localhost:8585/v2/plans

The tuskar service configuration parameter auth_strategy defaulted to "noauth". This allowed unrestricted access to the tuskar management plan and roles, including templates and any set sensitive parameters like passwords. This fix sets the default to keystone authentication. Now non-authenticated http requests to the tuskar service will return a HTTP 401 Unauthorized error. Use the following command to verify from the Undercloud:

$ curl -v localhost:8585/v2/plans

The code for executing bulk actions did not include a check to ensure a node is actually selected. The actions assumed that the list of nodes was not empty. The code generated an uncaught exception, resulting in a "Something went wrong" message when a DEBUG is disabled.

With this update, a check to verify if at least one node is selected is included or to display a helpful error message when no node is selected. As a result, trying to perform a bulk action with no nodes selected results in a helpful message telling you to select some nodes first.

The code for executing bulk actions did not include a check to ensure a node is actually selected. The actions assumed that the list of nodes was not empty. The code generated an uncaught exception, resulting in a "Something went wrong" message when a DEBUG is disabled.

With this update, a check to verify if at least one node is selected is included or to display a helpful error message when no node is selected. As a result, trying to perform a bulk action with no nodes selected results in a helpful message telling you to select some nodes first.

The node detail URL name was specified incorrectly and rendered incorrectly. This fix corrects the node detail URL name. Now the node detail link renders correctly, which allows access to the node detail page.

The node detail URL name was specified incorrectly and rendered incorrectly. This fix corrects the node detail URL name. Now the node detail link renders correctly, which allows access to the node detail page.

Roles were not added to the plan during Undercloud installation. As a result, there could not be edited using the OpenStack Dashboard.

With this update, the Undercloud installation has been fixed to add roles to the plan. As a result, you can now edit these roles using the Dashboard.

Roles were not added to the plan during Undercloud installation. As a result, there could not be edited using the OpenStack Dashboard.

With this update, the Undercloud installation has been fixed to add roles to the plan. As a result, you can now edit these roles using the Dashboard.

The director's user interface took long periods with page loads due to communicating with External API services such as keystone, heat, ironic and tuskar. This fix adds caching to all External service calls to reduce the amount of calls and decrease page load times. Page loading times are now significantly faster when accessing the user interface.

The director's user interface took long periods with page loads due to communicating with External API services such as keystone, heat, ironic and tuskar. This fix adds caching to all External service calls to reduce the amount of calls and decrease page load times. Page loading times are now significantly faster when accessing the user interface.

The user interface attempted to connect to the Overcloud keystone-api before the creation and initialization of the corresponding endpoint. The user interface would not find the endpoint the Overcloud would not initialize from the user interface. This fix enables the user interface to properly identify when the Overcloud has not yet been initialized. The error no longer occurs.

The user interface attempted to connect to the Overcloud keystone-api before the creation and initialization of the corresponding endpoint. The user interface would not find the endpoint the Overcloud would not initialize from the user interface. This fix enables the user interface to properly identify when the Overcloud has not yet been initialized. The error no longer occurs.

The post-install validation was not implemented in the unified CLI, it was implemented only in the deprecated OpenStack Deployment (tripleO) scripts. As a result, the command was missing from python-rdomanager-oscplugin.

With this update, the post-install validation is implemented and the 'openstack overcloud validate' command is now present in the CLI.

The post-install validation was not implemented in the unified CLI, it was implemented only in the deprecated OpenStack Deployment (tripleO) scripts. As a result, the command was missing from python-rdomanager-oscplugin.

With this update, the post-install validation is implemented and the 'openstack overcloud validate' command is now present in the CLI.

The DRAC ready-state configuration was not implemented in the unified CLI, it was implemented only in the deprecated OpenStack Deployment (tripleO) scripts. As a result, the command was missing from python-rdomanager-oscplugin.

With this update, the DRAC ready-state is implemented and 'openstack baremetal configure ready state' command is now present in the CLI.

The DRAC ready-state configuration was not implemented in the unified CLI, it was implemented only in the deprecated OpenStack Deployment (tripleO) scripts. As a result, the command was missing from python-rdomanager-oscplugin.

With this update, the DRAC ready-state is implemented and 'openstack baremetal configure ready state' command is now present in the CLI.

This release introduces four parameters that govern the default overcloud neutron tenant network behavior: --neutron-network-type, --neutron-tunnel-types, --neutron-disable-tunneling, and --neutron-network-vlan-ranges. The default is to provide GRE types and tunnels for overcloud tenant networks.

If the --neutron-network-type is specified as 'vlan', you can also set the --neutron-network-vlan-ranges parameter, which governs the range of VLAN IDs to be allocated to overcloud Neutron tenant networks (defaults to "datacenter:1:1000", where "datacenter" must be the name of the Neutron physical network where the VLANs will be allocated). If exclusively specifying 'vlan' as the network type, then --neutron-disable-tunneling must also be specified (examples below).

If the --neutron-network-type is specified as 'gre' or 'vxlan' (or both), then the corresponding --neutron-tunnel-types must also be enabled (examples below). Furthermore, when specifying the 'gre' or 'vxlan' network types, you can further set the related --neutron-tunnel-id-ranges and --neutron-vni-ranges parameters that govern the GRE or VXLAN tunnel IDs respectively. These are to be made available for the tenant networks.

Examples:
* Specify the 'vxlan' type for overcloud tenant networks:
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "vxlan" --neutron-tunnel-types "vxlan"

* Specify both 'gre' and 'vxlan' overcloud tenant networks:
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "gre,vxlan" --neutron-tunnel-types "gre,vxlan"

* Specify the 'vlan' type for overcloud tenant networks, as well as the VLAN ranges:
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "vlan" --neutron-disable-tunneling --neutron-network-vlan-ranges "datacenter:3:3000"

These parameters default to the following values when not specified at deployment time, and may be deemed restrictive or unsuitable for a given deployment scenario:

--neutron-network-type # default 'gre'
--neutron-tunnel-types # default 'gre'
--neutron-disable-tunneling # defaults to tunneling being enabled
--neutron-network-vlan-ranges # 'datacenter:1:1000'

After deployment, you can verify that the following are set in the Neutron configuration logs on a controller node; the values here should correspond to those specified during the deployment as shown above:

grep -rni 'tunnel_types\|network_type\|enable_tunneling\|vlan_ranges' /etc/neutron/*
/etc/neutron/plugin.ini:14:tenant_network_types = vlan
/etc/neutron/plugin.ini:72:network_vlan_ranges =datacenter:3:3000
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:54:enable_tunneling=False
/etc/neutron/plugins/ml2/ml2_conf.ini:14:tenant_network_types = vlan
/etc/neutron/plugins/ml2/ml2_conf.ini:72:network_vlan_ranges =datacenter:3:3000

Also, you can create a network in overcloud Neutron and inspect it; for example, on the undercloud:

$ source overcloudrc
$ neutron net-create "default"
$ neutron net-show default
...
| provider:network_type     | vlan                                 |
| provider:physical_network | datacenter                           |
| provider:segmentation_id  | 3                                    |
...

This release introduces four parameters that govern the default overcloud neutron tenant network behavior: --neutron-network-type, --neutron-tunnel-types, --neutron-disable-tunneling, and --neutron-network-vlan-ranges. The default is to provide GRE types and tunnels for overcloud tenant networks.

If the --neutron-network-type is specified as 'vlan', you can also set the --neutron-network-vlan-ranges parameter, which governs the range of VLAN IDs to be allocated to overcloud Neutron tenant networks (defaults to "datacenter:1:1000", where "datacenter" must be the name of the Neutron physical network where the VLANs will be allocated). If exclusively specifying 'vlan' as the network type, then --neutron-disable-tunneling must also be specified (examples below).

If the --neutron-network-type is specified as 'gre' or 'vxlan' (or both), then the corresponding --neutron-tunnel-types must also be enabled (examples below). Furthermore, when specifying the 'gre' or 'vxlan' network types, you can further set the related --neutron-tunnel-id-ranges and --neutron-vni-ranges parameters that govern the GRE or VXLAN tunnel IDs respectively. These are to be made available for the tenant networks.

Examples:
* Specify the 'vxlan' type for overcloud tenant networks:
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "vxlan" --neutron-tunnel-types "vxlan"

* Specify both 'gre' and 'vxlan' overcloud tenant networks:
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "gre,vxlan" --neutron-tunnel-types "gre,vxlan"

* Specify the 'vlan' type for overcloud tenant networks, as well as the VLAN ranges:
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "vlan" --neutron-disable-tunneling --neutron-network-vlan-ranges "datacenter:3:3000"

These parameters default to the following values when not specified at deployment time, and may be deemed restrictive or unsuitable for a given deployment scenario:

--neutron-network-type # default 'gre'
--neutron-tunnel-types # default 'gre'
--neutron-disable-tunneling # defaults to tunneling being enabled
--neutron-network-vlan-ranges # 'datacenter:1:1000'

After deployment, you can verify that the following are set in the Neutron configuration logs on a controller node; the values here should correspond to those specified during the deployment as shown above:

grep -rni 'tunnel_types\|network_type\|enable_tunneling\|vlan_ranges' /etc/neutron/*
/etc/neutron/plugin.ini:14:tenant_network_types = vlan
/etc/neutron/plugin.ini:72:network_vlan_ranges =datacenter:3:3000
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:54:enable_tunneling=False
/etc/neutron/plugins/ml2/ml2_conf.ini:14:tenant_network_types = vlan
/etc/neutron/plugins/ml2/ml2_conf.ini:72:network_vlan_ranges =datacenter:3:3000

Also, you can create a network in overcloud Neutron and inspect it; for example, on the undercloud:

$ source overcloudrc
$ neutron net-create "default"
$ neutron net-show default
...
| provider:network_type     | vlan                                 |
| provider:physical_network | datacenter                           |
| provider:segmentation_id  | 3                                    |
...

The Unified CLI displays a timed out error, expecting the OpenStack overcloud deployment to have been incomplete. As a result, the user incorrectly gets a message that the resulting deployment failed.

With this update, the timeout value is increased to an hour. As a result, deployments should now finish within the timeout.

The Unified CLI displays a timed out error, expecting the OpenStack overcloud deployment to have been incomplete. As a result, the user incorrectly gets a message that the resulting deployment failed.

With this update, the timeout value is increased to an hour. As a result, deployments should now finish within the timeout.

With this release, a duplicated command for scaling a deployment has been removed in favor of scaling a deployment directly using Tuskar or using the deploy command.

With this release, a duplicated command for scaling a deployment has been removed in favor of scaling a deployment directly using Tuskar or using the deploy command.

Issues in the KVM PXE code displayed failures when too many nodes tried to PXE-boot simultaneously, resulting in some nodes failing to connect to DHCP.

With this update, the sleep value is increased, allowing introspection on the nodes. As a result, DHCP is no longer an issue, making the introspection a little longer.

Issues in the KVM PXE code displayed failures when too many nodes tried to PXE-boot simultaneously, resulting in some nodes failing to connect to DHCP.

With this update, the sleep value is increased, allowing introspection on the nodes. As a result, DHCP is no longer an issue, making the introspection a little longer.

Previously, when using the 'openstack overcloud deploy' command, some of the command line parameters were not being used by the code. As a result, the user was unable to set these parameters.

With this release, the parameters are now used and sent to the Orchestration service.

Previously, when using the 'openstack overcloud deploy' command, some of the command line parameters were not being used by the code. As a result, the user was unable to set these parameters.

With this release, the parameters are now used and sent to the Orchestration service.

The OpenStack Overcloud validate ran the OpenStack Integration Test Suite (tempest) as documented upstream instead of using a midstream tool in redhat-openstack/tempest, resulting in an output format that was different.

With this update, the OpenStack Overcloud validate runs tempest using the midstream tool and the output format is as expected.

The OpenStack Overcloud validate ran the OpenStack Integration Test Suite (tempest) as documented upstream instead of using a midstream tool in redhat-openstack/tempest, resulting in an output format that was different.

With this update, the OpenStack Overcloud validate runs tempest using the midstream tool and the output format is as expected.

The CLI had no method of customizing certain Neutron parameters. This fix adds news arguments to the deploy command. The user provides these arguments with "Openstack overcloud deploy" command to configure these parameters.

The CLI had no method of customizing certain Neutron parameters. This fix adds news arguments to the deploy command. The user provides these arguments with "Openstack overcloud deploy" command to configure these parameters.

Tuskar API expected all parameters to be strings, but since some of the parameters were passed as integer values, the API would reject those.

With this update, all parameters are converted to strings before being sent to the API. As a result, the API accepts all parameters and the deployment works successfully.

Tuskar API expected all parameters to be strings, but since some of the parameters were passed as integer values, the API would reject those.

With this update, all parameters are converted to strings before being sent to the API. As a result, the API accepts all parameters and the deployment works successfully.

The director used hard coded paths to the Heat template collection in /usr/share/openstack-tripleo-heat-templates/. This caused problems when using a custom Heat template e.g. creating a local copy and customizing it. This fix provides variable input with the --template argument. Users can now create an Overcloud with a customised Heat template collection.

The director used hard coded paths to the Heat template collection in /usr/share/openstack-tripleo-heat-templates/. This caused problems when using a custom Heat template e.g. creating a local copy and customizing it. This fix provides variable input with the --template argument. Users can now create an Overcloud with a customised Heat template collection.

Previously, the necessary parameters were not passed to Orchestration service correctly for an OpenStack Overcloud redeployment, resulting in an UPGRADE_FAILED message.

With this update, a parameter 'Existing=True' is added to the Orchestration update parameters, resulting in a successful Overcloud deployment.

Previously, the necessary parameters were not passed to Orchestration service correctly for an OpenStack Overcloud redeployment, resulting in an UPGRADE_FAILED message.

With this update, a parameter 'Existing=True' is added to the Orchestration update parameters, resulting in a successful Overcloud deployment.

During deployment, the heat engine logs return a non-zero error due to no valid hosts being found, despite the ironic logs showing nodes available. This is due to the director not setting nodes to "available" when the "openstack baremetal introspection" command completes. This fix sets the nodes to "available" after the introspection completes. The director now sees the nodes when deploying the Overcloud.

During deployment, the heat engine logs return a non-zero error due to no valid hosts being found, despite the ironic logs showing nodes available. This is due to the director not setting nodes to "available" when the "openstack baremetal introspection" command completes. This fix sets the nodes to "available" after the introspection completes. The director now sees the nodes when deploying the Overcloud.

In addition to using plans stored in its database, the director now also uses Heat template collections to create an Overcloud. This provides a method to use Heat templates directly when running "openstack overcloud stack update" command to update packages on the Overcloud. If you created the Overcloud using a template collection instead of a plan, run "openstack overcloud stack update" command with the "--templates" parameter instead of the "--plan" parameter.

In addition to using plans stored in its database, the director now also uses Heat template collections to create an Overcloud. This provides a method to use Heat templates directly when running "openstack overcloud stack update" command to update packages on the Overcloud. If you created the Overcloud using a template collection instead of a plan, run "openstack overcloud stack update" command with the "--templates" parameter instead of the "--plan" parameter.

The director now provides parameters to accept extra Heat environment files when updating packages on Overcloud nodes. Overcloud isolated networks require extra environment files upon creation and subsequent updates. Without the extra environment files, users cannot use "openstack overcloud update stack" on an Overcloud using isolated network. User now use the "-e" parameter with the "openstack overcloud update stack" command to update packages on Overcloud nodes using isolated networks.

The director now provides parameters to accept extra Heat environment files when updating packages on Overcloud nodes. Overcloud isolated networks require extra environment files upon creation and subsequent updates. Without the extra environment files, users cannot use "openstack overcloud update stack" on an Overcloud using isolated network. User now use the "-e" parameter with the "openstack overcloud update stack" command to update packages on Overcloud nodes using isolated networks.

This release allow the use of Heat templates directly when deleting overcloud nodes. You can now run the "openstack overcloud node delete" command with the "--templates" parameter if the overcloud was deployed without Tuskar.

This release allow the use of Heat templates directly when deleting overcloud nodes. You can now run the "openstack overcloud node delete" command with the "--templates" parameter if the overcloud was deployed without Tuskar.

New in this release is the ability to accept extra Heat environment files when deleting a node from overcloud. When using an isolated network, extra environment files must be passed to Heat on any overcloud update. With this update, the "openstack overcloud node delete" command can be used to delete overcloud nodes on an isolated network.

New in this release is the ability to accept extra Heat environment files when deleting a node from overcloud. When using an isolated network, extra environment files must be passed to Heat on any overcloud update. With this update, the "openstack overcloud node delete" command can be used to delete overcloud nodes on an isolated network.

Some arguments existed that provided the same function as other arguments for the deploy command. This fix removes the redundant arguments (--plan-uuid, --use-tripleo-heat-templates, --extra-template).

Some arguments existed that provided the same function as other arguments for the deploy command. This fix removes the redundant arguments (--plan-uuid, --use-tripleo-heat-templates, --extra-template).

A timeout could not be set, which meant deployments always timeout after one hour. This fix adds a timeout argument that allows users to set a custom timeout. It defaults to four hours.

A timeout could not be set, which meant deployments always timeout after one hour. This fix adds a timeout argument that allows users to set a custom timeout. It defaults to four hours.

The Heat templates lacked a certain parameter to configure the Neutron L3 Agent. As a result the director would not configure the L3 Agent properly. This fix adds the
missing Heat parameter to the templates. the director now configures the L3 Agent correctly.

The Heat templates lacked a certain parameter to configure the Neutron L3 Agent. As a result the director would not configure the L3 Agent properly. This fix adds the
missing Heat parameter to the templates. the director now configures the L3 Agent correctly.

Due to a casting bug, 'L3HA' was passed as 'True' for overcloud Neutron configuration when deploying with only one controller. Because Neutron requires a minimum of 2 L3 agents to ensure native L3 HA, it complained when the overcloud tenant networking was set up after an otherwise successful deployment. As a consequence, after a successful deployment and when creating tenant Neutron networks or routers, the following error was returned from Neutron:

    Not enough l3 agents available to ensure HA. Minimum required 2, available 1.

This bug has been fixed by correctly casting the number of controllers to an integer before checking for enablement of L3 HA. As a result, deployments with one controller have 'L3HA' as 'False' in the /etc/neutron/neutron.conf file on the controller node. Deployments with multiple controllers will instead have this set to 'True'.

Due to a casting bug, 'L3HA' was passed as 'True' for overcloud Neutron configuration when deploying with only one controller. Because Neutron requires a minimum of 2 L3 agents to ensure native L3 HA, it complained when the overcloud tenant networking was set up after an otherwise successful deployment. As a consequence, after a successful deployment and when creating tenant Neutron networks or routers, the following error was returned from Neutron:

    Not enough l3 agents available to ensure HA. Minimum required 2, available 1.

This bug has been fixed by correctly casting the number of controllers to an integer before checking for enablement of L3 HA. As a result, deployments with one controller have 'L3HA' as 'False' in the /etc/neutron/neutron.conf file on the controller node. Deployments with multiple controllers will instead have this set to 'True'.

python-tuskarclient had no support to specify a custom CA certificate to verify SSL certificates from the Tuskar API server. Connections failed due the server using an certificate set unknown to the client. This fix adds the --os-cacert option to python-tuskarclient, which allows specification of the CA certificate path. This provides successful communication with the API server.

python-tuskarclient had no support to specify a custom CA certificate to verify SSL certificates from the Tuskar API server. Connections failed due the server using an certificate set unknown to the client. This fix adds the --os-cacert option to python-tuskarclient, which allows specification of the CA certificate path. This provides successful communication with the API server.

On the Overcloud, the glance_store section in /etc/glance/glance-api.conf file sets stores=glance.store.filesystem.Store. This caused problems with image uploads due to the different store types. This fix modifies glance configuration to use glance.store.http.Store for the stores parameter and to include a backend for the store type to use.

On the Overcloud, the glance_store section in /etc/glance/glance-api.conf file sets stores=glance.store.filesystem.Store. This caused problems with image uploads due to the different store types. This fix modifies glance configuration to use glance.store.http.Store for the stores parameter and to include a backend for the store type to use.

Incorrect ordering of DHCP options the configuration file caused machines to fail on boot. This fix uses tags to the DHCP option to provide the correct ordering. Machine now chainload the boot with the iPXE ROM and then invoking the HTTP URL to continue the boot. This results in a successful boot.

Incorrect ordering of DHCP options the configuration file caused machines to fail on boot. This fix uses tags to the DHCP option to provide the correct ordering. Machine now chainload the boot with the iPXE ROM and then invoking the HTTP URL to continue the boot. This results in a successful boot.

The grub configuration set the kernel parameters to redirect the console to a serial port that might not be present. As a result, the node failed to boot. This fix disables console redirection to the serial port by default. The node now boots successfully.

The grub configuration set the kernel parameters to redirect the console to a serial port that might not be present. As a result, the node failed to boot. This fix disables console redirection to the serial port by default. The node now boots successfully.

Upstream Nova defaults to appending "novalocal" to host names. This causes problems with our tooling. The resulting nova host names don't correspond to the names expected by Puppet. This caused CREATE_FAILED on ControllerNodesPostDeployment in the Heat stack during Overcloud creation. This fix overrides the upstream default and does not set the "novalocal" suffix. Now post-deployment Puppet configuration reports a CREATE_COMPLETE on the Overcloud Heat stack.

Upstream Nova defaults to appending "novalocal" to host names. This causes problems with our tooling. The resulting nova host names don't correspond to the names expected by Puppet. This caused CREATE_FAILED on ControllerNodesPostDeployment in the Heat stack during Overcloud creation. This fix overrides the upstream default and does not set the "novalocal" suffix. Now post-deployment Puppet configuration reports a CREATE_COMPLETE on the Overcloud Heat stack.

The deployment_mode configuration for the Undercloud that could be set in instack.answers in tech preview has been removed. deployment_mode allowed choosing a "scale" mode that deployed individual roles onto specific nodes. This functionality has been replaced with the node tagging features part of the Automated Health Check (AHC) tools.

The deployment_mode configuration for the Undercloud that could be set in instack.answers in tech preview has been removed. deployment_mode allowed choosing a "scale" mode that deployed individual roles onto specific nodes. This functionality has been replaced with the node tagging features part of the Automated Health Check (AHC) tools.

The director provides a method to isolate different network services on individual subnets and VLANs. These instructions are contains within the Basic and Advanced Overcloud Scenarios in the Red Hat Enterprise Linux OpenStack Platform 7.0 Director Installation and Usage guide.

The director provides a method to isolate different network services on individual subnets and VLANs. These instructions are contains within the Basic and Advanced Overcloud Scenarios in the Red Hat Enterprise Linux OpenStack Platform 7.0 Director Installation and Usage guide.

Mixing DHCP and static routes both appear in the route table. However, the DHCP route had a metric of 100. This meant the static route with a metric of 0 was always used instead. As a workaround for using multiple DHCP links, you can configure one or more to ignore the default route offered by the DHCP server. Use the "defroute: false" declaration to accomplish this.

Mixing DHCP and static routes both appear in the route table. However, the DHCP route had a metric of 100. This meant the static route with a metric of 0 was always used instead. As a workaround for using multiple DHCP links, you can configure one or more to ignore the default route offered by the DHCP server. Use the "defroute: false" declaration to accomplish this.

Previously, deployment specific values were not provided in OpenStack Integration Test Suite (tempest), resulting in the failure of some tempest tests.

With this update, a '--deployer-input' flag is added for the 'openstack overcloud validate' command so the administrator can provide a file (tempest.conf) containing the deployment specific values. As a result of using the '--deployer-input filename' flag, fewer tests result in failure.

Previously, deployment specific values were not provided in OpenStack Integration Test Suite (tempest), resulting in the failure of some tempest tests.

With this update, a '--deployer-input' flag is added for the 'openstack overcloud validate' command so the administrator can provide a file (tempest.conf) containing the deployment specific values. As a result of using the '--deployer-input filename' flag, fewer tests result in failure.

Redis needs to use a separate VIP. When deploying with network isolation, the director automatically place Redis VIP on the Internal API VIP by default. Operators do have the ability to move Redis to another network using the ServiceNetMap parameter.

Redis needs to use a separate VIP. When deploying with network isolation, the director automatically place Redis VIP on the Internal API VIP by default. Operators do have the ability to move Redis to another network using the ServiceNetMap parameter.

The director previously used a file with network and floating IP options for deployment. However, these network options were ignored in early versions of the director. This fix replaces the file with a set of command line arguments for "openstack overcloud director". The CLI tool now contains the necessary options for configuring network and floating IPs in the Overcloud.

The director previously used a file with network and floating IP options for deployment. However, these network options were ignored in early versions of the director. This fix replaces the file with a set of command line arguments for "openstack overcloud director". The CLI tool now contains the necessary options for configuring network and floating IPs in the Overcloud.

Previously, an error in the name of the 'management_plan.uuid' variable led to attribute errors that would cause all deployments of Tuskar plans to fail. With this update, this variable name has now been corrected.

Previously, an error in the name of the 'management_plan.uuid' variable led to attribute errors that would cause all deployments of Tuskar plans to fail. With this update, this variable name has now been corrected.

When deploying an Overcloud, the director placed the Public VIP services on the Provisioning network's "ctlplane". This meant you could not reach these services from outside of the Overcloud. This fix patches the Heat templates to place the Public VIP on the External network.

When deploying an Overcloud, the director placed the Public VIP services on the Provisioning network's "ctlplane". This meant you could not reach these services from outside of the Overcloud. This fix patches the Heat templates to place the Public VIP on the External network.

When deploying an Overcloud, the director placed the Public VIP services on the Provisioning network's "ctlplane". This meant you could not reach the horizon and keystone services from outside of the Overcloud. This fix patches the Heat templates to place the Public VIP on the External network.

When deploying an Overcloud, the director placed the Public VIP services on the Provisioning network's "ctlplane". This meant you could not reach the horizon and keystone services from outside of the Overcloud. This fix patches the Heat templates to place the Public VIP on the External network.

Previously, in cases when ironic-discoverd submitted a 'set_boot_device' request with the same boot device already configured on the node, the DRAC driver in OpenStack Bare Metal Provisioning (ironic) tried to commit a configuration job against BIOS without any change, resulting in a failed deployment.

With this update, the DRAC driver in OpenStack Bare Metal Provisioning ignores requests where the target boot device is the same as the current one. As a result, the deployment succeeds.

Previously, in cases when ironic-discoverd submitted a 'set_boot_device' request with the same boot device already configured on the node, the DRAC driver in OpenStack Bare Metal Provisioning (ironic) tried to commit a configuration job against BIOS without any change, resulting in a failed deployment.

With this update, the DRAC driver in OpenStack Bare Metal Provisioning ignores requests where the target boot device is the same as the current one. As a result, the deployment succeeds.

Previously, the keystone token expired while Orchestration worked to deploy the Overcloud, resulting in the deployment failing with an authentication error.

With this release, the token timeout has been increased, resulting in the successful deployment of the Overcloud.

Previously, the keystone token expired while Orchestration worked to deploy the Overcloud, resulting in the deployment failing with an authentication error.

With this release, the token timeout has been increased, resulting in the successful deployment of the Overcloud.

The default route was not set on the External network. This meant you could only access Horizon and the Public API from the same subnet as the Controller. This fix updates the Heat templates to include the ExternalInterfaceDefaultRoute parameter. This ensures a default route is available on the External interface.

The default route was not set on the External network. This meant you could only access Horizon and the Public API from the same subnet as the Controller. This fix updates the Heat templates to include the ExternalInterfaceDefaultRoute parameter. This ensures a default route is available on the External interface.

The NeutronScale resource renamed neutron agents on Controller nodes. This caused an inconsistency with the "neutron agent-list" and as result Neutron reported errors of not having enough L3 agents for L3 HA. This fix removes the NeutronScale resource from Overcloud Heat templates and plans. NeutronScale does not appear in "neutron agent-list" and Neutron reports no errors.

The NeutronScale resource renamed neutron agents on Controller nodes. This caused an inconsistency with the "neutron agent-list" and as result Neutron reported errors of not having enough L3 agents for L3 HA. This fix removes the NeutronScale resource from Overcloud Heat templates and plans. NeutronScale does not appear in "neutron agent-list" and Neutron reports no errors.

Previously, the undercloud admin user did not have a 'swiftoperator' role on the service tenant. As a result, it was not possible for CloudForms Management Engine (CFME), which uses the admin user to access the swift objects.

With this update, the undercloud admin user is given the 'swiftoperator' role on the service tenant, thus, allowing the admin user access to the swift objects by specifying the service tenant in the API request.

Previously, the undercloud admin user did not have a 'swiftoperator' role on the service tenant. As a result, it was not possible for CloudForms Management Engine (CFME), which uses the admin user to access the swift objects.

With this update, the undercloud admin user is given the 'swiftoperator' role on the service tenant, thus, allowing the admin user access to the swift objects by specifying the service tenant in the API request.

The NeutronScale resource renamed neutron agents on Controller nodes. This caused an inconsistency with the "neutron agent-list" and as result Neutron reported errors of not having enough L3 agents for L3 HA. This fix removes the NeutronScale resource from Overcloud Heat templates and plans. NeutronScale does not appear in "neutron agent-list" and Neutron reports no errors.

The NeutronScale resource renamed neutron agents on Controller nodes. This caused an inconsistency with the "neutron agent-list" and as result Neutron reported errors of not having enough L3 agents for L3 HA. This fix removes the NeutronScale resource from Overcloud Heat templates and plans. NeutronScale does not appear in "neutron agent-list" and Neutron reports no errors.

With this release, a new enhancement adds NFS backend for the Block Storage service to provide a greater variety of possible Block Storage backends.

As a result, Overcloud Block Storage service can be configured with a NFS backend with the following parameters:

* CinderEnableNfsBackend
* CinderNfsMountOptions
* CinderNfsServers

With this release, a new enhancement adds NFS backend for the Block Storage service to provide a greater variety of possible Block Storage backends.

As a result, Overcloud Block Storage service can be configured with a NFS backend with the following parameters:

* CinderEnableNfsBackend
* CinderNfsMountOptions
* CinderNfsServers

The glance backend was hard coded to use swift. This meant you could not use other file system types, such as NFS, for glance. This release adds a new enhancement that provides a NFS backend for glance. You can now configure the Overcloud's glance service an NFS backend using the following parameters:

* GlanceBackend
* GlanceFilePcmkManage
* GlanceFilePcmkDevice
* GlanceFilePcmkOptions

The glance backend was hard coded to use swift. This meant you could not use other file system types, such as NFS, for glance. This release adds a new enhancement that provides a NFS backend for glance. You can now configure the Overcloud's glance service an NFS backend using the following parameters:

* GlanceBackend
* GlanceFilePcmkManage
* GlanceFilePcmkDevice
* GlanceFilePcmkOptions

The OpenStack Dashboard (Horizon) is now a part of the high availability architecture. The Dashboard is now a resource that Pacemaker manages.

The OpenStack Dashboard (Horizon) is now a part of the high availability architecture. The Dashboard is now a resource that Pacemaker manages.

Pacemaker and ironic fought for control over power management, which caused issues with fencing. This fix sets force_power_state_during_sync=False in /etc/ironic/ironic.conf by default. This stops ironic automatically restoring the power state of the node during its synchronization. Pacemaker can now successfully fence the node.

Pacemaker and ironic fought for control over power management, which caused issues with fencing. This fix sets force_power_state_during_sync=False in /etc/ironic/ironic.conf by default. This stops ironic automatically restoring the power state of the node during its synchronization. Pacemaker can now successfully fence the node.

The lack of a CLI parameter to set NeutronExternalNetworkBridge caused problems when assigning floating IPs. This means the only way to set this parameter is through custom environment file for network isolation. For example:

parameter_defaults:
  # Set to "br-ex" if External is on native VLAN
  NeutronExternalNetworkBridge: "''"


Set this parameters to '' if the floating IP network is on a VLAN and to 'br-ex' if on a native VLAN on the br-ex bridge. This configuration allows the Neutron bridge mapping to work correctly for the environment. This is documented in the Red Hat Enterprise Linux OpenStack Platform 7 Director Installation and Usage guide

The lack of a CLI parameter to set NeutronExternalNetworkBridge caused problems when assigning floating IPs. This means the only way to set this parameter is through custom environment file for network isolation. For example:

parameter_defaults:
  # Set to "br-ex" if External is on native VLAN
  NeutronExternalNetworkBridge: "''"


Set this parameters to '' if the floating IP network is on a VLAN and to 'br-ex' if on a native VLAN on the br-ex bridge. This configuration allows the Neutron bridge mapping to work correctly for the environment. This is documented in the Red Hat Enterprise Linux OpenStack Platform 7 Director Installation and Usage guide

The ipxe-bootimgs package was unavailable in the default Red Hat Enterprise Linux repository. It was only available in the Red Hat Enterprise Linux - Optional repository. This caused deployments without the Optional channel to fail. This fix adds this package to the director channel. Deployments now work without the Optional channel enabled.

The ipxe-bootimgs package was unavailable in the default Red Hat Enterprise Linux repository. It was only available in the Red Hat Enterprise Linux - Optional repository. This caused deployments without the Optional channel to fail. This fix adds this package to the director channel. Deployments now work without the Optional channel enabled.

The NeutronScale resource renamed neutron agents on Controller nodes. This caused an inconsistency with the "neutron agent-list" and as result Neutron reported errors of not having enough L3 agents for L3 HA. This fix removes the NeutronScale resource from Overcloud Heat templates and plans. NeutronScale does not appear in "neutron agent-list" and Neutron reports no errors.

The NeutronScale resource renamed neutron agents on Controller nodes. This caused an inconsistency with the "neutron agent-list" and as result Neutron reported errors of not having enough L3 agents for L3 HA. This fix removes the NeutronScale resource from Overcloud Heat templates and plans. NeutronScale does not appear in "neutron agent-list" and Neutron reports no errors.

The Overcloud's configured its Heat component incorrectly and lacked settings for heat_stack_user_role, stack_domain_admin, and stack_domain_admin_password. This fix correctly sets the user and admin roles in /etc/heat/heat.conf.

The Overcloud's configured its Heat component incorrectly and lacked settings for heat_stack_user_role, stack_domain_admin, and stack_domain_admin_password. This fix correctly sets the user and admin roles in /etc/heat/heat.conf.

Deployed Overclouds configured the Heat CloudFormation API to use an auth_url pointing at localhost. However, Keystone does not listen on localhost. This caused an unusable Heat CloudFormation API. This fix changes the auth_url option in /etc/heat/heat.conf to the IP address where Keystone is listening on the Internal API network. The Heat CloudFormation API now functions correctly.

Deployed Overclouds configured the Heat CloudFormation API to use an auth_url pointing at localhost. However, Keystone does not listen on localhost. This caused an unusable Heat CloudFormation API. This fix changes the auth_url option in /etc/heat/heat.conf to the IP address where Keystone is listening on the Internal API network. The Heat CloudFormation API now functions correctly.

The Overcloud configured the heat service with instance_user=heat-admin. This meant SSH communication into heat-provisioned guest VMs required the heat-admin user. This fix sets instance_user to an empty value. Now you can SSH into guest VMs using the default image user.

The Overcloud configured the heat service with instance_user=heat-admin. This meant SSH communication into heat-provisioned guest VMs required the heat-admin user. This fix sets instance_user to an empty value. Now you can SSH into guest VMs using the default image user.

The number of connections to the database scaled depending on the number of Controllers and the cores of each Controller. In HA scenarios with three controllers where each has more than 12 cores, the database connections could  reach the default max_connections value set to 1024. This caused services to not respond to requests. As a workaround, increase the max_connections limit with the following command:

$ openstack management plan set [tuskar_plan_uuid] -P "Controller-1::MysqlMaxConnections=4096"

Replace [tuskar_plan_uuid] with the actual plan UUID, which you can find with:

$ openstack management plan list

To increase the max_connections value when deploying with the --templates argument, provide to the deploy command an additional customization environment file containing the following:

parameters:
  MysqlMaxConnections: 4096

Add it to the deploy command with:

$ openstack management deploy --plan overcloud -e /path/to/custom_environment_file.yaml

The number of connections to the database scaled depending on the number of Controllers and the cores of each Controller. In HA scenarios with three controllers where each has more than 12 cores, the database connections could  reach the default max_connections value set to 1024. This caused services to not respond to requests. As a workaround, increase the max_connections limit with the following command:

$ openstack management plan set [tuskar_plan_uuid] -P "Controller-1::MysqlMaxConnections=4096"

Replace [tuskar_plan_uuid] with the actual plan UUID, which you can find with:

$ openstack management plan list

To increase the max_connections value when deploying with the --templates argument, provide to the deploy command an additional customization environment file containing the following:

parameters:
  MysqlMaxConnections: 4096

Add it to the deploy command with:

$ openstack management deploy --plan overcloud -e /path/to/custom_environment_file.yaml

Nodes would end up out of synchronization due to a lack of access to NTP servers. This was because not all nodes routed access to the required servers (NTP, DNS, etc). This fix sets the Undercloud as a gateway for non-Controller nodes. This provides non-Controller nodes with access to external services such as DNS and NTP, which aids synchronization.

Nodes would end up out of synchronization due to a lack of access to NTP servers. This was because not all nodes routed access to the required servers (NTP, DNS, etc). This fix sets the Undercloud as a gateway for non-Controller nodes. This provides non-Controller nodes with access to external services such as DNS and NTP, which aids synchronization.

SELinux was set to enforcing mode on Ceph OSD nodes. However, according to official Ceph documentation, SELinux should be set to permissive mode on Ceph OSD nodes. This fix sets SELinux to permissive on Ceph OSD nodes.

SELinux was set to enforcing mode on Ceph OSD nodes. However, according to official Ceph documentation, SELinux should be set to permissive mode on Ceph OSD nodes. This fix sets SELinux to permissive on Ceph OSD nodes.

The timeout for Pacemaker service start-up was 20 seconds. Sometimes start-up exceeded this time limit and caused hung deployments. This fix increases the timeout to 60 second. Pacemaker services now start correctly and the deployment completes.

The timeout for Pacemaker service start-up was 20 seconds. Sometimes start-up exceeded this time limit and caused hung deployments. This fix increases the timeout to 60 second. Pacemaker services now start correctly and the deployment completes.