← Back to team overview

yahoo-eng-team team mailing list archive

  1. yahoo-eng-team team
  2. Mailing list archive
  3. Message #93905

[Bug 2063669] [NEW] DNS extensions reported as available even if not enabled

  Thread Previous • Date Previous • • Thread Next 
Public bug reported:

# Summary

The Neutron Extensions API [^1] returns all possible DNS extensions even if the configured DNS extension driver for the ML2 plugin does not offer all of them or even if no DNS extension driver is enabled at all.
This is misleading to the user because it communicates features that aren't actually available depending on the backend configuration.

This is in contrast to other Neutron extensions (e.g. "uplink-status-
propagation") where the Extensions API only returns the extension if it
is actually enabled.

[^1]: https://docs.openstack.org/api-ref/network/v2/#id5


# Description

In the context of DNS functionality, Neutron has a hierarchy of
extensions that supersede one another [^2]:

- dns-integration
- dns-domain-ports (includes dns-integration)
- subnet-dns-publish-fixed-ip (includes dns-integration and dns-domain-ports)
- dns-integration-domain-keywords (includes all others)

The "dns-integration" extension offers the least functionality and "dns-integration-domain-keywords" the most.
The `extension_drivers` setting of the ML2 plugin determines which extension will be active.
Thus, the actual DNS functionality range offered by Neutron depends on the selected extension driver.

The user documentation of Designate [^3] instructs users to query the Neutron Extensions API to determine the available functionality.
For the different use cases involving publishing fixed IP DNS records within user-created networks [^4], the documentation states: "Check that the subnet-dns-publish-fixed-ip Neutron extension is enabled.".

This suggests that the user should check for the "subnet-dns-publish-
fixed-ip" extension in the Neutron Extensions API and if it is listed,
they can expect the feature to work.

However, the Neutron Extensions API currently returns all DNS extensions regardless of which DNS extension driver is actually active. Even if none of them is active, all DNS extensions are still returned.
Depending on the individual configuration, this might communicate the availability of features to the user which aren't actually available.
In the case of the Designate documentation, this is especially misleading because it seems to assume that the extensions listed by Neutron API match the available functionality.

[^2]: https://docs.openstack.org/designate/latest/user/neutron-
integration.html#neutron-dns-extensions

[^3]: https://docs.openstack.org/designate/latest/user/neutron-
integration.html#dns-domain-ports

[^4]: https://docs.openstack.org/designate/latest/user/neutron-
integration.html#dns-for-nova-server-instances


# How to reproduce

The following steps have been executed on a DevStack with Neutron
@135cfa321549f04bc248dbcece45075fc59cfa67 and neutron-lib v3.11.0 with
OVN-based configuration.

Consider the following example entry in
`/etc/neutron/plugins/ml2/ml2_conf.ini`:

```
[ml2]
extension_drivers = port_security,qos,dns_domain_ports
```

Note: the behavior illustrated below stays the same even if
`dns_domain_ports` is removed completely and no DNS extension driver is
specified at all!

Either the OpenStack client can be used or API requests directly to list
extensions:

```
# authenticate as user
$ source openrc demo demo

# check API extensions using client
$ openstack extension list --network -f value -c Alias | grep dns
dns-integration
dns-domain-ports
dns-integration-domain-keywords
subnet-dns-publish-fixed-ip

# check API extensions via direct HTTP request
$ TOKEN=$(openstack token issue -f value -c id)
$ curl -s -H "X-Auth-Token: $TOKEN" http://192.168.144.111:9696/networking/v2.0/extensions | jq | grep "alias.*dns"
      "alias": "dns-integration",
      "alias": "dns-domain-ports",
      "alias": "dns-integration-domain-keywords",
      "alias": "subnet-dns-publish-fixed-ip",
```

But the "subnet-dns-publish-fixed-ip" extension is not actually active:

```
$ openstack network create test-network
$ openstack subnet create --network test-network \
    --subnet-range 192.168.0.1/24 --dns-publish-fixed-ip test-subnet
$ openstack subnet show -f value -c dns_publish_fixed_ip test-subnet
None
```

In this case the `dns_publish_fixed_ip` attribute is returned as `None` and the documented behavior of DNS record publishing using Designate does not work.
This can also be verified by peeking into Neutron's database and observing that the "subnet_dns_publish_fixed_ips" table does not receive any entries.
Once the `dns_publish_fixed_ip` extension driver is enabled in `ml2_conf.ini`, the attribute will be returned as either `True` or `False` instead and the DNS record creation actually works.

# Counterexample (expected behavior)

The ML2 plugin shows a different behavior for the "uplink-status-propagation" extension.
The API will only list this extension if its extension driver actually enabled.
Documented below is the behavior of the "uplink-status-propagation" extension on the same DevStack environment.

Based on the following setting:

```
[ml2]
extension_drivers = port_security,qos
```

The extension "uplink-status-propagation" will not be listed by the
Extensions API:

```
$ openstack extension list --network -f value -c Alias | grep uplink

```

Now, after adding the `uplink_status_propagation` extension driver like
this:

```
[ml2]
extension_drivers = port_security,qos,uplink_status_propagation
```

... and restarting Neutron, the extension will now be listed by the
Extensions API:

```
$ openstack extension list --network -f value -c Alias | grep uplink
uplink-status-propagation
```

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2063669

Title:
  DNS extensions reported as available even if not enabled

Status in neutron:
  New

Bug description:
  # Summary

  The Neutron Extensions API [^1] returns all possible DNS extensions even if the configured DNS extension driver for the ML2 plugin does not offer all of them or even if no DNS extension driver is enabled at all.
  This is misleading to the user because it communicates features that aren't actually available depending on the backend configuration.

  This is in contrast to other Neutron extensions (e.g. "uplink-status-
  propagation") where the Extensions API only returns the extension if
  it is actually enabled.

  [^1]: https://docs.openstack.org/api-ref/network/v2/#id5

  
  # Description

  In the context of DNS functionality, Neutron has a hierarchy of
  extensions that supersede one another [^2]:

  - dns-integration
  - dns-domain-ports (includes dns-integration)
  - subnet-dns-publish-fixed-ip (includes dns-integration and dns-domain-ports)
  - dns-integration-domain-keywords (includes all others)

  The "dns-integration" extension offers the least functionality and "dns-integration-domain-keywords" the most.
  The `extension_drivers` setting of the ML2 plugin determines which extension will be active.
  Thus, the actual DNS functionality range offered by Neutron depends on the selected extension driver.

  The user documentation of Designate [^3] instructs users to query the Neutron Extensions API to determine the available functionality.
  For the different use cases involving publishing fixed IP DNS records within user-created networks [^4], the documentation states: "Check that the subnet-dns-publish-fixed-ip Neutron extension is enabled.".

  This suggests that the user should check for the "subnet-dns-publish-
  fixed-ip" extension in the Neutron Extensions API and if it is listed,
  they can expect the feature to work.

  However, the Neutron Extensions API currently returns all DNS extensions regardless of which DNS extension driver is actually active. Even if none of them is active, all DNS extensions are still returned.
  Depending on the individual configuration, this might communicate the availability of features to the user which aren't actually available.
  In the case of the Designate documentation, this is especially misleading because it seems to assume that the extensions listed by Neutron API match the available functionality.

  [^2]: https://docs.openstack.org/designate/latest/user/neutron-
  integration.html#neutron-dns-extensions

  [^3]: https://docs.openstack.org/designate/latest/user/neutron-
  integration.html#dns-domain-ports

  [^4]: https://docs.openstack.org/designate/latest/user/neutron-
  integration.html#dns-for-nova-server-instances

  
  # How to reproduce

  The following steps have been executed on a DevStack with Neutron
  @135cfa321549f04bc248dbcece45075fc59cfa67 and neutron-lib v3.11.0 with
  OVN-based configuration.

  Consider the following example entry in
  `/etc/neutron/plugins/ml2/ml2_conf.ini`:

  ```
  [ml2]
  extension_drivers = port_security,qos,dns_domain_ports
  ```

  Note: the behavior illustrated below stays the same even if
  `dns_domain_ports` is removed completely and no DNS extension driver
  is specified at all!

  Either the OpenStack client can be used or API requests directly to
  list extensions:

  ```
  # authenticate as user
  $ source openrc demo demo

  # check API extensions using client
  $ openstack extension list --network -f value -c Alias | grep dns
  dns-integration
  dns-domain-ports
  dns-integration-domain-keywords
  subnet-dns-publish-fixed-ip

  # check API extensions via direct HTTP request
  $ TOKEN=$(openstack token issue -f value -c id)
  $ curl -s -H "X-Auth-Token: $TOKEN" http://192.168.144.111:9696/networking/v2.0/extensions | jq | grep "alias.*dns"
        "alias": "dns-integration",
        "alias": "dns-domain-ports",
        "alias": "dns-integration-domain-keywords",
        "alias": "subnet-dns-publish-fixed-ip",
  ```

  But the "subnet-dns-publish-fixed-ip" extension is not actually
  active:

  ```
  $ openstack network create test-network
  $ openstack subnet create --network test-network \
      --subnet-range 192.168.0.1/24 --dns-publish-fixed-ip test-subnet
  $ openstack subnet show -f value -c dns_publish_fixed_ip test-subnet
  None
  ```

  In this case the `dns_publish_fixed_ip` attribute is returned as `None` and the documented behavior of DNS record publishing using Designate does not work.
  This can also be verified by peeking into Neutron's database and observing that the "subnet_dns_publish_fixed_ips" table does not receive any entries.
  Once the `dns_publish_fixed_ip` extension driver is enabled in `ml2_conf.ini`, the attribute will be returned as either `True` or `False` instead and the DNS record creation actually works.

  # Counterexample (expected behavior)

  The ML2 plugin shows a different behavior for the "uplink-status-propagation" extension.
  The API will only list this extension if its extension driver actually enabled.
  Documented below is the behavior of the "uplink-status-propagation" extension on the same DevStack environment.

  Based on the following setting:

  ```
  [ml2]
  extension_drivers = port_security,qos
  ```

  The extension "uplink-status-propagation" will not be listed by the
  Extensions API:

  ```
  $ openstack extension list --network -f value -c Alias | grep uplink

  ```

  Now, after adding the `uplink_status_propagation` extension driver
  like this:

  ```
  [ml2]
  extension_drivers = port_security,qos,uplink_status_propagation
  ```

  ... and restarting Neutron, the extension will now be listed by the
  Extensions API:

  ```
  $ openstack extension list --network -f value -c Alias | grep uplink
  uplink-status-propagation
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2063669/+subscriptions
  Thread Previous • Date Previous • • Thread Next