skorchir opened a new issue, #14168:
URL: https://github.com/apache/cloudstack/issues/14168
As a user of VPCs I would like to set custom DNS servers on an individual
VPC tier, with the VPC's DNS as the default when a tier has none, and I would
like to change a VPC's DNS after creation via `updateVPC`. Today both are
refused, while isolated networks already support both, and the VPC virtual
router already renders DNS per tier interface.
### Current behaviour (4.22.1.1, verified against a live install and source)
| Call | Result |
|---|---|
| `createVPC` with `dns1`/`dns2` | accepted; tiers created afterwards
inherit the values (since #8621) |
| `createNetwork` with `vpcid` + `dns1`/`dns2` | refused: `DNS can not be
specified for a VPC tier` |
| `updateNetwork` on a tier + `dns1`/`dns2` | refused with the same message,
asynchronously (job fails) |
| `updateVPC` + `dns1`/`dns2` | parameters do not exist; the values are
ignored and the VPC keeps its original DNS |
| `updateNetwork` on an **isolated** network + `dns1`/`dns2` | accepted; the
row is updated and the network is restarted to re-render the VR |
### Why this looks like an oversight rather than a design limit
1. **The feature's own PR says tiers were in scope.** #6425 (4.18) describes
itself as adding custom DNS "for isolated network, shared network and VPC
tier", and its Marvin test is named `test_network_vpc_custom_dns.py`. The
refusal for tiers has nonetheless been present since 4.18.0.0. I could not find
a review comment on #6425 explaining the exclusion.
2. **The refusal is a single unconditional check**, not a setting or an
offering capability. `NetworkServiceImpl.checkNetworkDns`:
```java
if (vpcId != null) {
throw new InvalidParameterValueException("DNS can not be specified
for a VPC tier");
}
```
It is reached from both `createNetwork` and, via
`checkAndUpdateNetworkDns`, from `updateNetwork`.
3. **Everything downstream of the check already handles per-tier DNS:**
- Tier networks are rows in the same `networks` table as isolated
networks, with the same `dns1`/`dns2`/`ip6_dns1`/`ip6_dns2` columns. Since
#8621 the VPC's values are written into each tier row at create.
- `NetworkModelImpl.getNetworkIp4Dns` resolves network row → VPC → zone,
so a tier with its own value already takes precedence over the VPC value.
- `CommandSetupHelper` passes the resolved DNS to the VR per guest
network, and the VR renders one `dhcp-option=tag:interface-ethN,6,...` line per
tier interface. The dnsmasq config pasted in #8621 shows three tiers of one VPC
with two different resolver lists.
- `checkAndUpdateNetworkDns` already diffs, writes the row and flags a
restart; for a tier it only fails because it calls the same check.
For the tier half, the change appears to be: remove the `vpcId != null`
branch, expose the fields in the UI's tier forms, and confirm that a
(non-cleanup) tier restart re-renders the tier's dnsmasq options. I have not
verified that last point.
### What is genuinely missing (the VPC half)
- `updateVPC` has no `dns1`/`dns2`/`ip6dns1`/`ip6dns2` parameters.
- Because #8621 **copies** the VPC's DNS into each tier row at create, a
later VPC change cannot tell a tier that inherited the value from one that set
the same value explicitly. A cascade needs an "inherit" representation, for
example NULL on the tier meaning "follow the VPC", with `getNetworkIp4Dns`
already providing the fallback. That is a small design decision rather than a
guard removal, and the reason I am filing this as a request rather than a PR.
### Proposed behaviour
- `createNetwork` / `updateNetwork` on a VPC tier accept `dns1`/`dns2` (and
the IPv6 pair where the tier is IPv6-enabled), subject to the offering carrying
the `Dns` service exactly as isolated networks are.
- A tier with no DNS of its own follows the VPC; a tier with DNS set keeps
its own.
- `updateVPC` accepts `dns1`/`dns2`/`ip6dns1`/`ip6dns2`; tiers that follow
the VPC pick up the change; the change is applied to running routers on VPC
restart, as the isolated-network update does today.
- Semantics as for isolated networks: the new values reach guests on their
next DHCP lease, so running guests see them after a renew or reboot.
### Question for maintainers
If the tier refusal exists to protect a configuration where tiers are not
served by the VPC VR (for example NSX or Netris backed VPCs), then the request
is to narrow the check to those providers rather than to all VPCs.
Versions checked: 4.18.0.0, 4.19.0.0, 4.22.1.1, 4.23.0.0 (the check is
identical in all four).
Related: #6425 (adds custom DNS, 4.18), #8598 / #8621 (tiers inherit VPC
DNS, 4.19).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
