Description of problem: ======================= Octavia creates Amphorae (service VMs) under an operator configured project (tenant). In TripleO, we currently use 'service' project by default. Each Amphora instance has its own tap device in a shared management subnet named lb-mgmt-subnet. That subnet is concealed under the 'service' project and cannot be accessed by non-privileged users. TripleO creates that subnet during the Octavia deployment process. Currently, it is created as a class B subnet with allocation_pools that essentially limit the number of address in that subnet to 150. Which means, globally for a given OpenStack deployment: - 150 Amphorae ==> 150 Loadbalancers if the Amphora topology is SINGLE - 150 Amphorae ==> 75 Loadbalancers if the Amphora topology is ACTIVE_STANDBY Here's how it currently looks (snipped): +-------------------+--------------------------------------+ | Field | Value | +-------------------+--------------------------------------+ | allocation_pools | 192.168.199.50-192.168.199.200 | | cidr | 192.168.199.0/24 | | created_at | 2018-05-07T09:14:36Z | | enable_dhcp | True | | gateway_ip | 192.168.199.1 | | ip_version | 4 | | name | lb-mgmt-subnet | +-------------------+--------------------------------------+ Version-Release number of selected component (if applicable): ============================================================= OSP13 2018-05-10.3 openstack-tripleo-common-8.6.1-9 How reproducible: ================= 100% Steps to Reproduce: 1. Deploy OpenStack with Octavia via TripleO 2. 3. Actual results: =============== As mentioned above. Expected results: ================= We should have a much larger subnet such as class B, so the global amount of Octavia loadbalancers won't constrained to a very low number.
Current config: https://github.com/openstack/tripleo-common/blob/53513666974657f120def7811c95b36a30782b89/playbooks/roles/common/defaults/main.yml#L11-L14
Minor correction to the 'Description of problem': class C instead of class B.
Manually patched undercloud with Nir's patches. It works. (overcloud) [stack@undercloud-0 ~]$ openstack subnet show lb-mgmt-subnet +-------------------+--------------------------------------+ | Field | Value | +-------------------+--------------------------------------+ | allocation_pools | 172.20.0.2-172.20.255.254 | | cidr | 172.20.0.0/16 | | created_at | 2018-05-15T16:46:19Z | | description | | | dns_nameservers | | | enable_dhcp | True | | gateway_ip | 172.20.0.1 | | host_routes | | | id | 8b1dbae1-1cbd-4b65-b651-049d6fbd3751 | | ip_version | 4 | | ipv6_address_mode | None | | ipv6_ra_mode | None | | name | lb-mgmt-subnet | | network_id | 1306567e-c415-4eb7-9274-78fea5acb8f3 | | project_id | 18cae82661624a12bd4c5b908044fcea | | revision_number | 0 | | segment_id | None | | service_types | | | subnetpool_id | None | | tags | | | updated_at | 2018-05-15T16:46:19Z | +-------------------+--------------------------------------+ [heat-admin@controller-0 ~]$ ip a show dev o-hm0 55: o-hm0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:c7:b7:6f brd ff:ff:ff:ff:ff:ff inet 172.20.0.9/16 brd 172.20.255.255 scope global o-hm0 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fec7:b76f/64 scope link valid_lft forever preferred_lft forever
*** Bug 1577611 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:2086