4장. 기술 노트
4.1. RHEA-2016:0603 - Red Hat OpenStack Platform 8 기능 개선 권고 링크 복사링크가 클립보드에 복사되었습니다!
diskimage-builder
- BZ#1307001
The diskimage-builder package has been upgraded to upstream version 1.10.0, which provides a number of bug fixes and enhancements over the previous version. Notably, the python-devel package is no longer removed by default, as it previously caused other packages to be removed as well.
The diskimage-builder package has been upgraded to upstream version 1.10.0, which provides a number of bug fixes and enhancements over the previous version. Notably, the python-devel package is no longer removed by default, as it previously caused other packages to be removed as well.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Memcached
- BZ#1299075
Previously, memcached was unable to bind IPv6 addresses, resulting in memcached failing to start in IPv6 environments. This update addresses this issue, with memcached-1.4.15-9.1.el7ost now IPv6-enabled.
Previously, memcached was unable to bind IPv6 addresses, resulting in memcached failing to start in IPv6 environments. This update addresses this issue, with memcached-1.4.15-9.1.el7ost now IPv6-enabled.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
mongodb
- BZ#1308855
This rebase package adds improved performance for range queries. Specifically, queries that used the `$or` operator were previously affected with the 2.4 release. Those regressions are now fixed in 2.6
This rebase package adds improved performance for range queries. Specifically, queries that used the `$or` operator were previously affected with the 2.4 release. Those regressions are now fixed in 2.6
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
openstack-cinder
- BZ#1272572
Previously, a bug in the Block Storage component caused it to be incompatible with the Identity API v2 when working with quotas, resulting in failures when managing information on quotas in Block Storage. With this update, Block Storage has now been updated to be compatible with the Identity API v2, and the dashboard can now correctly retrieve information on volume quotas.
Previously, a bug in the Block Storage component caused it to be incompatible with the Identity API v2 when working with quotas, resulting in failures when managing information on quotas in Block Storage. With this update, Block Storage has now been updated to be compatible with the Identity API v2, and the dashboard can now correctly retrieve information on volume quotas.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1295576
Previously, a bug in the cinder API server quota code used `encryption_auth_url` when it should have used `auth_uri`. Consequently, cinder failed to talk to keystone when querying quota information, causing the client to receive HTTP 500 errors from cinder. This issue has been resolved in 7.0.1. Fix: Fixed in Cinder API service in 7.0.1, resulting in expected behavior of the cinder quota commands.
Previously, a bug in the cinder API server quota code used `encryption_auth_url` when it should have used `auth_uri`. Consequently, cinder failed to talk to keystone when querying quota information, causing the client to receive HTTP 500 errors from cinder. This issue has been resolved in 7.0.1. Fix: Fixed in Cinder API service in 7.0.1, resulting in expected behavior of the cinder quota commands.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1262106
This enhancement enables backup of Block Storage (cinder) volumes to a Ceph object store using the same user interface as that for backing up cinder volumes to Object Storage (swift). This was done to avoid the need for a second object store if Ceph was already being used.
This enhancement enables backup of Block Storage (cinder) volumes to a Ceph object store using the same user interface as that for backing up cinder volumes to Object Storage (swift). This was done to avoid the need for a second object store if Ceph was already being used.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1179445
Previously, when Ceph was used as the backing store for Block Storage (cinder), operations such as deleting or flattening a large volume may have blocked other driver threads. Consequently, deleting and flattening threads may have prevented cinder from doing other work until they completed. This fix changes the delete and flattening threads to run in a sub-process, rather than as green threads in the same process. As a result, delete and flattening operations are run in the background so that other cinder operations (such as volume creates and attaches) can run concurrently.
Previously, when Ceph was used as the backing store for Block Storage (cinder), operations such as deleting or flattening a large volume may have blocked other driver threads. Consequently, deleting and flattening threads may have prevented cinder from doing other work until they completed. This fix changes the delete and flattening threads to run in a sub-process, rather than as green threads in the same process. As a result, delete and flattening operations are run in the background so that other cinder operations (such as volume creates and attaches) can run concurrently.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1192641
With this release, in order to provide security isolation, the '/usr/local' path has been removed from the default Block Storage rootwrap configuration. As a result, the deployments relying on Block Storage service executing commands from the '/usr/local/' as the 'root' user will need to add configuration for the commands to work.
With this release, in order to provide security isolation, the '/usr/local' path has been removed from the default Block Storage rootwrap configuration. As a result, the deployments relying on Block Storage service executing commands from the '/usr/local/' as the 'root' user will need to add configuration for the commands to work.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1258645
This enhancement adds a new scaled backend replication implementation (between backends) that leaves the bulk of the work up to the driver, while providing basic admin API methods. This is available where replication is set at the volume types level, and when the cinder driver reports its capabilities. New configuration options are available: replication_enabled - set to True replication_type - async, sync replication_count - Number of replicas
This enhancement adds a new scaled backend replication implementation (between backends) that leaves the bulk of the work up to the driver, while providing basic admin API methods. This is available where replication is set at the volume types level, and when the cinder driver reports its capabilities. New configuration options are available: replication_enabled - set to True replication_type - async, sync replication_count - Number of replicas
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1258643
To provide better flexibility for administrators on deployments with an assortment of storage backends, Block Storage now defines standard names for the capabilities, for example, QoS, compression, replication, bandwidth control, and thin provisioning. This means volume type specifications that will work with multiple drivers without modifications can be defined.
To provide better flexibility for administrators on deployments with an assortment of storage backends, Block Storage now defines standard names for the capabilities, for example, QoS, compression, replication, bandwidth control, and thin provisioning. This means volume type specifications that will work with multiple drivers without modifications can be defined.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1267951
This update introduces nested quotas. Deployers now have the ability to manage a hierarchy of quotas in Cinder, with subprojects that inherit from parent projects.
This update introduces nested quotas. Deployers now have the ability to manage a hierarchy of quotas in Cinder, with subprojects that inherit from parent projects.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
openstack-glance
- BZ#1167565
This update adds a common API hosted by the Image Service (glance) for vendors, admins, services, and users to meaningfully define an available key/value pair, and tag metadata. The intent is to enable better metadata collaboration across artifacts, services, and projects for OpenStack users. This definition describes the available metadata that can be used on different types of resources (images, artifacts, volumes, flavors, aggregates, among others). A definition includes the properties type, key, description, and constraints. This catalog will not store the values for specific instance properties. For example, a definition of a virtual CPU topology property for a number of cores will include the key to use, a description, and value constraints, such as requiring it to be an integer. As a result, users (potentially through the dashboard) would be able to search this catalog to list the available properties they can add to a flavor or image. They will see the virtual CPU topology property in the list and know that it must be an integer. In the dashboard example, when the user adds the property, its key and value will be stored in the service that owns that resource (in nova for flavors, and in glance for images).
This update adds a common API hosted by the Image Service (glance) for vendors, admins, services, and users to meaningfully define an available key/value pair, and tag metadata. The intent is to enable better metadata collaboration across artifacts, services, and projects for OpenStack users. This definition describes the available metadata that can be used on different types of resources (images, artifacts, volumes, flavors, aggregates, among others). A definition includes the properties type, key, description, and constraints. This catalog will not store the values for specific instance properties. For example, a definition of a virtual CPU topology property for a number of cores will include the key to use, a description, and value constraints, such as requiring it to be an integer. As a result, users (potentially through the dashboard) would be able to search this catalog to list the available properties they can add to a flavor or image. They will see the virtual CPU topology property in the list and know that it must be an integer. In the dashboard example, when the user adds the property, its key and value will be stored in the service that owns that resource (in nova for flavors, and in glance for images).
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
openstack-gnocchi
- BZ#1252954
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
openstack-heat
- BZ#1303084
Previously, heat would attempt to validate old properties based on the current property's definitions. Consequently, during director upgrades where a property definition changed type, the process would fail with a 'TypeError' when heat tried to validate the old property value. With this fix, heat no longer tries to validate old property values. As a result, heat can now gracefully handle property schema definitions changes by only validating new property values.
Previously, heat would attempt to validate old properties based on the current property's definitions. Consequently, during director upgrades where a property definition changed type, the process would fail with a 'TypeError' when heat tried to validate the old property value. With this fix, heat no longer tries to validate old property values. As a result, heat can now gracefully handle property schema definitions changes by only validating new property values.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1318474
Previously, director used a patch update when updating a cloud, which reused all the parameters passed at creation. Parameters which were removed in an update were failing validation. Consequently, updating a stack with parameters removed, and using a patch update would fail unless the parameters were explicitly cleared. With this fix, heat changes the handling of patched updates to ignore parameters which were not present in the newest template. As a result, it's now possible to remove top-level parameters and update a stack using a patch update.
Previously, director used a patch update when updating a cloud, which reused all the parameters passed at creation. Parameters which were removed in an update were failing validation. Consequently, updating a stack with parameters removed, and using a patch update would fail unless the parameters were explicitly cleared. With this fix, heat changes the handling of patched updates to ignore parameters which were not present in the newest template. As a result, it's now possible to remove top-level parameters and update a stack using a patch update.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1303723
Previously, heat would leave the context roles empty when loading the stored context. When signaling heat used the stored context (trust scoped token), and if the context did not have any roles, it failed. Consequently, the process failed with the error 'trustee has no delegated roles'. This fix addresses this issue by populating roles when loading the stored context. As a result, loading the auth ref, and populating the roles from the token will confirm that any RBAC performed on the context roles will work as expected, and that the stack update succeeds.
Previously, heat would leave the context roles empty when loading the stored context. When signaling heat used the stored context (trust scoped token), and if the context did not have any roles, it failed. Consequently, the process failed with the error 'trustee has no delegated roles'. This fix addresses this issue by populating roles when loading the stored context. As a result, loading the auth ref, and populating the roles from the token will confirm that any RBAC performed on the context roles will work as expected, and that the stack update succeeds.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1303112
Previously, heat changed the name of properties on several neutron resources; while it used a mechanism to support the old names when creating them, it failed to validate resources created with a previous version. Consequently, using Red Hat OpenStack Platform 8 to update a stack created in version 7 (or previous) using with a neutron port resource would fail by trying to lookup a 'None' object. With this fix, when heat updates the resource, it now uses the translation mechanism on old properties too. As a result, supporting deprecated properties now works as expected with resources created from a previous version.
Previously, heat changed the name of properties on several neutron resources; while it used a mechanism to support the old names when creating them, it failed to validate resources created with a previous version. Consequently, using Red Hat OpenStack Platform 8 to update a stack created in version 7 (or previous) using with a neutron port resource would fail by trying to lookup a 'None' object. With this fix, when heat updates the resource, it now uses the translation mechanism on old properties too. As a result, supporting deprecated properties now works as expected with resources created from a previous version.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
openstack-ironic-python-agent
- BZ#1312187
Sometimes, hard drives were not available in time for a deployment ramdisk run. Consequently, the deployment failed if the ramdisk was unable to find the required root device. With this update, the "udev settle" command is executed before enumerating disks in the ramdisk, and the deployment no longer fails due to the missing root device.
Sometimes, hard drives were not available in time for a deployment ramdisk run. Consequently, the deployment failed if the ramdisk was unable to find the required root device. With this update, the "udev settle" command is executed before enumerating disks in the ramdisk, and the deployment no longer fails due to the missing root device.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
openstack-keystone
- BZ#1282944
Identity Service (keystone) used a hard-coded LDAP membership attribute when checking if a user was enabled, if the 'enabled emulation' feature was being used. Consequently, users who were `enabled` could show as `disabled` if an unexpected LDAP membership attribute was used. With this fix, the 'enabled emulation' membership check now uses the configurable LDAP membership attribute that is used for group resources. As a result, the 'enabled' status for users is shown correctly when different LDAP membership attributes are configured.
Identity Service (keystone) used a hard-coded LDAP membership attribute when checking if a user was enabled, if the 'enabled emulation' feature was being used. Consequently, users who were `enabled` could show as `disabled` if an unexpected LDAP membership attribute was used. With this fix, the 'enabled emulation' membership check now uses the configurable LDAP membership attribute that is used for group resources. As a result, the 'enabled' status for users is shown correctly when different LDAP membership attributes are configured.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1300395
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#923598
Previously, the Identity Service (keystone) allowed administrators to set a maximum password length limit that was larger than the limit used by the Passlib python module. Consequently, if the maximum password length limit was set larger than the Passlib limit, attempts to set a user password larger than the Passlib limit would fail with a HTTP 500 response and an uncaught exception. With this update, Identity Service now validates that the 'max_password_length' configuration value is less than or equal to the Passlib maximum password length limit. As a result, if the Identity Service setting 'max_password_length' is too large, it will fail to start with a configuration validation error.
Previously, the Identity Service (keystone) allowed administrators to set a maximum password length limit that was larger than the limit used by the Passlib python module. Consequently, if the maximum password length limit was set larger than the Passlib limit, attempts to set a user password larger than the Passlib limit would fail with a HTTP 500 response and an uncaught exception. With this update, Identity Service now validates that the 'max_password_length' configuration value is less than or equal to the Passlib maximum password length limit. As a result, if the Identity Service setting 'max_password_length' is too large, it will fail to start with a configuration validation error.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
openstack-neutron
- BZ#1292570
Previously, the 'ip netns list' command returned unexpected ID data in recent versions of 'iproute2'. Consequently, neutron was unable to parse namespaces. This fix addresses this issue by updating the parser used in neutron. As a result, neutron can now be expected to properly parse namespaces.
Previously, the 'ip netns list' command returned unexpected ID data in recent versions of 'iproute2'. Consequently, neutron was unable to parse namespaces. This fix addresses this issue by updating the parser used in neutron. As a result, neutron can now be expected to properly parse namespaces.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1287736
Prior to this update, the L3 agent failed to respawn keepalived process if the keepalived parent process died. This was because the child keepalived process was still running. Consequently, the L3 agent could not recover from keepalived parent process death, breaking the HA router served by the process. With this update, the L3 agent is made aware of the child keepalived process, and now cleans up it as well before respawning keepalived. As a result, the L3 agent is now able to recover HA routers when the keepalived process dies.
Prior to this update, the L3 agent failed to respawn keepalived process if the keepalived parent process died. This was because the child keepalived process was still running. Consequently, the L3 agent could not recover from keepalived parent process death, breaking the HA router served by the process. With this update, the L3 agent is made aware of the child keepalived process, and now cleans up it as well before respawning keepalived. As a result, the L3 agent is now able to recover HA routers when the keepalived process dies.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1290562
Red Hat OpenStack Platform 8 introduced a new RBAC feature that allows you to share neutron networks with a specific list of tenants, instead of globally. As part of the feature, the default policy.json file for neutron started triggering I/O, consuming database fetches for every port fetch in attempt to allow the owner of a network to list all ports that belong to his network, even if they were created by other tenants. Consequently, the list operation for ports triggered multiple unneeded database fetches, which drastically affected performance of the operation. This update addresses this issue by running the I/O operations only when they are actually needed, for example, when the port to be validated by the policy engine does not belong to the tenant that invokes the list operation. As a result, list operations for ports will scale normally again.
Red Hat OpenStack Platform 8 introduced a new RBAC feature that allows you to share neutron networks with a specific list of tenants, instead of globally. As part of the feature, the default policy.json file for neutron started triggering I/O, consuming database fetches for every port fetch in attempt to allow the owner of a network to list all ports that belong to his network, even if they were created by other tenants. Consequently, the list operation for ports triggered multiple unneeded database fetches, which drastically affected performance of the operation. This update addresses this issue by running the I/O operations only when they are actually needed, for example, when the port to be validated by the policy engine does not belong to the tenant that invokes the list operation. As a result, list operations for ports will scale normally again.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1222775
Prior to this update, the fix for BZ#1215177 added the 'garp_master_repeat 5' and 'garp_master_refresh 10' options to Keepalived configuration. Consequently however, Keepalived continuously spammed the network with Gratuitous ARP (GARP) broadcasts; in addition, instances would lose their IPv6 default gateway settings. As a result of these issues, the IPv6 router stopped working with VRRP. This update addresses these issues by dropping the 'repeat' and 'refresh' Keepalived options. This fixes the IPv6 bug but re-introduces the bug described in BZ#1215177. To resolve this, use the 'delay' option instead. As a result, Keepalived sends a GARP when it transitions to 'MASTER', and then waits a number of seconds (determined by the delay option), and sends another GARP. Use an aggressive 'delay' setting to make sure that when the node boots and the L3/L2 agents start, there is enough time for the L2 agent to wire the ports.
Prior to this update, the fix for BZ#1215177 added the 'garp_master_repeat 5' and 'garp_master_refresh 10' options to Keepalived configuration. Consequently however, Keepalived continuously spammed the network with Gratuitous ARP (GARP) broadcasts; in addition, instances would lose their IPv6 default gateway settings. As a result of these issues, the IPv6 router stopped working with VRRP. This update addresses these issues by dropping the 'repeat' and 'refresh' Keepalived options. This fixes the IPv6 bug but re-introduces the bug described in BZ#1215177. To resolve this, use the 'delay' option instead. As a result, Keepalived sends a GARP when it transitions to 'MASTER', and then waits a number of seconds (determined by the delay option), and sends another GARP. Use an aggressive 'delay' setting to make sure that when the node boots and the L3/L2 agents start, there is enough time for the L2 agent to wire the ports.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1283623
Prior to this update, a change to the Open vSwitch agent introduced a bug in how the agent handles the segmentation ID value for flat networking during agent startup. Consequently, the agent failed to restart when serving a flat network. With this update, the agent code was fixed to handle segmentation properly for flat networking. As a result, the agent is successfully restarted when serving a flat network.
Prior to this update, a change to the Open vSwitch agent introduced a bug in how the agent handles the segmentation ID value for flat networking during agent startup. Consequently, the agent failed to restart when serving a flat network. With this update, the agent code was fixed to handle segmentation properly for flat networking. As a result, the agent is successfully restarted when serving a flat network.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1295690
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1177611
A known issue has been identified for interactions between High Availability (VRRP) routers and L2 Population. Currently, when connecting a HA router to a subnet, HA routers use a distributed port by design. Each router has the same port details on each node that it's scheduled on, and only the master router has IPs configured on that port; all the slaves have the port without any IPs configured. Consequently, L2Population uses the stale information to advise that the router is present on the node (which it states in the port binding information for that port). As a result, each node that has a port on that logical network has a tunnel created only to the node where the port is presumably bound. In addition, a forwarding entry is set so that any traffic to that port is sent through the created tunnel. However, this action may not succeed as there is not guarantee that the master router is on the node specified in the port binding. Furthermore, in the event that the master router is in fact on the node, a failover event would cause it to migrate to another node and result in a loss of connectivity with the router.
A known issue has been identified for interactions between High Availability (VRRP) routers and L2 Population. Currently, when connecting a HA router to a subnet, HA routers use a distributed port by design. Each router has the same port details on each node that it's scheduled on, and only the master router has IPs configured on that port; all the slaves have the port without any IPs configured. Consequently, L2Population uses the stale information to advise that the router is present on the node (which it states in the port binding information for that port). As a result, each node that has a port on that logical network has a tunnel created only to the node where the port is presumably bound. In addition, a forwarding entry is set so that any traffic to that port is sent through the created tunnel. However, this action may not succeed as there is not guarantee that the master router is on the node specified in the port binding. Furthermore, in the event that the master router is in fact on the node, a failover event would cause it to migrate to another node and result in a loss of connectivity with the router.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1300308
Previously, the neutron-server service would sometimes erroneously require a new RPC entrypoint version from the L2 agents that listened for security group updates. Consequently, the RHEL OpenStack Platform 7 neutron L2 agents could not handle certain security group update notifications sent by Red Hat OpenStack Platform 8 neutron-server services, causing certain security group updates to not be propagated to the data plane. This update addresses this issue by ending the requirement of the new RPC endpoint version from agents, as this will assist the rolling upgrade scenario between RHEL OpenStack Platform 7 and Red Hat OpenStack Platform 8. As a result, RHEL OpenStack Platform 7 neutron L2 agents will now correctly handle security group update notifications sent by the Red Hat OpenStack Platform 8 neutron-server services.
Previously, the neutron-server service would sometimes erroneously require a new RPC entrypoint version from the L2 agents that listened for security group updates. Consequently, the RHEL OpenStack Platform 7 neutron L2 agents could not handle certain security group update notifications sent by Red Hat OpenStack Platform 8 neutron-server services, causing certain security group updates to not be propagated to the data plane. This update addresses this issue by ending the requirement of the new RPC endpoint version from agents, as this will assist the rolling upgrade scenario between RHEL OpenStack Platform 7 and Red Hat OpenStack Platform 8. As a result, RHEL OpenStack Platform 7 neutron L2 agents will now correctly handle security group update notifications sent by the Red Hat OpenStack Platform 8 neutron-server services.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1293381
Prior to this update, when the last HA router of a tenant was deleted, the HA network belonging to the tenant was not removed. This happened in certain scenarios, such as the 'router delete' API call, which raised an exception since the router had been deleted. That scenario was possible due to a race condition between HA router 'create' and 'delete' operations. As a result of this issue, HA network tenants were not deleted. This update resolves the race condition, and now catches the exceptions 'ObjectDeletedError' and 'NetworkInUse' when a user deletes the last HA router, and also moves the HA network deleting procedure under the 'ha_network exist' check block. In addition, the fix checks whether or not HA routers are present, and deletes the HA network when the last HA router is deleted.
Prior to this update, when the last HA router of a tenant was deleted, the HA network belonging to the tenant was not removed. This happened in certain scenarios, such as the 'router delete' API call, which raised an exception since the router had been deleted. That scenario was possible due to a race condition between HA router 'create' and 'delete' operations. As a result of this issue, HA network tenants were not deleted. This update resolves the race condition, and now catches the exceptions 'ObjectDeletedError' and 'NetworkInUse' when a user deletes the last HA router, and also moves the HA network deleting procedure under the 'ha_network exist' check block. In addition, the fix checks whether or not HA routers are present, and deletes the HA network when the last HA router is deleted.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1255037
Neutron ports created when neutron-openvswitch-agent is down are in status "DOWN, binding:vif_type=binding_failed", which is expected. Nevertheless, prior to this update, there was no way to recover those ports even if neutron-openvswitch-agent was back online. Now, the function "_bind_port_if_needed" binds at least once when the port's binding status passed in is already in "binding_failed". As a result, ports can now recover from a failed binding status by repeated binding attempts triggered when neutron-openvswitch-agent comes back online.
Neutron ports created when neutron-openvswitch-agent is down are in status "DOWN, binding:vif_type=binding_failed", which is expected. Nevertheless, prior to this update, there was no way to recover those ports even if neutron-openvswitch-agent was back online. Now, the function "_bind_port_if_needed" binds at least once when the port's binding status passed in is already in "binding_failed". As a result, ports can now recover from a failed binding status by repeated binding attempts triggered when neutron-openvswitch-agent comes back online.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1284739
Prior to this update, the status of a floating IP address was not set when the floating IP address was realized by an HA router. Consequently, 'neutron floatingip-show <floating_ip>' would not output an updated status. With this update, a floating IP address status is updated when realized by HA routers, and when the L3 agent configures a router. As a result, the status field for floating IP addresses realized by HA routers are now updated to 'ACTIVE' when the floating IP is configured by the L3 agent.
Prior to this update, the status of a floating IP address was not set when the floating IP address was realized by an HA router. Consequently, 'neutron floatingip-show <floating_ip>' would not output an updated status. With this update, a floating IP address status is updated when realized by HA routers, and when the L3 agent configures a router. As a result, the status field for floating IP addresses realized by HA routers are now updated to 'ACTIVE' when the floating IP is configured by the L3 agent.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
openstack-nova
- BZ#978365
The ability of the libvirt driver to set the admin password has been added. To use this feature, run the following command: "nova root-password [server]".
The ability of the libvirt driver to set the admin password has been added. To use this feature, run the following command: "nova root-password [server]".
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1298825
Previously, selecting an odd number of vCPUs would cause the assignment of one core and one thread in the guest instance per CPU, which would impact performance. The update addresses this issue by correctly assigning pairs of threads and one independent thread per CPU, when an odd number of vCPUs is assigned.
Previously, selecting an odd number of vCPUs would cause the assignment of one core and one thread in the guest instance per CPU, which would impact performance. The update addresses this issue by correctly assigning pairs of threads and one independent thread per CPU, when an odd number of vCPUs is assigned.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1301914
Previously, when a source compute node is back up after a migration, instances that have been successfully evacuated from it when the node was down were not deleted. A result of having the non-deleted instances makes it impossible to evacuate them. With this update, the successful migration status when evacuating an instance is now verified for knowing which instance to delete when a compute node is back up and running again. As a result, instances can be evacuated from one host to another, regardless of their previous locations.
Previously, when a source compute node is back up after a migration, instances that have been successfully evacuated from it when the node was down were not deleted. A result of having the non-deleted instances makes it impossible to evacuate them. With this update, the successful migration status when evacuating an instance is now verified for knowing which instance to delete when a compute node is back up and running again. As a result, instances can be evacuated from one host to another, regardless of their previous locations.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1315394
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1293607
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
openstack-packstack
- BZ#1301366
Previously, Packstack did not enable the VPNaaS tab in the Dashboard even if the CONFIG_NEUTRON_VPNAAS parameter was set to 'y'. As a result, the tab for VPNaaS was not shown on the Dashboard. With this update, a check to see if VPNaaS is enabled has been set up. This check then enables the Dashboard tab in the Puppet manifest. As a result, the VPNaaS tab is now shown on the Dashboard when the service is configured in Packstack.
Previously, Packstack did not enable the VPNaaS tab in the Dashboard even if the CONFIG_NEUTRON_VPNAAS parameter was set to 'y'. As a result, the tab for VPNaaS was not shown on the Dashboard. With this update, a check to see if VPNaaS is enabled has been set up. This check then enables the Dashboard tab in the Puppet manifest. As a result, the VPNaaS tab is now shown on the Dashboard when the service is configured in Packstack.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1297712
Previously, Packstack edited the /etc/lvm/lvm.conf file to set specific parameters for snapshot autoextend. However, the regexp used only allowed black spaces instead of the tabs as currently used in the file. As a result, some lines were added at the end of the file, breaking its format. With this update, the regexp is updated in Packstack to set the parameters properly. As a result, there are no error messages when running LVM commands.
Previously, Packstack edited the /etc/lvm/lvm.conf file to set specific parameters for snapshot autoextend. However, the regexp used only allowed black spaces instead of the tabs as currently used in the file. As a result, some lines were added at the end of the file, breaking its format. With this update, the regexp is updated in Packstack to set the parameters properly. As a result, there are no error messages when running LVM commands.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
openstack-puppet-modules
- BZ#1289180
Previously, although the haproxy is configured to allow a value of 10000 for the 'maxconn' parameter for all proxies together, there is a default 'maxconn' value of 2000 for each proxy individually. If the specific proxy used for MySQL reached the limit of 2000, it dropped all further connections to the database and the client would not retry, which caused API timeout and subsequent commands to fail. With this update, the default value for 'maxconn' parameter has been increased to work better for production environments, As a result, the database connections are far less likely to time out.
Previously, although the haproxy is configured to allow a value of 10000 for the 'maxconn' parameter for all proxies together, there is a default 'maxconn' value of 2000 for each proxy individually. If the specific proxy used for MySQL reached the limit of 2000, it dropped all further connections to the database and the client would not retry, which caused API timeout and subsequent commands to fail. With this update, the default value for 'maxconn' parameter has been increased to work better for production environments, As a result, the database connections are far less likely to time out.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1280523
Previously, Facter 2 did not have netmask6 and netmask6_<ifce> facts. As a result, IPv6 was not supported. With this update, the relevant custom facts have been added to support checks on IPv6 interfaces, resulting in the IPv6 interfaces are now supported.
Previously, Facter 2 did not have netmask6 and netmask6_<ifce> facts. As a result, IPv6 was not supported. With this update, the relevant custom facts have been added to support checks on IPv6 interfaces, resulting in the IPv6 interfaces are now supported.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1243611
Previously, there was no default time out parameter, resulting in some stages of Ceph cluster set-up that look longer than the default 5 minutes (300 seconds). With this update, a time out parameter is added for relevant operations. The default time out parameter value is set at 600 seconds. You can modify the default value, if necessary. As a result, the installation is more resilient, especially when some of the Ceph setup operations take longer than average.
Previously, there was no default time out parameter, resulting in some stages of Ceph cluster set-up that look longer than the default 5 minutes (300 seconds). With this update, a time out parameter is added for relevant operations. The default time out parameter value is set at 600 seconds. You can modify the default value, if necessary. As a result, the installation is more resilient, especially when some of the Ceph setup operations take longer than average.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
openstack-sahara
- BZ#1189502
With this update, configuration settings now exist to set timeouts, after which clusters which have failed to reach the 'Active' state will be automatically deleted.
With this update, configuration settings now exist to set timeouts, after which clusters which have failed to reach the 'Active' state will be automatically deleted.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1189517
When creating a job template intended for re-use, you can now register a variable for datasource URLs with OpenStack Data Processing (sahara). Doing so allows you to easily change input and output paths per run, rather than an actual URL (which would require revising the template, or manually revising the URL per run between jobs). This makes it easier to reuse job templates when data source jobs are mutable between runs, as is true for most real-world cases.
When creating a job template intended for re-use, you can now register a variable for datasource URLs with OpenStack Data Processing (sahara). Doing so allows you to easily change input and output paths per run, rather than an actual URL (which would require revising the template, or manually revising the URL per run between jobs). This makes it easier to reuse job templates when data source jobs are mutable between runs, as is true for most real-world cases.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1299982
With this update, the integration for CDH 5.4 with Sahara is now complete and hence, the default-enabled option for the plugin version, CDH 5.3 is now removed.
With this update, the integration for CDH 5.4 with Sahara is now complete and hence, the default-enabled option for the plugin version, CDH 5.3 is now removed.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1233159
Previously, the tenant context information was not available to the periodic task responsible for cleaning up stale clusters. With this update, temporary trusts are established between the tenant and admin, allowing the periodic job to use this trust to delete stale clusters.
Previously, the tenant context information was not available to the periodic task responsible for cleaning up stale clusters. With this update, temporary trusts are established between the tenant and admin, allowing the periodic job to use this trust to delete stale clusters.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
openstack-selinux
- BZ#1281547
Previously, httpd was not allowed to search through directories having the "nova_t" label. Consequently, nova-novncproxy failed to deploy an HA overcloud. This update allows httpd to search through such directories, which enables nova-novncproxy to run successfully.
Previously, httpd was not allowed to search through directories having the "nova_t" label. Consequently, nova-novncproxy failed to deploy an HA overcloud. This update allows httpd to search through such directories, which enables nova-novncproxy to run successfully.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1284268
Previously, Openvswitch was trying to create a tun socket, but SELinux prevented that. This update allows Openvswitch to create a tun socket, and as a result, Openvswitch now runs without failures.
Previously, Openvswitch was trying to create a tun socket, but SELinux prevented that. This update allows Openvswitch to create a tun socket, and as a result, Openvswitch now runs without failures.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1310383
Previously, SELinux blocked ovsdb-server from running, resulting in simple networking operations to fail. With this update, Open vSwitch is allowed to connect to its own port. As a result, ovsdb-server now runs without issues and the networking operations are completed successfully.
Previously, SELinux blocked ovsdb-server from running, resulting in simple networking operations to fail. With this update, Open vSwitch is allowed to connect to its own port. As a result, ovsdb-server now runs without issues and the networking operations are completed successfully.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1284133
Previously, SELinux prevented redis from connecting to its own port, resulting in redis failing at restart. With this update, redis has the permission to connect to the 'redis' labeled port. As a result, redis runs properly and resource restart is successful.
Previously, SELinux prevented redis from connecting to its own port, resulting in redis failing at restart. With this update, redis has the permission to connect to the 'redis' labeled port. As a result, redis runs properly and resource restart is successful.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1281588
Prior to this update, SELinux prevented nova from uploading the public key to the overcloud. A new rule has now been added to allow nova to upload the key.
Prior to this update, SELinux prevented nova from uploading the public key to the overcloud. A new rule has now been added to allow nova to upload the key.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1306525
Previously, when nova was trying to retrieve a list of glance images, SELinux prevented that, and nova failed with an "Unexpected API Error". This update allows nova to communicate with glance. As a result, nova can now list glance images.
Previously, when nova was trying to retrieve a list of glance images, SELinux prevented that, and nova failed with an "Unexpected API Error". This update allows nova to communicate with glance. As a result, nova can now list glance images.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1283674
Prior to this update, SELinix prevented dhclient, vnc, and redis from working. New rules have now been added to allow these software tools to run successfully.
Prior to this update, SELinix prevented dhclient, vnc, and redis from working. New rules have now been added to allow these software tools to run successfully.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
openvswitch
- BZ#1266050
The Open vSwitch (openvswitch) package is now re-based to upstream version 2.4.0.
The Open vSwitch (openvswitch) package is now re-based to upstream version 2.4.0.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
python-cinderclient
- BZ#1214230
With this update, a new feature adds pagination support for the Block Storage 'snapshots-list' and 'backups-list' commands. You can now limit, marker and sort parameters to control the number of returned results, starting element and their order. Retrieving a limited number of results instead of the entire data set can be extremely useful on the large deployments with thousands of snapshots and backups.
With this update, a new feature adds pagination support for the Block Storage 'snapshots-list' and 'backups-list' commands. You can now limit, marker and sort parameters to control the number of returned results, starting element and their order. Retrieving a limited number of results instead of the entire data set can be extremely useful on the large deployments with thousands of snapshots and backups.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
python-django-horizon
- BZ#1167563
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1100542
OpenStack dashboard tables summarize information about a large number of entities. This update adds a table enhancement that enables this information to be displayed within the table as a slide-down "drawer" that is activated when you click on a toggle switch within a row. The drawer appears as an additional row (with configurable height) and contains additional information about the entity in the row above it (e.g. additional entity details, metrics, graphs, etc.). Multiple drawers may be opened at one time.
OpenStack dashboard tables summarize information about a large number of entities. This update adds a table enhancement that enables this information to be displayed within the table as a slide-down "drawer" that is activated when you click on a toggle switch within a row. The drawer appears as an additional row (with configurable height) and contains additional information about the entity in the row above it (e.g. additional entity details, metrics, graphs, etc.). Multiple drawers may be opened at one time.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1166963
This update replaces the network topology with curvature based graph as the previous UI did not work well with larger number of nodes or networks. The new network topology map can handle more nodes, looks stylish and the node layout can be re-organized.
This update replaces the network topology with curvature based graph as the previous UI did not work well with larger number of nodes or networks. The new network topology map can handle more nodes, looks stylish and the node layout can be re-organized.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1042947
This update adds support for volume migrations of the Block Storage (cinder) service. These are done in the 'Volumes' panel of the OpenStack dashboard (Project-> Compute -> Volumes and in Admin-> System Panel-> Volumes). You can perform this action on the 'Volumes' row in the table. The final patch in this series resolved the command action itself; it had previously errored out due to incorrect parameters, and parameter count issues.
This update adds support for volume migrations of the Block Storage (cinder) service. These are done in the 'Volumes' panel of the OpenStack dashboard (Project-> Compute -> Volumes and in Admin-> System Panel-> Volumes). You can perform this action on the 'Volumes' row in the table. The final patch in this series resolved the command action itself; it had previously errored out due to incorrect parameters, and parameter count issues.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1305905
The python-django-horizon packages have been upgraded to upstream version 8.0.1, which provides a number of bug fixes and enhancements over the previous version. Notably, this version contains localization updates, includes Italian localization, fixes job_binaries deletion, and adds support for accepting IPv6 in the VIP address for an LB pool.
The python-django-horizon packages have been upgraded to upstream version 8.0.1, which provides a number of bug fixes and enhancements over the previous version. Notably, this version contains localization updates, includes Italian localization, fixes job_binaries deletion, and adds support for accepting IPv6 in the VIP address for an LB pool.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1279812
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1300735
With this release, the 'Metering' panel in Dashboard (horizon) has been disabled due to performance issues.
With this release, the 'Metering' panel in Dashboard (horizon) has been disabled due to performance issues.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1297757
Previously, no timeout was specified in horizon's systemd snippet for httpd, so the standard one-minute timeout was used when waiting for httpd to fully start up. In some cases, however, especially when running in a virtualized or a very loaded environment, the startup takes longer. Consequently, a failure from systemd sometimes occurred even if httpd was already running. With this update, the timeout has been set to two minutes, which resolves the problem.
Previously, no timeout was specified in horizon's systemd snippet for httpd, so the standard one-minute timeout was used when waiting for httpd to fully start up. In some cases, however, especially when running in a virtualized or a very loaded environment, the startup takes longer. Consequently, a failure from systemd sometimes occurred even if httpd was already running. With this update, the timeout has been set to two minutes, which resolves the problem.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
python-glance-store
- BZ#1284845
Previously, when Object Storage service was used as a backend storage for Image service, image data was stored in Object Storage service as multiple 'chunks' of data. When using the Image service APIv2, there were circumstances in which the upload operations would fail if the client sent a final zero-sized 'chunk' to the server. The failure involved a race condition between the operation to store a zero-sized 'chunk' and a cleanup delete of that 'chunk'. As a result, intermittent failure occurred while storing Image service images in Object Storage service. With this update, the cleanup delete operations are retried rather than failing them as well as the primary upload image task. As a result, Image service APIv2 handles this rare circumstance gracefully, so that the image upload does not fail.
Previously, when Object Storage service was used as a backend storage for Image service, image data was stored in Object Storage service as multiple 'chunks' of data. When using the Image service APIv2, there were circumstances in which the upload operations would fail if the client sent a final zero-sized 'chunk' to the server. The failure involved a race condition between the operation to store a zero-sized 'chunk' and a cleanup delete of that 'chunk'. As a result, intermittent failure occurred while storing Image service images in Object Storage service. With this update, the cleanup delete operations are retried rather than failing them as well as the primary upload image task. As a result, Image service APIv2 handles this rare circumstance gracefully, so that the image upload does not fail.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1229634
Previously, there was no secure way to remotely access S3 backend in a private network. With this update, a new feature allows Image service S3 driver to connect a S3 backend from a different network in a secure way through the HTTP proxy.
Previously, there was no secure way to remotely access S3 backend in a private network. With this update, a new feature allows Image service S3 driver to connect a S3 backend from a different network in a secure way through the HTTP proxy.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
python-glanceclient
- BZ#1314069
Previously, the Image service client could be configured to only allow uploading images in certain formats (for example, raw, ami, iso) to the Image service server. The client also allowed download of an image from the server only if it was in one of these formats. As a result of this restriction, users could no longer download images in other formats that had been previously uploaded. With this update, as the Image service server already validates image formats at the time they are imported, there is no need for the Image service client to verify image format when it is downloaded. As a result, the image format validation when an image is downloaded is now skipped, allowing the consumption of images in legitimate formats even if the client-side support for upload of images in those formats is no longer configured.
Previously, the Image service client could be configured to only allow uploading images in certain formats (for example, raw, ami, iso) to the Image service server. The client also allowed download of an image from the server only if it was in one of these formats. As a result of this restriction, users could no longer download images in other formats that had been previously uploaded. With this update, as the Image service server already validates image formats at the time they are imported, there is no need for the Image service client to verify image format when it is downloaded. As a result, the image format validation when an image is downloaded is now skipped, allowing the consumption of images in legitimate formats even if the client-side support for upload of images in those formats is no longer configured.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
python-heatclient
- BZ#1234108
Previously, the output of the "heat resource-list --nested-depth ..." command contained a column called "parent_resource"; however, the output did not include the information required to run a subsequent "heat resource-show ..." command. With this update, the output of the "heat resource-list --nested-depth ..." command includes a column called "stack_name", which provides the values to use in a "heat resource-show [stack_name] [resource_name]" call.
Previously, the output of the "heat resource-list --nested-depth ..." command contained a column called "parent_resource"; however, the output did not include the information required to run a subsequent "heat resource-show ..." command. With this update, the output of the "heat resource-list --nested-depth ..." command includes a column called "stack_name", which provides the values to use in a "heat resource-show [stack_name] [resource_name]" call.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
python-networking-odl
- BZ#1266156
The OpenDaylight OpenStack neutron driver has been split from the neutron project and moved to a new package, python-networking-odl. Operators still have the driver available for use as part of their Red Hat OpenStack Platform installations.
The OpenDaylight OpenStack neutron driver has been split from the neutron project and moved to a new package, python-networking-odl. Operators still have the driver available for use as part of their Red Hat OpenStack Platform installations.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
python-neutronclient
- BZ#1291739
The 'neutron router-gateway-set' command now supports the '--fixed-ip' option, which allows you to configure the fixed IP address and subnet that the router will use in the external network. This IP address is used by the OpenStack Networking service (openstack-neutron) to connect interfaces on the software level to connect the tenant networks to the external network.
The 'neutron router-gateway-set' command now supports the '--fixed-ip' option, which allows you to configure the fixed IP address and subnet that the router will use in the external network. This IP address is used by the OpenStack Networking service (openstack-neutron) to connect interfaces on the software level to connect the tenant networks to the external network.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
python-openstackclient
- BZ#1303038
With this release, the python-openstackclient package is now re-based to upstream version 1.7.2. This applies several fixes and enhancements, which include improved exception handling for 'find_resource'.
With this release, the python-openstackclient package is now re-based to upstream version 1.7.2. This applies several fixes and enhancements, which include improved exception handling for 'find_resource'.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
python-oslo-messaging
- BZ#1302391
Oslo Messaging used the "shuffle" strategy to select a RabbitMQ host from the list of RabbitMQ servers. When a node of the cluster running RabbitMQ was restarted, each OpenStack service connected to this server reconnected to a new RabbitMQ server. Unfortunately, this strategy does not handle dead RabbitMQ servers correctly; it can try to connect to the same dead server multiple times in a row. The strategy also leads to increased reconnection time, and sometimes it may lead to RPC operations timing out because no guarantee is provided on how long the reconnection process will take. With this update, Oslo Messaging uses the "round-robin" strategy to select a RabbitMQ host. This strategy provides the least achievable reconnection time and avoids RPC timeout when a node is restarted. It also guarantees that if K of N RabbitMQ hosts are alive, it will take at most N - K + 1 attempts to successfully reconnect to the RabbitMQ cluster.
Oslo Messaging used the "shuffle" strategy to select a RabbitMQ host from the list of RabbitMQ servers. When a node of the cluster running RabbitMQ was restarted, each OpenStack service connected to this server reconnected to a new RabbitMQ server. Unfortunately, this strategy does not handle dead RabbitMQ servers correctly; it can try to connect to the same dead server multiple times in a row. The strategy also leads to increased reconnection time, and sometimes it may lead to RPC operations timing out because no guarantee is provided on how long the reconnection process will take. With this update, Oslo Messaging uses the "round-robin" strategy to select a RabbitMQ host. This strategy provides the least achievable reconnection time and avoids RPC timeout when a node is restarted. It also guarantees that if K of N RabbitMQ hosts are alive, it will take at most N - K + 1 attempts to successfully reconnect to the RabbitMQ cluster.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1312912
When the RabbitMQ service fails to deliver an AMQP message from one OpenStack service to another, it reconnects and retries delivery. The "rabbit_retry_backoff" option, whose default is 2 seconds, is supposed to control the pace of retries; however, retries were previously done every second irrespective of the configured value of this option. The consequence of this problem was excessive retries, for example, when an endpoint was not available. This problem has now been fixed, and the "rabbit_retry_backoff" option, as explicitly configured or with the default value of two seconds, properly controls message delivery retries.
When the RabbitMQ service fails to deliver an AMQP message from one OpenStack service to another, it reconnects and retries delivery. The "rabbit_retry_backoff" option, whose default is 2 seconds, is supposed to control the pace of retries; however, retries were previously done every second irrespective of the configured value of this option. The consequence of this problem was excessive retries, for example, when an endpoint was not available. This problem has now been fixed, and the "rabbit_retry_backoff" option, as explicitly configured or with the default value of two seconds, properly controls message delivery retries.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
python-oslo-middleware
- BZ#1313875
With this release, oslo.middleware now supports SSL/TLS, which in turn allows OpenStack services to listen to HTTPS traffic and encrypt exchanges. In previous releases, OpenStack services could only listen to HTTP, and all exchanges were done in cleartext.
With this release, oslo.middleware now supports SSL/TLS, which in turn allows OpenStack services to listen to HTTPS traffic and encrypt exchanges. In previous releases, OpenStack services could only listen to HTTP, and all exchanges were done in cleartext.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
python-oslo-service
- BZ#1288528
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
sahara-image-elements
- BZ#1286276
In some base image contexts, iptables was not initialized prior to save. This cause 'iptables save' in the 'disable-firewall' element to fail. This release adds the non-destructive command 'iptables -L', which successfully initializes iptables in all contexts, thereby ensuring a successful image generation.
In some base image contexts, iptables was not initialized prior to save. This cause 'iptables save' in the 'disable-firewall' element to fail. This release adds the non-destructive command 'iptables -L', which successfully initializes iptables in all contexts, thereby ensuring a successful image generation.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#1286856
In the Liberty release, the OpenStack versioning scheme is now based on the major release number (previously, it was based on year). This update adds an epoch to the current sahara-image-elements package to ensure that it upgrades the older version.
In the Liberty release, the OpenStack versioning scheme is now based on the major release number (previously, it was based on year). This update adds an epoch to the current sahara-image-elements package to ensure that it upgrades the older version.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow