3.2. Red Hat OpenStack Platform 12 Maintenance Release January 2018

There is currently a known issue where you cannot use ACLs to make a container public for anonymous access. This issue arises when sending `POST` operations to Swift that specify a '*' value in the `X-Container-Read` or `X-Container-Write` settings.

There is currently a known issue where you cannot use ACLs to make a container public for anonymous access. This issue arises when sending `POST` operations to Swift that specify a '*' value in the `X-Container-Read` or `X-Container-Write` settings.

When using the Docker CLI to report the state of running containers, the nova_migration_target container might be incorrectly reported as "unhealthy". This is due to an issue with the health check itself, and not with an accurate reflection of the state of the running container.

When using the Docker CLI to report the state of running containers, the nova_migration_target container might be incorrectly reported as "unhealthy". This is due to an issue with the health check itself, and not with an accurate reflection of the state of the running container.

There is currently a known issue with LDAP integration for Red Hat OpenStack Platform. At present, the `keystone_domain_confg` tag is missing from `keystone.yaml`, preventing Puppet from properly applying the required configuration files. Consequently, LDAP integration with Red Hat OpenStack Platform will not be properly configured. As a workaround, you will need to manually edit `keystone.yaml` and add the missing tag. There are two ways to do this:

1. Edit the the file directly:
  a. Log into the undercloud as the stack user.
  b. Open the keystone.yaml in the editor of your choice. For example:
       `sudo vi /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml`
  c. Append the missing puppet tag, `keystone_domain_confg`, to line 94. For example:
      `puppet_tags: keystone_config`
        Changes to:
      `puppet_tags: keystone_config,keystone_domain_confg`
  d. Save and close `keystone.yaml`.
  e. Verify you see the missing tag in the `keystone.yaml` file. The following command should return '1':
    `cat /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml | grep 'puppet_tags: keystone_config,keystone_domain_config' | wc -l`

2. Or, use sed to edit the file inline:
  a. Login to the undercloud as the stack user.
  b. Run the following command to add the missing puppet tag:
     `sed -i 's/puppet_tags\: keystone_config/puppet_tags\: keystone_config,keystone_domain_config/' /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml`
  c. Verify you see the missing tag in the keystone.yaml file The following command should return '1':
    `cat /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml | grep 'puppet_tags: keystone_config,keystone_domain_config' | wc -l`

There is currently a known issue with LDAP integration for Red Hat OpenStack Platform. At present, the `keystone_domain_confg` tag is missing from `keystone.yaml`, preventing Puppet from properly applying the required configuration files. Consequently, LDAP integration with Red Hat OpenStack Platform will not be properly configured. As a workaround, you will need to manually edit `keystone.yaml` and add the missing tag. There are two ways to do this:

1. Edit the the file directly:
  a. Log into the undercloud as the stack user.
  b. Open the keystone.yaml in the editor of your choice. For example:
       `sudo vi /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml`
  c. Append the missing puppet tag, `keystone_domain_confg`, to line 94. For example:
      `puppet_tags: keystone_config`
        Changes to:
      `puppet_tags: keystone_config,keystone_domain_confg`
  d. Save and close `keystone.yaml`.
  e. Verify you see the missing tag in the `keystone.yaml` file. The following command should return '1':
    `cat /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml | grep 'puppet_tags: keystone_config,keystone_domain_config' | wc -l`

2. Or, use sed to edit the file inline:
  a. Login to the undercloud as the stack user.
  b. Run the following command to add the missing puppet tag:
     `sed -i 's/puppet_tags\: keystone_config/puppet_tags\: keystone_config,keystone_domain_config/' /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml`
  c. Verify you see the missing tag in the keystone.yaml file The following command should return '1':
    `cat /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml | grep 'puppet_tags: keystone_config,keystone_domain_config' | wc -l`

It is only possible to deploy Ceph storage servers if their disk devices are homogeneous.

It is only possible to deploy Ceph storage servers if their disk devices are homogeneous.

For deployments using OVN as the ML2 mechanism driver, only nodes with connectivity to the external networks are eligible to schedule the router gateway ports on them. However, there is a known issue that marks all nodes as eligible, which becomes a problem when the Compute nodes do not have external connectivity. 

As a result, if a router gateway port is scheduled on Compute nodes without external connectivity, ingress and egress connections for the external networks will not work; in which case the router gateway port has to be rescheduled to a controller node. 

As a workaround, you can provide connectivity on all your compute nodes, or you can consider deleting NeutronBridgeMappings, or set it to datacentre:br-ex. For more information, see https://bugzilla.redhat.com/show_bug.cgi?id=1525520 and https://bugzilla.redhat.com/show_bug.cgi?id=1510879.

For deployments using OVN as the ML2 mechanism driver, only nodes with connectivity to the external networks are eligible to schedule the router gateway ports on them. However, there is a known issue that marks all nodes as eligible, which becomes a problem when the Compute nodes do not have external connectivity. 

As a result, if a router gateway port is scheduled on Compute nodes without external connectivity, ingress and egress connections for the external networks will not work; in which case the router gateway port has to be rescheduled to a controller node. 

As a workaround, you can provide connectivity on all your compute nodes, or you can consider deleting NeutronBridgeMappings, or set it to datacentre:br-ex. For more information, see https://bugzilla.redhat.com/show_bug.cgi?id=1525520 and https://bugzilla.redhat.com/show_bug.cgi?id=1510879.