6.4. RHSA-2015:2650 — Moderate: Red Hat Enterprise Linux OpenStack Platform 7 director update

Heat templates lacked the *RemovalPolicies parameters. This meant it was not possible to delete specific nodes when using Heat templates  directly (i.e. not through Tuskar). This update adds the *RemovalPolicies parameters. Now a user can specify particular nodes to remove by setting the *RemovalPolicies parameters.

Heat templates lacked the *RemovalPolicies parameters. This meant it was not possible to delete specific nodes when using Heat templates  directly (i.e. not through Tuskar). This update adds the *RemovalPolicies parameters. Now a user can specify particular nodes to remove by setting the *RemovalPolicies parameters.

Previously, orphaned OpenStack Networking L3 agent keepalived processes were left running by OpenStack Networking's netns-cleanup script. As a result, the OpenStack Networking tenant router failover did not work during the controller node update in the overcloud.

With this update, keepalived processes are cleaned up properly during the controller node update. As a result, OpenStack Networking tenant router failover works normally and the high availability of the tenant network is preserved.

Previously, orphaned OpenStack Networking L3 agent keepalived processes were left running by OpenStack Networking's netns-cleanup script. As a result, the OpenStack Networking tenant router failover did not work during the controller node update in the overcloud.

With this update, keepalived processes are cleaned up properly during the controller node update. As a result, OpenStack Networking tenant router failover works normally and the high availability of the tenant network is preserved.

Previously, during the initial Overcloud deployment, there existed a race condition between the puppet trying to stop the neutron-server and the Pacemaker trying to start the neutron-server. The neutron-server would often be left stopped on the Overcloud controllers, even though the deployment indicated it was successful. This was because the request to stop neutron-server eventually succeeded, although it would be not reported to Orchestration.

With this update, the puppet manifest is fixed to only conditionally stop the neutron-server if the Pacemaker is not already managing the neutron-server resource. As a result, the initial deployments succeed and the neutron-server is running in the Overcloud.

Previously, during the initial Overcloud deployment, there existed a race condition between the puppet trying to stop the neutron-server and the Pacemaker trying to start the neutron-server. The neutron-server would often be left stopped on the Overcloud controllers, even though the deployment indicated it was successful. This was because the request to stop neutron-server eventually succeeded, although it would be not reported to Orchestration.

With this update, the puppet manifest is fixed to only conditionally stop the neutron-server if the Pacemaker is not already managing the neutron-server resource. As a result, the initial deployments succeed and the neutron-server is running in the Overcloud.

Previously, hard-coded parameters were being passed directly to Orchestration. As a result, the parameters could not be overridden properly.

With this update, a custom environment file from the parameters collected is generated and pass as 'parameter_defaults', allowing parameters to be overridden.

Previously, hard-coded parameters were being passed directly to Orchestration. As a result, the parameters could not be overridden properly.

With this update, a custom environment file from the parameters collected is generated and pass as 'parameter_defaults', allowing parameters to be overridden.

Previously, the 'debug' parameter was enabled and hard-coded in the overcloud deployment code and there was no way to disable the debug mode by an user.

With this update, the 'debug' parameter is removed from the default hard-coded parameters in the overcloud deployment code. As a result, the user can now control debug move in the environment file used to deploy the overcloud.

Previously, the 'debug' parameter was enabled and hard-coded in the overcloud deployment code and there was no way to disable the debug mode by an user.

With this update, the 'debug' parameter is removed from the default hard-coded parameters in the overcloud deployment code. As a result, the user can now control debug move in the environment file used to deploy the overcloud.

This update removes an incorrect warning when deploying the Red Hat Enterprise Linux OpenStack Platform director.

This update removes an incorrect warning when deploying the Red Hat Enterprise Linux OpenStack Platform director.

Previously, while checking the node configuration deployment validation checked for all Ironic nodes, including those in the maintenance mode.

With this update, the nodes in maintenance mode are skipped by the validation step as they cannot be deployed.

Previously, while checking the node configuration deployment validation checked for all Ironic nodes, including those in the maintenance mode.

With this update, the nodes in maintenance mode are skipped by the validation step as they cannot be deployed.

Previously, the 'tempest-deployer-input.conf' file contained incorrect stack_owner_role. So using the 'tempest-deployer-input.conf' file for post-install validation caused more Tempest test failures.

With this update, the value in the 'tempest-deployer-input.conf' file generated during deployment is changed. As a result, less number of Tempest tests will fail during post-install validation.

Previously, the 'tempest-deployer-input.conf' file contained incorrect stack_owner_role. So using the 'tempest-deployer-input.conf' file for post-install validation caused more Tempest test failures.

With this update, the value in the 'tempest-deployer-input.conf' file generated during deployment is changed. As a result, less number of Tempest tests will fail during post-install validation.

Previously, breakpoints were not removed when an update operation failed. If a user ran the "openstack overcloud update" command and it failed, it is possible that the subsequent stack-update command (e.g. "openstack overcloud deploy") might be stuck in the 'IN_PROGRESS' state waiting for the removal of breakpoints.

With this update, all existing CLI commands explicitly remove any existing breakpoints when running a stack-update operation. As a result, the stack-update operations do not get stuck in the 'IN_PROGRESS' state while waiting for the breakpoint removal.

Previously, breakpoints were not removed when an update operation failed. If a user ran the "openstack overcloud update" command and it failed, it is possible that the subsequent stack-update command (e.g. "openstack overcloud deploy") might be stuck in the 'IN_PROGRESS' state waiting for the removal of breakpoints.

With this update, all existing CLI commands explicitly remove any existing breakpoints when running a stack-update operation. As a result, the stack-update operations do not get stuck in the 'IN_PROGRESS' state while waiting for the breakpoint removal.

Previously, the base resource registry environment was included for all overcloud stack updates, which meant customizations may be lost unless all environment files are repeated in order when calling "openstack overcloud deploy".

With this update, it is possible to call "openstack overcloud deploy" with no environments without losing customizations. If any environment files are specified, then all environment files must be specified again in the desired order.

Previously, the base resource registry environment was included for all overcloud stack updates, which meant customizations may be lost unless all environment files are repeated in order when calling "openstack overcloud deploy".

With this update, it is possible to call "openstack overcloud deploy" with no environments without losing customizations. If any environment files are specified, then all environment files must be specified again in the desired order.

Previously the base resource registry environment was included for all overcloud stack updates, which meant customizations may be lost unless all environment files are repeated in order when calling "openstack overcloud deploy".

With this update, it is possible to call "openstack overcloud deploy" with no environments without losing customizations. If any environment files are specified, then all environment files must be specified again in the desired order.

Previously the base resource registry environment was included for all overcloud stack updates, which meant customizations may be lost unless all environment files are repeated in order when calling "openstack overcloud deploy".

With this update, it is possible to call "openstack overcloud deploy" with no environments without losing customizations. If any environment files are specified, then all environment files must be specified again in the desired order.

Previously, when scaling out the Compute nodes in the Overcloud after an update was performed, the default UpdateIdentifier parameter in the Heat stack caused the new Compute node to attempt an update as soon as it was coming up. Since the yum repositories were not configured on the new Compute nodes yet, it would cause the update to fail, which in turn caused the scale out to fail.

With this update, the client, python-rdomanager-oscplugin, does not clear the UpdateIdentifier parameter  on the subsequent stack-update attempts (including the scale out) until after the initial update has been completed. As a result, scale out attempts after the update now succeeds.

Previously, when scaling out the Compute nodes in the Overcloud after an update was performed, the default UpdateIdentifier parameter in the Heat stack caused the new Compute node to attempt an update as soon as it was coming up. Since the yum repositories were not configured on the new Compute nodes yet, it would cause the update to fail, which in turn caused the scale out to fail.

With this update, the client, python-rdomanager-oscplugin, does not clear the UpdateIdentifier parameter  on the subsequent stack-update attempts (including the scale out) until after the initial update has been completed. As a result, scale out attempts after the update now succeeds.

Previously, a Pacemaker constraint between the neutron-server and the neutron-ovs-cleanup processes meant that the over-cleanup restarted whenever the neutron-server did. The clearup by the ovs-cleanup (and associated netns-cleanup) should only occur when a node was being evacuated or rebooted and not for a neutron-server restart. As a result of this constraint, the neutron-server needed long startup to rebuild the data plane and ultimately caused issues for the dependent DHCP and L3 agents.

With this update, the constraint between the neutron-server and the ovs-cleanup/netns-cleanup was removed. This means that the ovs-cleanup/net-ns cleanup does not re-run after neutron-server is restarted (for example, because haproxy was). The result is the two constraints chains for OpenStack Networking: ovs-cleanup-->netns-cleanup-->openvswitch-agent, and then neutron-server-->openvswitch-agent-->dhcp-agent-->l3-agent-->metadata-agent. As a result, when haproxy is restarted or when neutron-server is, more specifically, the ovs and netns cleanup scripts will not be re-run, so the OpenStack Networking service startup will proceed normally.

Previously, a Pacemaker constraint between the neutron-server and the neutron-ovs-cleanup processes meant that the over-cleanup restarted whenever the neutron-server did. The clearup by the ovs-cleanup (and associated netns-cleanup) should only occur when a node was being evacuated or rebooted and not for a neutron-server restart. As a result of this constraint, the neutron-server needed long startup to rebuild the data plane and ultimately caused issues for the dependent DHCP and L3 agents.

With this update, the constraint between the neutron-server and the ovs-cleanup/netns-cleanup was removed. This means that the ovs-cleanup/net-ns cleanup does not re-run after neutron-server is restarted (for example, because haproxy was). The result is the two constraints chains for OpenStack Networking: ovs-cleanup-->netns-cleanup-->openvswitch-agent, and then neutron-server-->openvswitch-agent-->dhcp-agent-->l3-agent-->metadata-agent. As a result, when haproxy is restarted or when neutron-server is, more specifically, the ovs and netns cleanup scripts will not be re-run, so the OpenStack Networking service startup will proceed normally.

With this update, the default network where the 'KeystoneAdminVip' is placed was changed from 'InternalApi' to 'ctlplane' so that the post-deployment Identity service initialization step could be carried by the Undercloud over the 'ctlplane' network. Relocating the 'KeystoneAdminVip' causes a cascading restart of the services pointing to the old 'KeystoneAdminVip'.

As a workaround to make sure the KeystoneAdminVip remains on the 'InternalApi' network, a customized 'ServiceNetMap' must be provided as deployment parameter when launching an update from the 7.0 release. A sample Orchestration environment file passing a customized 'ServiceNetMap' is as follows:


parameters:
  ServiceNetMap:
    NeutronTenantNetwork: tenant
    CeilometerApiNetwork: internal_api
    MongoDbNetwork: internal_api
    CinderApiNetwork: internal_api
    CinderIscsiNetwork: storage
    GlanceApiNetwork: storage
    GlanceRegistryNetwork: internal_api
    KeystoneAdminApiNetwork: internal_api
    KeystonePublicApiNetwork: internal_api
    NeutronApiNetwork: internal_api
    HeatApiNetwork: internal_api
    NovaApiNetwork: internal_api
    NovaMetadataNetwork: internal_api
    NovaVncProxyNetwork: internal_api
    SwiftMgmtNetwork: storage_mgmt
    SwiftProxyNetwork: storage
    HorizonNetwork: internal_api
    MemcachedNetwork: internal_api
    RabbitMqNetwork: internal_api
    RedisNetwork: internal_api
    MysqlNetwork: internal_api
    CephClusterNetwork: storage_mgmt
    CephPublicNetwork: storage
    ControllerHostnameResolveNetwork: internal_api
    ComputeHostnameResolveNetwork: internal_api
    BlockStorageHostnameResolveNetwork: internal_api
    ObjectStorageHostnameResolveNetwork: internal_api
    CephStorageHostnameResolveNetwork: storage

If any additional binding network from the above has been customized then that setting has to be preserved as well.

As a result of the workaround changes, the 'KeystoneAdminVip' is not relocated on the 'ctlplane' network so that no services restart needs to be triggered.

With this update, the default network where the 'KeystoneAdminVip' is placed was changed from 'InternalApi' to 'ctlplane' so that the post-deployment Identity service initialization step could be carried by the Undercloud over the 'ctlplane' network. Relocating the 'KeystoneAdminVip' causes a cascading restart of the services pointing to the old 'KeystoneAdminVip'.

As a workaround to make sure the KeystoneAdminVip remains on the 'InternalApi' network, a customized 'ServiceNetMap' must be provided as deployment parameter when launching an update from the 7.0 release. A sample Orchestration environment file passing a customized 'ServiceNetMap' is as follows:


parameters:
  ServiceNetMap:
    NeutronTenantNetwork: tenant
    CeilometerApiNetwork: internal_api
    MongoDbNetwork: internal_api
    CinderApiNetwork: internal_api
    CinderIscsiNetwork: storage
    GlanceApiNetwork: storage
    GlanceRegistryNetwork: internal_api
    KeystoneAdminApiNetwork: internal_api
    KeystonePublicApiNetwork: internal_api
    NeutronApiNetwork: internal_api
    HeatApiNetwork: internal_api
    NovaApiNetwork: internal_api
    NovaMetadataNetwork: internal_api
    NovaVncProxyNetwork: internal_api
    SwiftMgmtNetwork: storage_mgmt
    SwiftProxyNetwork: storage
    HorizonNetwork: internal_api
    MemcachedNetwork: internal_api
    RabbitMqNetwork: internal_api
    RedisNetwork: internal_api
    MysqlNetwork: internal_api
    CephClusterNetwork: storage_mgmt
    CephPublicNetwork: storage
    ControllerHostnameResolveNetwork: internal_api
    ComputeHostnameResolveNetwork: internal_api
    BlockStorageHostnameResolveNetwork: internal_api
    ObjectStorageHostnameResolveNetwork: internal_api
    CephStorageHostnameResolveNetwork: storage

If any additional binding network from the above has been customized then that setting has to be preserved as well.

As a result of the workaround changes, the 'KeystoneAdminVip' is not relocated on the 'ctlplane' network so that no services restart needs to be triggered.

It was discovered that Director's NeutronMetadataProxySharedSecret parameter remained specified at the default value of 'unset'. This value is used by OpenStack Networking to sign instance headers; if unchanged, an attacker knowing the shared secret could use this flaw to spoof OpenStack Networking metadata requests.

It was discovered that Director's NeutronMetadataProxySharedSecret parameter remained specified at the default value of 'unset'. This value is used by OpenStack Networking to sign instance headers; if unchanged, an attacker knowing the shared secret could use this flaw to spoof OpenStack Networking metadata requests.

A flaw was found in the director (openstack-tripleo-heat-templates) where the RabbitMQ credentials defaulted to guest/guest and supplied values in the configuration were not used. As a result, all deployed overclouds used the same credentials (guest/guest). A remote non-authenticated attacker could use this flaw to access RabbitMQ services in the deployed cloud.

A flaw was found in the director (openstack-tripleo-heat-templates) where the RabbitMQ credentials defaulted to guest/guest and supplied values in the configuration were not used. As a result, all deployed overclouds used the same credentials (guest/guest). A remote non-authenticated attacker could use this flaw to access RabbitMQ services in the deployed cloud.