routed.network.vpc.enabled gates BGP / routed-isolated-network APIs (not VPC-specific); disabling VPC silently removes them with a misleading error

[jball-resetdata]

CloudStack GitHub issue — FINAL (v5): routed/BGP APIs gated by a VPC-named flag; silent + misleading

Title: routed.network.vpc.enabled gates BGP / routed-isolated-network APIs (not VPC-specific); disabling VPC silently removes them with a misleading error

Summary

The global setting routed.network.vpc.enabled ("If true, the Routed network and VPC are enabled in the zone.") gates a large set of APIs that are not VPC-specific — the entire BGP dynamic-routing and routed-isolated-network command set. When it is false, RoutedIpv4ManagerImpl.getCommands() returns an empty list, so ~42 commands never register with API Discovery:

createASNRange, createBgpPeer, updateBgpPeer, deleteBgpPeer, listBgpPeers, dedicateBgpPeer, releaseBgpPeer, changeBgpPeersForNetwork, changeBgpPeersForVpc, listASNRanges, listASNumbers, releaseASNumber, createIpv4SubnetForZone / ...ForGuestNetwork (+ list/update/delete/dedicate/release variants), routing-firewall-rule commands, etc.

There are two problems:

1. Conflation of two independent features under one VPC-named flag

Routed isolated networks with BGP dynamic routing are a distinct capability from VPC. An operator who wants BGP-routed isolated networks but does not want to offer VPC (a common, reasonable posture) has no way to enable one without the other. Disabling VPC via this flag also disables routed isolated networks + all BGP/ASN APIs. A VPC toggle should not gate non-VPC functionality; these should be separately controllable (or the flag renamed/split, e.g. routed.network.enabled vs vpc.enabled).

2. Silent removal + misleading error (major debugging cost)

When the flag is false:

• The ~42 commands are absent from listApis with no indication why.
• Calling one returns "The given command createASNRange either does not exist, is not available for user, or not available from ip address ..." and listApis name=createASNRange returns HTTP 530 "Api Discovery plugin was unable to find an api by that name."
• The startup log still shows RoutedIpv4ManagerImpl registering as an extension and being "Discovered" — so everything looks fine.

None of these mention that a feature toggle is responsible. There is no "this API is disabled because routed.network.vpc.enabled=false" message. This makes the cause extremely hard to find — the symptoms all point at a broken/missing feature or a permissions problem, not a config flag. (In our case it took an extensive investigation before locating the gate in RoutedIpv4ManagerImpl.getCommands().)

Reproduce

1. Any CloudStack 4.20+ (confirmed 4.22.0.0 and 4.22.1.0).
2. Set global routed.network.vpc.enabled = false (or disable VPC in a way that sets it false) and restart the management server.
3. As root admin: listApis — the BGP/ASN/Ipv4-subnet commands are gone; listApis name=createBgpPeer → 530; calling createBgpPeer → "not available for user".
4. Set routed.network.vpc.enabled = true, restart — the commands reappear.

Mechanism: server/src/main/java/org/apache/cloudstack/network/RoutedIpv4ManagerImpl.java, getCommands():

public List<Class<?>> getCommands() {
    final List<Class<?>> cmdList = new ArrayList<>();
    if (!RoutedNetworkVpcEnabled.value()) {   // "routed.network.vpc.enabled"
        return cmdList;                         // hides ALL routed/BGP/ASN/IPv4-subnet commands
    }
    ...
}

Suggested fixes

1. Separate the toggles — a distinct enable for routed isolated networks / BGP dynamic routing, independent of VPC (or rename routed.network.vpc.enabled and split it), so BGP-routed-without-VPC is possible.
2. Make the disabled state discoverable — when a command is unavailable due to a feature flag, return an error that names the flag (e.g. "API disabled; set routed.network.vpc.enabled=true"), rather than the generic "does not exist / not available for user". At minimum, document that this flag gates the BGP/ASN/routed-subnet API set.

Environment

Observed on CloudStack 4.22.1.0 and 4.22.0.0 (stock, download.cloudstack.org, Ubuntu 24.04, OpenJDK 17, MariaDB 10.11), KVM. The gating code is identical across these versions — it is a config-flag behaviour, not version-specific.

[jball-resetdata]

i'll do a PR on this a little later - busy actually bring up a new prod instance.