Bug 1671766

Summary: Network isolation doesn't work for the 2nd stack when deploying multiple overcloud stacks from the same undercloud
Product: Red Hat OpenStack Reporter: Marius Cornea <mcornea>
Component: documentationAssignee: Alex McLeod <amcleod>
Status: CLOSED CURRENTRELEASE QA Contact: RHOS Documentation Team <rhos-docs>
Severity: urgent Docs Contact:
Priority: medium    
Version: 15.0 (Stein)CC: amcleod, aschultz, atragler, dbecker, dcadzow, jrouleau, mburns, mcornea, morazi, pgrist
Target Milestone: beta   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-07-11 13:51:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1241596    
Attachments:
Description Flags
stack.tar.gz
none
working_templates.tar.gz none

Description Marius Cornea 2019-02-01 15:05:50 UTC
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).

Comment 1 Marius Cornea 2019-02-01 15:08:27 UTC
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)

Comment 2 Jill Rouleau 2019-02-04 19:49:13 UTC
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.

Comment 3 Marius Cornea 2019-02-05 16:32:43 UTC
(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

Comment 4 Jill Rouleau 2019-02-07 16:18:24 UTC
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'}]

Comment 5 Jill Rouleau 2019-02-11 16:25:44 UTC
@mcornea, does the info in Comment 4 help?

Comment 6 Marius Cornea 2019-02-13 01:54:41 UTC
(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.

Comment 7 Marius Cornea 2019-02-13 01:55:20 UTC
Created attachment 1534282 [details]
working_templates.tar.gz

Uploading the templates that worked during for my test.

Comment 13 Red Hat Bugzilla 2023-09-14 04:46:09 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days