Allow DNS on VPC tiers (override) and make VPC DNS updatable via updateVPC

Start with NetworkServiceImpl.checkNetworkDns and checkAndUpdateNetworkDns, then trace NetworkModelImpl.getNetworkIp4Dns and CommandSetupHelper. Review the test_network_vpc_custom_dns.py coverage and the updateVPC and tier UI entry points. Done means tier DNS can override or inherit VPC DNS, updateVPC supports IPv4/IPv6 DNS, and router rendering and restart behavior are verified.

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)

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:

   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).