From 49f1396d6048a0c0e297f3f889a6f816bb67a321 Mon Sep 17 00:00:00 2001 From: Tom Barron Date: Tue, 28 Jul 2020 14:04:07 -0400 Subject: [PATCH] Use appropriate allocation pools for StorageNFS The StorageNFS network was defined in network_data_ganesha.yaml 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-controller case, one for the regular StorageNFS interface on 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_data_ganesha.yaml with network_data.yaml since the former was derived from the latter and should differ from it only by inclustion of the StorageNFS network. Closes-bug: #1889682 Change-Id: Ibb50dad42ec3dc154cd27ae9094a9be5d0a2dd28 (cherry picked from commit 4e8a05833cb9679bc6140839305d075389dc4822) (cherry picked from commit 6efb29dcc7294a289a78cf380b14eaf146a1a49e) (cherry picked from commit 688b59301dd880bc15da7539dd9c5b7946903346) (cherry picked from commit 2026fa444e3a93ca8c249f37aaa5820883265215) (cherry picked from commit 9862730ce282ac135a7361879e927d35bfd66fda) --- network_data_ganesha.yaml | 20 ++++++++++++++++--- ...-StorageNFS-net.yaml-bd77be924e8b7056.yaml | 20 +++++++++++++++++++ 2 files changed, 37 insertions(+), 3 deletions(-) create mode 100644 releasenotes/notes/fix-allocation-range-for-StorageNFS-net.yaml-bd77be924e8b7056.yaml diff --git a/network_data_ganesha.yaml b/network_data_ganesha.yaml index c18d343f10..6a20f47805 100644 --- a/network_data_ganesha.yaml +++ b/network_data_ganesha.yaml @@ -5,6 +5,9 @@ # name: Name of the network (mandatory) # name_lower: lowercase version of name used for filenames # (optional, defaults to name.lower()) +# service_net_map_replace: if name_lower is set to a custom name this should be set +# to original default (optional). This field is only necessary when +# changing the default network names, not when adding a new custom network. # enabled: Is the network enabled (optional, defaults to true) # NOTE: False will use noop.yaml for unused legacy networks to support upgrades. # vlan: vlan for the network (optional) @@ -106,7 +109,18 @@ vip: true name_lower: storage_nfs vlan: 70 - ip_subnet: '172.16.4.0/24' - allocation_pools: [{'start': '172.16.4.4', 'end': '172.16.4.250'}] + ip_subnet: '172.17.0.0/20' ipv6_subnet: 'fd00:fd00:fd00:7000::/64' - ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:7000::10', 'end': 'fd00:fd00:fd00:7000:ffff:ffff:ffff:fffe'}] + # This network is shared by the overcloud deployment and a Neutron provider network + # that is set up post-deployment for consumers like Nova VMs to use to mount shares. + # The allocation pool specified here is used for the overcloud deployment for interfaces + # on the ControllerStorageNfs role nodes and for the VIP where the Ganesha service itself is + # exposed. With a default three-controller node deployment, only four IPs are actually needed + # for this allocation pool. + # When you adapt this file for your own deployment you can of course change the /20 CIDR + # and adjust the allocation pool -- just make sure to leave a good-sized range outside the + # allocation pool specified here for use in the allocation pool for the overcloud Neutron + # StorageNFS provider network's subnet definition. + allocation_pools: [{'start': '172.17.0.4', 'end': '172.17.0.250'}] + ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:7000::4', 'end': 'fd00:fd00:fd00:7000::fffe'}] + mtu: 1500 diff --git a/releasenotes/notes/fix-allocation-range-for-StorageNFS-net.yaml-bd77be924e8b7056.yaml b/releasenotes/notes/fix-allocation-range-for-StorageNFS-net.yaml-bd77be924e8b7056.yaml new file mode 100644 index 0000000000..046a29b6fb --- /dev/null +++ b/releasenotes/notes/fix-allocation-range-for-StorageNFS-net.yaml-bd77be924e8b7056.yaml @@ -0,0 +1,20 @@ +--- +upgrade: + - | + The CIDR for the StorageNFS network in the sample network_data_ganesha.yaml file + has been modified to provide more usable IPs for the corresponding Neutron + overcloud StorageNFS provider network. Since the CIDR of an existing network + cannot be modified, deployments with existing StorageNFS networks should be + sure to customize the StorageNFS network definition to use the same CIDR + as that in their existing deployment in order to avoid a heat resource failure + when updating or upgrading the overcloud. +fixes: + - | + Fixed issue in the sample network_data_ganesha.yaml file where the + IPv4 allocation range for the StorageNFS network occupies almost + the whole of its CIDR. If network_data_ganesha.yaml is used + without modification in a customer deployment then there are too + few IPs left over in its CIDR for use by the corresponding + overcloud Neutron StorageNFS provider network for its overcloud + DHCP service. + (See `bug: #1889682 `_) \ No newline at end of file