# Custom network names, name_lower, dns_domain, ...
## Issues

1. `network.name.lower()` vs `network.name_lower` - inconsistent usage
2. `network.name_lower` is customizable as shown in multi-overcloud doc[5]
3. FQDN is built from `network.name.lower()` - not possible to change without using custom network name.
4. `CloudDomain` vs `overcloud_domain_name`: `CloudDomain` shouldn't be exposed
5. Network-v2 has `dns_domain` property for network[1], but it is not used.
Could use dns_domain property in NetHostMap[4] if it is set?
6. inconsistency with `network.name_lower`: sometimes with CamelCase (in OSP doc[2], sometimes with my_super_name (in upstream doc[3])
7. `service_net_map_replace` does not work for all ServiceNetMap entries if using a custom `network.name`. (ResolveNetwork and QDRMetricNetwork).
9. doc is either absent, not precise enough or, worse, inconsistent
10. if we use `network.name_lower` instead of `network.name.lower()`, we will break existing deploys
11. if we use `network.name.lower()`, we will break an existing feature
12. the `network.name_lower` is wrongly named - should be more something like `network.custom_name`
13. Lot's of hard-coding in `tripleo_ansible/roles/tripleo_hieradata/templates/vip_data.j2`

## Issues mitigation, path forward
### Preflight validation
#### Domain consistency validation
A validation is needed in order to ensure we have the correct consistency with `overcloud_domain_name`, `CloudDomain` and potential `network.dns_domain`. This would allow us to be more confident when we're building FQDN, services URIs and so on.

The `overcloud_domain_name` is defined in the ctlplane network, on the Undercloud.

#### Network name in network-data and role-data
A validation ensuring role-data isn't using undefined network will also help ensuring we're able to deploy with more confidence.

### Deprecate some variables/parameters
#### CloudDomain
As previously stated, this parameter shouldn't be exposed, and we should take the actual value from the ctlplane network, as defined on the Undercloud. In order to do so, we can take the `dns_domain` value from the ctlplane network:

> **_NOTE:_** CloudDomain is likely used by Standalone.

(undercloud) [CentOS-8 - stack@undercloud ~]$ openstack network show ctlplane
+---------------------------+--------------------------------------+
| Field                     | Value                                |
+---------------------------+--------------------------------------+
| admin_state_up            | UP                                   |
| availability_zone_hints   |                                      |
| availability_zones        | nova                                 |
| created_at                | 2021-10-07T08:31:09Z                 |
| description               |                                      |
| dns_domain                | ctlplane.mydomain.tld.               | <====
| id                        | be432669-0346-45da-98a6-c45297868f1c |
| ipv4_address_scope        | None                                 |
| ipv6_address_scope        | None                                 |
| is_default                | None                                 |
| is_vlan_transparent       | None                                 |
| mtu                       | 1500                                 |
| name                      | ctlplane                             |
| port_security_enabled     | True                                 |
| project_id                | fake_project_id                      |
| provider:network_type     | flat                                 |
| provider:physical_network | ctlplane                             |
| provider:segmentation_id  | None                                 |
| qos_policy_id             | None                                 |
| revision_number           | 3                                    |
| router:external           | Internal                             |
| segments                  | None                                 |
| shared                    | False                                |
| status                    | ACTIVE                               |
| subnets                   | 5eaf8db6-de09-4cfc-93e5-a0eb60a563bd |
| tags                      | 192.168.24.0/24                      |
| updated_at                | 2021-10-07T08:31:10Z                 |
+---------------------------+--------------------------------------+

### Be stricter for format, consistency and needed parameters
#### network.name_lower
This variable has no fixed format, as previously discussed in the "Issues" part. In addition, its name is misleading...
#### dns_domain
It must match the `overcloud_domain_name` (and, by extension, `CloudDomain`).

## References
1. https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/custom_networks.html#network-data-yaml-options
2. https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/advanced_overcloud_customization/custom-composable-networks#renaming-default-networks_portal
3. https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/custom_networks.html
4. https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/puppet/role.role.j2.yaml#L368
5. https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/multiple_overclouds.html#deploying-additional-overclouds