Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1708755

Summary: ctlplane-subnet always created
Product: Red Hat OpenStack Reporter: Ian Pilcher <ipilcher>
Component: openstack-tripleo-heat-templatesAssignee: Emilien Macchi <emacchi>
Status: CLOSED ERRATA QA Contact: Sasha Smolyak <ssmolyak>
Severity: medium Docs Contact:
Priority: medium    
Version: 14.0 (Rocky)CC: aschultz, beth.white, bfournie, cjeanner, hbrock, hjensas, jslagle, mburns
Target Milestone: z2Keywords: TestOnly, Triaged, ZStream
Target Release: 14.0 (Rocky)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-tripleo-heat-templates-9.3.1-0.20190314162760.d0a6cb1.el7ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-07-02 20:08:44 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:
Attachments:
Description Flags
undercloud.conf none

Description Ian Pilcher 2019-05-10 18:42:33 UTC
Created attachment 1566764 [details]
undercloud.conf

New OSP 14 deployment with routed control plane (provisioning) network.  I would like to have the local subnet (local_subnet in undercloud.conf) named simply "ctlplane" (rather than the default "ctlplane-subnet"), so that the subnet name with match the segment/provider:physical_network name.

To that end, I've got the following in my undercloud.conf:

local_subnet = ctlplane
subnets = ctlplane,ctlplane-remote

#[ctlplane-subnet]

[ctlplane]
cidr = 192.168.19.0/24
dhcp_start = 192.168.19.101
dhcp_end = 192.168.19.200
inspection_iprange = 192.168.19.51,192.168.19.100
gateway = 192.168.19.254
masquerade_network = False

[ctlplane-remote]
cidr = 192.168.119.0/24
dhcp_start = 192.168.119.101
dhcp_end = 192.168.119.200
inspection_iprange = 192.168.119.51,192.168.119.100
gateway = 192.168.119.254
masquerade_network = False

(Note that the [ctlplane-subnet] section is commented out.)

Despite this, the ctlplane-subnet subnet and network segment are being created, with the derault 192.168.24.0/24 network address:

$ openstack network segment list -c Name -c Network
+-----------------+--------------------------------------+
| Name            | Network                              |
+-----------------+--------------------------------------+
| ctlplane-remote | 8bbf86d6-893d-4212-b74b-d4396b641e7e |
| ctlplane-subnet | 8bbf86d6-893d-4212-b74b-d4396b641e7e |
| ctlplane        | 8bbf86d6-893d-4212-b74b-d4396b641e7e |
+-----------------+--------------------------------------+

$ openstack subnet list -c Name -c Network -c Subnet
+-----------------+--------------------------------------+------------------+
| Name            | Network                              | Subnet           |
+-----------------+--------------------------------------+------------------+
| ctlplane        | 8bbf86d6-893d-4212-b74b-d4396b641e7e | 192.168.19.0/24  |
| ctlplane-subnet | 8bbf86d6-893d-4212-b74b-d4396b641e7e | 192.168.24.0/24  |
| ctlplane-remote | 8bbf86d6-893d-4212-b74b-d4396b641e7e | 192.168.119.0/24 |
+-----------------+--------------------------------------+------------------+

$ openstack network show ctlplane -f json -c segments 
{
  "segments": [
    {
      "provider:network_type": "flat", 
      "provider:physical_network": "ctlplane-remote", 
      "provider:segmentation_id": null
    }, 
    {
      "provider:network_type": "flat", 
      "provider:physical_network": "ctlplane", 
      "provider:segmentation_id": null
    }, 
    {
      "provider:network_type": "flat", 
      "provider:physical_network": "ctlplane-subnet", 
      "provider:segmentation_id": null
    }
  ]
}

It looks like the existence of "ctlplane-subnet" is effectively hardcoded in ${THT}/environments/undercloud.yaml:

  UndercloudCtlplaneSubnets:
    ctlplane-subnet:
      NetworkCidr: '192.168.24.0/24'
      NetworkGateway: '192.168.24.1'
      DhcpRangeStart: '192.168.24.5'
      DhcpRangeEnd: '192.168.24.24'

I.e. there's no way to get rid of the ctlplane-subnet via undercloud.conf.

Comment 1 Ian Pilcher 2019-05-12 15:46:57 UTC
Looks like the existence of ctlplane-subnet is also hardcoded in the validations:

StackValidationFailed: Property error: resources.ControlVirtualIP.properties.fixed_ips[0].subnet: Error validating value 'ctlplane-subnet': Unable to find subnet with name or id 'ctlplane-subnet'

Comment 3 Cédric Jeanneret 2019-05-15 10:17:15 UTC
Hello,

I've just checked the latest content in Rocky, apparently you can change that name by setting the UndercloudCtlplaneLocalSubnet value in the tripleo-heat-templates. At least it's present in environments/undercloud.yaml

In addition, the block you pasted is a comment (at least in my local tree), and not involved in the actual deploy.

Grep'ing in the t-h-t, we can also find how to override that for the overcloud, via ControlPlaneSubnet setting.

Care to provide the openstack-tripleo-heat-templates package version?

Cheers,

C.

Comment 5 Ian Pilcher 2019-05-17 15:06:10 UTC
(In reply to Cédric Jeanneret from comment #3)
> I've just checked the latest content in Rocky, apparently you can change
> that name by setting the UndercloudCtlplaneLocalSubnet value in the
> tripleo-heat-templates. At least it's present in environments/undercloud.yaml

Yeah.  The issue (from my POV) is that the comments in undercloud.conf imply that you can change it there, and I think that this did work in OSP 13.

> In addition, the block you pasted is a comment (at least in my local tree),
> and not involved in the actual deploy.

It's certainly not a comment in /usr/share/openstack-tripleo-heat-templates/environments/undercloud.yaml.  It's at line 135.

> Grep'ing in the t-h-t, we can also find how to override that for the
> overcloud, via ControlPlaneSubnet setting.

Yeah.  I'm sure it can be changed by passing an environment file during the undercloud install.

> Care to provide the openstack-tripleo-heat-templates package version?

openstack-tripleo-heat-templates-9.3.1-0.20190314162760.d0a6cb1.el7ost.noarch

Honestly, the more I futz with this, the more I think we should dispense with trying to set up multiple network segments during the undercloud install.  Let the operator do that via the CLI after the undercloud is set up.

Comment 6 Harald Jensås 2019-05-20 15:40:22 UTC
This should have been fixed with: https://review.opendev.org/644849

Comment 7 Harald Jensås 2019-05-20 15:57:04 UTC
(In reply to Harald Jensås from comment #6)
> This should have been fixed with: https://review.opendev.org/644849

To follow up, this is in the downstream git repository as well:
https://code.engineering.redhat.com/gerrit/gitweb?p=openstack-tripleo-heat-templates.git;a=blob;f=environments/undercloud.yaml;h=4d889b68fdc53b8fd543e4d14c82fc7c5b314e43;hb=refs/heads/rhos-14.0-patches#l149

In OSP 13 this did work, the regression was introduced when containerizing the undercloud in OSP14.

Comment 8 Bob Fournier 2019-05-20 16:12:23 UTC
Fix delivered in OSP-14z2, so moving this to ON_QA and TestOnly.

Comment 11 errata-xmlrpc 2019-07-02 20:08:44 UTC
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/RHBA-2019:1672