Open Stack

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-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
> > 
> >