Open Stack

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-plugins.html
>[2]
>https://opendev.org/openstack/puppet-manila/src/branch/master/manifests/backend/dellemc_vnx.pp#L48-L52
>[3]
>https://opendev.org/openstack/puppet-manila/src/branch/master/manifests/backend/dellemc_unity.pp#L49-L53
>
>--
>Harald Jensås
>
>