network_data_ganesha.yaml matches network_data.yaml except that it includes an additional StorageNFS isolated network definition. When deploying the overcloud with support for Manila backed by CephFS through NFS, customers are instructed to use '-n network_data_ganesha.yaml' or '-n' with a similarly modified network_data file with vlan values, mtus, CIDRs, etc. adapted to their actual deployment environment.
The IPv4 allocation range specified in network_data_ganesha.yaml mirrors those of the other networks defined in network_data.yaml in that it starts at address 4 and goes to address 250 in a /24 CIDR. This is a problem for StorageNFS since this isolated network is the basis of a Neutron provider Network in the overcloud where there is an independent DHCP service with its own allocation pool. Almost the whole CIDR is allocated in network_data_ganesha.yaml for the overcloud deployment itself, although in a default deployment with three nodes in the ControllerStorageNfs role only four addresses are needed -- one for the StorageNFS interface on each controller node, and one for the VIP where the NFS service is offered.
We should shrink the allocation pools for StorageNFS network as defined in network_data_ganesha.yaml and add comments explaining the need to leave a range of addresses for use by the Neutron provider network built on the StorageNFS isolated deployment network.
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: master
commit 4e8a05833cb9679
Author: Tom Barron <email address hidden>
Date: Tue Jul 28 14:04:07 2020 -0400
Use appropriate allocation pools for StorageNFS
The StorageNFS network was defined in network_
using allocation ranges that mirrored those of the other isolated
networks. But TripleO and the undercloud only need to use a small
number of addresses for overcloud deployment -- in the default
three-
each ControllerNfs role node, and one for the VIP on which the NFS
service is offered. The bulk of the addresses in the StorageNFS CIDR
should be left out of the allocation range defined in network_data
so that they can be used by the allocation pool for the overcloud
Netron StorageNFS provider network's subnet without danger of
overlap.
This change uses a CIDR with a shorter prefix so that there will
be sufficient IPs left over after the undercloud's TripleO allocation
pool to deploy almost 4000 clients on the Neutron StorageNFS provider
network's subnet.
This commit also includes some minor changes to synchronize
network_
was derived from the latter and should differ from it only by
inclustion of the StorageNFS network.
Closes-bug: #1889682
Change-Id: Ibb50dad42ec3dc