feat(ui): admin interface #532

New issue

Closed

opened 2026-03-28 04:25:25 +00:00 by mfreeman451 · 0 comments

mfreeman451 commented

2026-03-28 04:25:25 +00:00

Owner

Imported from GitHub.

Original GitHub issue: #1595
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/issues/1595
Original created: 2025-08-30T15:16:55Z

Need to create UI so admin users can affect configuration changes, using API and the KV service.

We need to be able to support a leaf/hub NATS/KV configuration, this means that if the core API service is talking to the local KV (hub), but data is on a leaf, it needs to know about the leafs and will have to specifically address it using $JS. (unsure if that is the exact syntax).

To put another way, if there are two KVs, the core KV has to specifically address the KV with the data that it wants to operate on.

We need to also start using the RBAC system here even if we only currently support one (admin) user currently.

We need to look at our existing json configurations (we'll worry about the toml/rust services later, they need to be converted to use json and read from the KV) and create CRUD interfaces for each object (k/v).

We can write configs for each service by pushing json to the KV just like we're currently doing with serviceradar-sync, and the service will automatically get the config out of the KV instead of the filesystem.

We need some way of identifying which service is managed by which KV. Some environments will only be running one instance of NATS JetStream/KV, but others will have leaf NATS JetStream KV systems, and you have to address them differently if you are not talking directly to that KV. The Core API in this situation would only have access to the hub (typically local or accessible to the Core API), so if it looked only at its own resources it wouldn't see the stuff on the leaf.

Update sidebar navigation
Add new CRUD API endpoints
Admin layout for core.json
Admin layout for sync.json
Admin layout for poller.json
Admin layout for agent.json

Users may be running multiple different services as well, for instance a user may have 10s or hundreds of different agent/poller combinations (they all should receive a unique agent-id and poller-id), so there needs to be a way to enumerate the different KV services, we also should be able to look in our pollers table to figure out what different agents/poller combinations there are out there. Once we know that we can show a tree-like navigation, users would probably start out choosing which KV they are going to operate on, we should be able to figure out of it is just one local KV, or if there is a cluster, by talking to the local one. Once a KV is decided, we need to enumerate out the different services that are pinned to that KV. Not sure if we have a good way for knowing that yet either, we may need to work that out here as well.

Imported from GitHub. Original GitHub issue: #1595 Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/issues/1595 Original created: 2025-08-30T15:16:55Z --- Need to create UI so admin users can affect configuration changes, using API and the KV service. We need to be able to support a leaf/hub NATS/KV configuration, this means that if the core API service is talking to the local KV (hub), but data is on a leaf, it needs to know about the leafs and will have to specifically address it using $JS.<id> (unsure if that is the exact syntax). To put another way, if there are two KVs, the core KV has to specifically address the KV with the data that it wants to operate on. We need to also start using the RBAC system here even if we only currently support one (admin) user currently. We need to look at our existing json configurations (we'll worry about the toml/rust services later, they need to be converted to use json and read from the KV) and create CRUD interfaces for each object (k/v). We can write configs for each service by pushing json to the KV just like we're currently doing with serviceradar-sync, and the service will automatically get the config out of the KV instead of the filesystem. We need some way of identifying which service is managed by which KV. Some environments will only be running one instance of NATS JetStream/KV, but others will have leaf NATS JetStream KV systems, and you have to address them differently if you are not talking directly to that KV. The Core API in this situation would only have access to the hub (typically local or accessible to the Core API), so if it looked only at its own resources it wouldn't see the stuff on the leaf. - [ ] Update sidebar navigation - [ ] Add new CRUD API endpoints - [ ] Admin layout for core.json - [ ] Admin layout for sync.json - [ ] Admin layout for poller.json - [ ] Admin layout for agent.json Users may be running multiple different services as well, for instance a user may have 10s or hundreds of different agent/poller combinations (they all should receive a unique agent-id and poller-id), so there needs to be a way to enumerate the different KV services, we also should be able to look in our pollers table to figure out what different agents/poller combinations there are out there. Once we know that we can show a tree-like navigation, users would probably start out choosing which KV they are going to operate on, we should be able to figure out of it is just one local KV, or if there is a cluster, by talking to the local one. Once a KV is decided, we need to enumerate out the different services that are pinned to that KV. Not sure if we have a good way for knowing that yet either, we may need to work that out here as well.