StorageNFS allocation pool is too big

Bug #1889682 reported by Tom Barron on 2020-07-30
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
Medium
Tom Barron

Bug Description

 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.

Tom Barron (tpb) on 2020-07-30
Changed in tripleo:
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Tom Barron (tpb)
milestone: none → victoria-3
Changed in tripleo:
status: Triaged → In Progress

Reviewed: https://review.opendev.org/743609
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=4e8a05833cb9679bc6140839305d075389dc4822
Submitter: Zuul
Branch: master

commit 4e8a05833cb9679bc6140839305d075389dc4822
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_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

Changed in tripleo:
status: In Progress → Fix Released

Reviewed: https://review.opendev.org/749048
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=6efb29dcc7294a289a78cf380b14eaf146a1a49e
Submitter: Zuul
Branch: stable/ussuri

commit 6efb29dcc7294a289a78cf380b14eaf146a1a49e
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_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)

tags: added: in-stable-ussuri

Reviewed: https://review.opendev.org/749399
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=688b59301dd880bc15da7539dd9c5b7946903346
Submitter: Zuul
Branch: stable/train

commit 688b59301dd880bc15da7539dd9c5b7946903346
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_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)

tags: added: in-stable-train

Reviewed: https://review.opendev.org/753608
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=49f1396d6048a0c0e297f3f889a6f816bb67a321
Submitter: Zuul
Branch: stable/queens

commit 49f1396d6048a0c0e297f3f889a6f816bb67a321
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_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)

tags: added: in-stable-queens

Reviewed: https://review.opendev.org/753603
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=9862730ce282ac135a7361879e927d35bfd66fda
Submitter: Zuul
Branch: stable/rocky

commit 9862730ce282ac135a7361879e927d35bfd66fda
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_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)

tags: added: in-stable-rocky

This issue was fixed in the openstack/tripleo-heat-templates 11.4.0 release.

This issue was fixed in the openstack/tripleo-heat-templates rocky-eol release.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers