skorchir commented on issue #14168: URL: https://github.com/apache/cloudstack/issues/14168#issuecomment-5708563685
Both questions checked at tag 4.22.1.1. ### On the NSX/Netris question The dates rule intent out. The guard arrived in #6425, merged 2022-09-10 for 4.18.0.0; the NSX plugin landed 2024-03-08 (#7919, 4.20.0) and Netris 2025-07-25 (#10458, 4.21.0). `checkNetworkDns` is textually unchanged since that merge (`NetworkServiceImpl.java:651`). Neither plugin serves DNS anyway. Neither plugin tree reads a network's DNS fields at all. NSX points a DHCP relay at the VPC VR's tier NIC (`NsxGuestNetworkGuru.java:244-248`); Netris disables DHCP on every vnet gateway it creates (`NetrisApiClientImpl.java:1890`). Both elements implement `DhcpServiceProvider`/`DnsServiceProvider` as `return true` no-ops, and the shipped default offerings map Dhcp/Dns/UserData to `VPCVirtualRouter` (`ConfigurationServerImpl.java:1256`, `VpcManagerImpl.java:440`). On both, the VPC VR is the DNS server. Nothing forces that mapping for an admin-created NSX/Netris offering, so I would narrow rather than delete: refuse only when the tier's Dns provider is not the VR, using the helper the render path already asks — `isProviderSupportServiceInNetwork(network.getId(), Service.Dns, Provider.VPCVirtualRouter)` (`CommandSetupHelper.java:1199`). At create there is no network id yet, so the offering's service→provider map is the equivalent; the offering check at `NetworkServiceImpl.java:660` is currently dead for tiers because the `vpcId` throw precedes it. ### On inherit-vs-explicit A correction to my report first: nothing copies the VPC's DNS onto a tier row at create. #8621 (4.19.1.0) added a read-time fallback only, and tier rows are NULL by construction because of the guard. `getNetworkIp4Dns`/`getNetworkIp6Dns` already resolve row → VPC → zone (`NetworkModelImpl.java:2750` and `:2764`), so NULL already means "follow the VPC" on every render path I traced. One row-direct reader is harmless: `NetworkOrchestrator.updateRouterDefaultDns` (`:464`) reads the VPC row for a VPC router, never a tier. The problem is `applyProfileToNetwork` (`NetworkOrchestrator.java:1389`), which persists the resolved dns1/dns2 back onto the network row on every successful `shutdownNetwork` (`:3241`). GC reaches it when the last VM leaves a tier on a non-persistent offering (`NetworkDaoImpl.findNetworksToGarbageCollect`, `:540-547`), baking the VPC's or zone's IPv4 into the row; ip6 is not written, so the two families diverge. Proposed design: - NULL on a tier means "follow the VPC"; an explicit tier value wins. Resolution order unchanged. - Stop persisting dns1/dns2 in `applyProfileToNetwork`: the profile value is already the resolved row → VPC → zone answer, recomputed on every render, so the write-back adds nothing and only collapses the NULL. If dropping it outright is too broad, skip the write when the row's dns1 was NULL going in. - Add the four dns params to `UpdateVPCCmd` (six today, none DNS) plus a `checkVpcDns` call on the update path, and cascade by re-rendering tiers whose DNS is NULL. A no-cleanup tier restart sends no `SetupGuestNetworkCommand` once the router is attached (`VpcVirtualRouterElement.java:253`), and cleanup restart is refused on a tier, so the cascade has to run through the whole-VPC restart (`VpcManagerImpl.java:2454`). - Data step: tier rows should be NULL except where the bake hit them; I checked the API and orchestration write paths, not upgrade SQL. Nulling rows whose dns1 equals their VPC's or the zone's restores inheritance but moves DNS for anyone relying on the baked value; leaving them keeps today's behaviour at the cost of tiers that look explicit without anyone asking. I traced the bake statically only and could not say how often it fires in practice. As the triage note suggests, the guard narrowing and the updateVPC cascade are independent and could land as two PRs. -- 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]
