26e268db79
This follows up [1] by adding an extension to allow requesting the default subnet pool explicitly through the API thus restoring the convenience that was lost by removing the automatic default subnetpool fallback behavior. ApiImpact [1] https://review.openstack.org/#/c/279378/ Change-Id: Ifff57c0485e4727f352b2cc2bd1bdaabd0f1606b Related-Bug: #1545199 Closes-Bug: #1547705
28 lines
1.2 KiB
YAML
28 lines
1.2 KiB
YAML
---
|
|
features:
|
|
- The subnet API now includes a new
|
|
use_default_subnetpool attribute. This attribute can
|
|
be specified on creating a subnet in lieu of a
|
|
subnetpool_id. The two are mutually exclusive. If
|
|
it is specified as True, the default subnet pool for
|
|
the requested ip_version will be looked up and used.
|
|
If no default exists, an error will be returned.
|
|
deprecations:
|
|
- The default_subnet_pools option is now deprecated and
|
|
will be removed in the Newton release. The same
|
|
functionality is now provided by setting is_default
|
|
attribute on subnetpools to True using the API or
|
|
client.
|
|
fixes:
|
|
- Before Mitaka, when a default subnetpool was defined
|
|
in the configuration, a request to create a subnet
|
|
would fall back to using it if no specific subnet
|
|
pool was specified. This behavior broke the
|
|
semantics of subnet create calls in this scenario and
|
|
is now considered an API bug. This bug has been
|
|
fixed so that there is no automatic fallback with the
|
|
presence of a default subnet pool. Workflows which
|
|
depended on this new behavior will have to be
|
|
modified to set the new use_default_subnetpool
|
|
attribute when creating a subnet.
|