Description of problem: Network isolation doesn't work for the 2nd stack when deploying multiple overcloud stacks from the same undercloud. I tried changing the vlans(where applicable) and subnets of the isolated network for the 2nd stack and I got the following results: 1/ I had to pass /usr/share/openstack-tripleo-heat-templates/environments/networks-disable.yaml to the 2nd stack otherwise it fails trying to re-create the isolated networks 2/ Next it failed with: overcloud2.PublicVirtualIP.ExternalPort: resource_type: OS::Neutron::Port physical_resource_id: status: CREATE_FAILED status_reason: | InvalidIpForNetworkClient: resources.ExternalPort: IP address 10.0.1.101 is not a valid IP for any of the subnets on the specified network. Neutron server returns request_ids: ['req-c87a2eee-87f5-4e76-9b60-758ee54d2111'] Note that I am passing the following parameters for the 2nd stack: PublicVirtualFixedIPs: [{'ip_address':'10.0.1.101'}] ExternalNetCidr: 10.0.1.0/24 ExternalAllocationPools: - end: 10.0.1.149 start: 10.0.1.101 Nevertheless the neutron 'external' network has only one subnet assigned(the one used for the 1st stack) and the subnet used for the 2nd stack is not present. (undercloud) [stack@undercloud-0 ~]$ openstack network show external -f json | jq .subnets "749b1f90-262f-476d-b7d5-792470b42de1" (undercloud) [stack@undercloud-0 ~]$ openstack subnet show 749b1f90-262f-476d-b7d5-792470b42de1 -f json { "service_types": "", "description": "", "enable_dhcp": false, "segment_id": null, "network_id": "b6ce6f7b-a020-409d-a784-9d5d362b8c47", "created_at": "2019-02-01T02:44:37Z", "tags": "", "dns_nameservers": "", "updated_at": "2019-02-01T02:44:37Z", "ipv6_ra_mode": null, "allocation_pools": "10.0.0.101-10.0.0.149", "gateway_ip": "10.0.0.1", "revision_number": 0, "ipv6_address_mode": null, "ip_version": 4, "host_routes": "", "cidr": "10.0.0.0/24", "project_id": "8781a417d052441387584eca4183312d", "id": "749b1f90-262f-476d-b7d5-792470b42de1", "subnetpool_id": null, "name": "external_subnet" 3/ If I remove the PublicVirtualFixedIPs parameter deployment moves further but the nodes get assigned IP addresses from the subnets used for the 1st stack, not the new ones defined for the 2nd stack(except ExternalInterfaceDefaultRoute).
Created attachment 1525860 [details] stack.tar.gz Attaching the templates used for the 1st stack(overcloud_deploy.sh) and the 2nd stack(overcloud_deplo2.sh)
You'll probably also need a new network_data.yaml for the second stack with unique names for the InternalApi, Management, etc nets. Running through this with your deploy script in my lab now.
(In reply to Jill Rouleau from comment #2) > You'll probably also need a new network_data.yaml for the second stack with > unique names for the InternalApi, Management, etc nets. Running through this > with your deploy script in my lab now. I tried that in a previous attempt but the 2nd stack deployment also failed because because we hardcode the network names e.g: ExternalNetName, InternalApiNetName in: https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/all-nodes-config.j2.yaml#L197-L241
You should be able to provide a network_data file that specifies a new name_lower value for each of those networks. With just doing internal_api, looks like: http://paste.openstack.org/show/744652/ network_data_cloud1.yaml: - name: InternalApi name_lower: internal_api_cloud_1 service_net_map_replace: internal_api vip: true vlan: 20 ip_subnet: '172.17.0.0/24' allocation_pools: [{'start': '172.17.0.4', 'end': '172.17.0.250'}] ipv6_subnet: 'fd00:fd00:fd00:2000::/64' ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:2000::10', 'end': 'fd00:fd00:fd00:2000:ffff:ffff:ffff:fffe'}] network_data_cloud2.yaml: - name: InternalApi name_lower: internal_api_cloud_2 service_net_map_replace: internal_api vip: true vlan: 20 ip_subnet: '172.21.0.0/24' allocation_pools: [{'start': '172.21.0.4', 'end': '172.21.0.250'}] ipv6_subnet: 'fd00:fd00:fd00:2000::/64' ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:2000::10', 'end': 'fd00:fd00:fd00:2000:ffff:ffff:ffff:fffe'}]
@mcornea, does the info in Comment 4 help?
(In reply to Jill Rouleau from comment #5) > @mcornea, does the info in Comment 4 help? Thanks Jill and sorry for the delayed response. Your suggestion worked, I guess we need to cover this change in the documentation for this feature.
Created attachment 1534282 [details] working_templates.tar.gz Uploading the templates that worked during for my test.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days