[TripleO][Manila] 'DEFAULT/network_plugin_ipv6_enabled' parameter - why is it not simply enabled by default?
Hi, I'm working on a change to remove some parameters related to IPv6 in TripleO. This is to simplify/automate the process for operators, and reduce failures due to user error. See: https://review.opendev.org/723898 I'm not sure what to do about the 'ManilaIPv6' parameter in TripleO. It control's the *DEFAULT/network_plugin_ipv6_enabled* parameter as well as *${share_backend_name}/network_plugin_ipv6_enabled* for some backends. Dockstrings [2] and [3] in the puppet module for these backends says the same as the Manila doc[1]. A note in Manilla doc[1] reading: """ The ip version of the share network is defined by the flags of network_plugin_ipv4_enabled and network_plugin_ipv6_enabled in the manila.conf configuration since Pike. The network_plugin_ipv4_enabled default value is set to True. The network_plugin_ipv6_enabled default value is set to False. If network_plugin_ipv6_enabled option is True, the value of network_plugin_ipv4_enabled will be ignored, it means to support both IPv4 and IPv6 share network. """ Is there a downside in simply enabling IPv6 by default in Manila? Why is this option present at all? [1] https://docs.openstack.org/manila/latest/admin/shared-file-systems-network-p... [2] https://opendev.org/openstack/puppet-manila/src/branch/master/manifests/back... [3] https://opendev.org/openstack/puppet-manila/src/branch/master/manifests/back... -- Harald Jensås
On 08/05/20 11:58 +0200, Harald Jensås wrote:
Hi,
I'm working on a change to remove some parameters related to IPv6 in TripleO. This is to simplify/automate the process for operators, and reduce failures due to user error. See: https://review.opendev.org/723898
I'm not sure what to do about the 'ManilaIPv6' parameter in TripleO. It control's the *DEFAULT/network_plugin_ipv6_enabled* parameter as well as *${share_backend_name}/network_plugin_ipv6_enabled* for some backends. Dockstrings [2] and [3] in the puppet module for these backends says the same as the Manila doc[1].
A note in Manilla doc[1] reading: """ The ip version of the share network is defined by the flags of network_plugin_ipv4_enabled and network_plugin_ipv6_enabled in the manila.conf configuration since Pike. The network_plugin_ipv4_enabled default value is set to True. The network_plugin_ipv6_enabled default value is set to False. If network_plugin_ipv6_enabled option is True, the value of network_plugin_ipv4_enabled will be ignored, it means to support both IPv4 and IPv6 share network.
"""
Is there a downside in simply enabling IPv6 by default in Manila? Why is this option present at all?
Why present: historically, some Manila backends only supported exporting and mounting file shares over IPv4 share networks, but then added IPv6 capabilities and needed configuration for their Manila drivers. Those drivers went down different code paths depending on whether IPv6 capability was enabled or not. Why default False: backwards compatibility. If the back storage itself, outside of OpenStack proper, hadn't been upgraded or configured to support IPv6, leaving the configuration toggle False ensured that the Manila driver wouldn't treat the backend device as having capabilities that it lacked. Can we remove this option now? Maybe. As you observe, it seems really to only be used nowadays by Dell-EMC drivers. We can check current requirements with the folks who use these drivers and see if the option is still needed. Even if it is, we might be able to toggle it different means than this THT/puppet variable. That said, Manila follows a deprecate in one release, remove/change in the following policy with regard to configuration option changes (removal of options or change in their default values in manila.conf proper). Goutham Pacha Ravi (Manila PTL) and I talked about this and were going to ask if it would make sense to leave the parameter as is in the review in question but make a LP Bug calling for its removal. We can then deprecate and remove the manila configuration variable it controls, or control it by other means, but follow our normal configuration change procedures. We have by the way independent motivation to remove the THT/puppet parameter anyways, namely that it has global scope for Manila but is being used for back end specific configuration. That didn't matter for TripleO when it only supported configuring a single Manila back end but that single back end limitation is getting removed. -- Tom Barron
[1] https://docs.openstack.org/manila/latest/admin/shared-file-systems-network-p... [2] https://opendev.org/openstack/puppet-manila/src/branch/master/manifests/back... [3] https://opendev.org/openstack/puppet-manila/src/branch/master/manifests/back...
-- Harald Jensås
On Fri, 2020-05-08 at 07:10 -0400, Tom Barron wrote:
On 08/05/20 11:58 +0200, Harald Jensås wrote:
Hi,
I'm working on a change to remove some parameters related to IPv6 in TripleO. This is to simplify/automate the process for operators, and reduce failures due to user error. See: https://review.opendev.org/723898
I'm not sure what to do about the 'ManilaIPv6' parameter in TripleO. It control's the *DEFAULT/network_plugin_ipv6_enabled* parameter as well as *${share_backend_name}/network_plugin_ipv6_enabled* for some backends. Dockstrings [2] and [3] in the puppet module for these backends says the same as the Manila doc[1].
A note in Manilla doc[1] reading: """ The ip version of the share network is defined by the flags of network_plugin_ipv4_enabled and network_plugin_ipv6_enabled in the manila.conf configuration since Pike. The network_plugin_ipv4_enabled default value is set to True. The network_plugin_ipv6_enabled default value is set to False. If network_plugin_ipv6_enabled option is True, the value of network_plugin_ipv4_enabled will be ignored, it means to support both IPv4 and IPv6 share network.
"""
Is there a downside in simply enabling IPv6 by default in Manila? Why is this option present at all?
Why present: historically, some Manila backends only supported exporting and mounting file shares over IPv4 share networks, but then added IPv6 capabilities and needed configuration for their Manila drivers. Those drivers went down different code paths depending on whether IPv6 capability was enabled or not.
Why default False: backwards compatibility. If the back storage itself, outside of OpenStack proper, hadn't been upgraded or configured to support IPv6, leaving the configuration toggle False ensured that the Manila driver wouldn't treat the backend device as having capabilities that it lacked.
Can we remove this option now? Maybe. As you observe, it seems really to only be used nowadays by Dell-EMC drivers. We can check current requirements with the folks who use these drivers and see if the option is still needed. Even if it is, we might be able to toggle it different means than this THT/puppet variable. That said, Manila follows a deprecate in one release, remove/change in the following policy with regard to configuration option changes (removal of options or change in their default values in manila.conf proper).
Goutham Pacha Ravi (Manila PTL) and I talked about this and were going to ask if it would make sense to leave the parameter as is in the review in question but make a LP Bug calling for its removal. We can then deprecate and remove the manila configuration variable it controls, or control it by other means, but follow our normal configuration change procedures.
We have by the way independent motivation to remove the THT/puppet parameter anyways, namely that it has global scope for Manila but is being used for back end specific configuration. That didn't matter for TripleO when it only supported configuring a single Manila back end but that single back end limitation is getting removed.
-- Tom Barron
Thanks Tom! It makes sense to not change this in TripleO for now then. -- Harald
[1] https://docs.openstack.org/manila/latest/admin/shared-file-systems-network-p... [2] https://opendev.org/openstack/puppet-manila/src/branch/master/manifests/back... [3] https://opendev.org/openstack/puppet-manila/src/branch/master/manifests/back...
-- Harald Jensås
participants (2)
-
Harald Jensås
-
Tom Barron