jball-resetdata opened a new issue, #13745:
URL: https://github.com/apache/cloudstack/issues/13745
### problem
## Summary
On a **fresh install** of CloudStack, the entire **RoutedIpv4Manager** API
set — `createASNRange`, `createBgpPeer`,
`createIpv4SubnetForZone/GuestNetwork`, `listBgpPeers`, `dedicateBgpPeer`,
`changeBgpPeersForNetwork/Vpc`, etc. (~42 commands) — is **not callable and not
returned by `listApis`**. The zone has no "AS Number" tab. On an **upgraded**
install (older release migrated up to the same version) the identical command
set works.
The component registers as an extension at startup, but is **silently
skipped when `AccountManagerImpl` enumerates pluggable services to build the
API-command map**. Every other pluggable service is enumerated;
`RoutedIpv4ManagerImpl` is not.
## Environment
- **Broken (fresh):** management server **freshly installed at 4.22.1.0**
(KVM, Ubuntu 24.04/noble, stock packages from download.cloudstack.org,
unmodified). `apt` history = single `install cloudstack-management=4.22.1.0`;
`version` table = full fresh `cloudstack-setup-databases` seed (4.0.0→4.22.1.0,
all rows in one ~70s window). `listApis` returns **814** APIs.
- **Working (upgraded):** a separate mgmt server installed at 4.19.x,
upgraded 4.19 → 4.20.2.0 → 4.22.0.0 over time (apt shows the `Upgrade:
cloudstack-management (4.20.2.0, 4.22.0.0)` transition; version-table
timestamps span days). `listApis` returns **856** APIs — the 42-command delta
is exactly the RoutedIpv4Manager set. BGP/AS-Number work.
## Evidence
**Startup — component registers as an extension:**
```
[ExtensionRegistry] Registering extension [RoutedIpv4ManagerImpl] in [Api
Commands Registry]
[PluggableServiceLifecycle] Registered
org.apache.cloudstack.network.RoutedIpv4ManagerImpl
[ApiServer] Discovered plugin RoutedIpv4ManagerImpl
[ApiDiscoveryServiceImpl] getting api commands of service:
org.apache.cloudstack.network.RoutedIpv4ManagerImpl
```
**But — `AccountManagerImpl` enumerates every service to collect API
commands, and RoutedIpv4ManagerImpl is ABSENT from that list:**
```
[AccountManagerImpl] getting api commands of service:
org.apache.cloudstack.gpu.GpuServiceImpl
[AccountManagerImpl] getting api commands of service:
org.apache.cloudstack.backup.BackupManagerImpl
[AccountManagerImpl] getting api commands of service:
org.apache.cloudstack.storage.template.VnfTemplateManagerImpl
[AccountManagerImpl] getting api commands of service:
com.cloud.baremetal.manager.BaremetalManagerImpl
[AccountManagerImpl] getting api commands of service:
org.apache.cloudstack.diagnostics.DiagnosticsServiceImpl
... (RoutedIpv4ManagerImpl does NOT appear in this enumeration)
```
**Runtime rejection when calling the API (directly-signed, as root `admin`,
Root Admin `*` ALLOW):**
```
[ApiServer] The given command createASNRange either does not exist, is not
available for user,
or not available from ip address '0:0:0:0:0:0:0:1'.
```
`listApis name=createASNRange` → HTTP 530 "Api Discovery plugin was unable
to find an api by that name".
## Ruled out (with evidence)
- **Not a missing feature:** `CreateBgpPeerCmd` and routed classes are in
`cloudstack-4.22.1.0.jar`; the webapp JS references `createBgpPeer`.
- **Not schema/config:** tables `bgp_peers`, `bgp_peer_details`,
`bgp_peer_network_map`, `as_number`, `as_number_range` exist;
`network_offerings.routing_mode` column exists; `routed.*` global settings
present and enabled (`use.system.bgp.peers=true`, etc.).
- **Not RBAC/role_permissions:** both installs have **zero**
`role_permissions` rows for these commands; Root Admin = `*` ALLOW; correct
admin API key; `dynamic.apichecker.enabled=true`, `cache.period=0`.
- **Not client-side:** verified with a directly-signed HTTP API call
(signing confirmed correct — identical signing succeeds for `listZones`,
`listApis`).
- **Not a dirty/restored DB, not an upgrade artifact:** the broken install
is genuinely fresh (apt + version-table evidence). No custom build.
- **Restart + clearing cache/work dirs — no change.**
## Questions
1. What determines whether `AccountManagerImpl` enumerates a pluggable
service's API commands? Why is `RoutedIpv4ManagerImpl` enumerated on an
**upgraded** DB but not on a **fresh** one?
2. Is there a way to force this service's commands into the API map on a
fresh install (a config, a migration step to re-run) — without reinstalling?
3. Is installing an older release and upgrading (to run the migration path)
the recommended workaround until fixed?
Full startup logs and the fresh-vs-upgraded `listApis` diff available on
request.
### versions
Common to both installs:
- **OS:** Ubuntu 24.04.4 LTS (noble), kernel 6.8.0-134-generic, amd64
- **Java:** OpenJDK 17.0.19 (2026-04-21)
- **DB:** MariaDB 10.11.14
- **Hypervisor:** KVM / libvirt (Ubuntu 24.04)
- **Packages:** stock from `download.cloudstack.org/ubuntu noble/4.22`
(cloudstack-common / -management / -usage), unmodified management server.
- **Broken (FRESH install):** `cloudstack-management` **4.22.1.0**. `apt`
history = a single `install cloudstack-management=4.22.1.0` (no upgrade). DB
`version` table = a full fresh `cloudstack-setup-databases` seed (rows
4.0.0→4.22.1.0 all written within one ~70-second window). `listApis` returns
**814** APIs; RoutedIpv4Manager commands absent.
- **Working (UPGRADED):** a separate mgmt server first installed at
**4.19.3.0**, upgraded **4.19.3.0 → 4.20.2.0 → 4.22.0.0** over time (apt shows
the `Upgrade: cloudstack-management (4.20.2.0, 4.22.0.0)` transition;
`version`-table timestamps span days). `listApis` returns **856** APIs — the
**42-command delta is exactly the RoutedIpv4Manager / BGP / ASN / IPv4-subnet
set**. BGP + AS-Number work.
### The steps to reproduce the bug
1. Fresh-install CloudStack management server at 4.22.1.0 on Ubuntu 24.04
(stock packages from download.cloudstack.org).
2. Initialize the database fresh: cloudstack-setup-databases (seeds the
schema by replaying migrations 4.0.0 → 4.22.1.0 in one run).
3. cloudstack-setup-management and start the management server.
As root admin, call listApis (or cmk sync; cmk list apis).
### What to do about it?
_No response_
--
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]
