nagaboinaramgopal commented on PR #14144: URL: https://github.com/apache/cloudstack/pull/14144#issuecomment-5682929402
Thanks for this, the change looks right for the private gateway case. I tried it on a KVM zone. Without the change, `createPrivateGateway` with `vlan=vxlan://5005` fails with `unsupported type of broadcastUri specified: vxlan://5005`. With the change, on a physical network with VXLAN isolation, `vxlan://6005` works: the private gateway is created, the network is stored with `vxlan://6005` and broadcast domain type `Vxlan`, and the router NIC is on `brvx-6005`, backed by a `vxlan6005` device on the host. A couple of questions, in case they are useful: 1. The Vlan type seems to come from `NetworkOrchestrator.createGuestNetwork`, which calls `setBroadcastDomainType(BroadcastDomainType.Vlan)` for any non-untagged vlan id regardless of the URI scheme. Correcting it in `PrivateNetworkGuru.design` works for private gateways. Was setting the type from the URI scheme there considered, or is the guru used on purpose to keep the change to this path? 2. `createPrivateNetwork` now also accepts a `vxlan://` URI on a physical network with VLAN isolation. I tried `vxlan://5006` on a VLAN physical network: the gateway is created, the network is stored as `Vxlan`, and the router gets a NIC on `brvx-5006` backed by a `vxlan5006` device on the host. Would it make sense to check the isolation method of the physical network and reject a `vxlan://` URI when it is not VXLAN (and the other way round)? -- 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]
