Skip to content

feat: config mode vs api mode for topology management#1772

Open
micpapal wants to merge 56 commits into
mainfrom
1768-config-mode-vs-api-mode-for-topology-management
Open

feat: config mode vs api mode for topology management#1772
micpapal wants to merge 56 commits into
mainfrom
1768-config-mode-vs-api-mode-for-topology-management

Conversation

@micpapal

@micpapal micpapal commented Jun 26, 2026

Copy link
Copy Markdown
Member

Description

Summary

Implements dual topology management modes for the SLIM control plane: config-managed (YAML file is source of truth) and API-managed (DB is source of truth with full CRUD via gRPC/CLI). Adds topology mutation commands, persistence for config→API mode transitions, and controller restart resilience.

Topology management modes

The control plane operates in one of two mutually exclusive modes based on whether the config file contains a topology section:

Config mode (topology section present)

  • Config file is the single source of truth
  • On restart: all state (runtime + topology) is wiped and config is re-applied
  • Dynamic $group expansion re-evaluated when new nodes register
  • Mutation APIs return an error: "topology is config-managed"
  • Topology is persisted to DB after expansion (for seamless transition to API mode)

API mode (no topology section)

  • DB is the single source of truth
  • On restart: runtime state (nodes, links, routes) is cleared but topology config (segments, segment links) is preserved from DB
  • Full CRUD operations available via slimctl and gRPC APIs
  • Nodes re-register and links/routes are rebuilt automatically

Changes

Topology persistence and startup logic

  • clear_runtime_state() — new DB method that clears nodes, links, routes but preserves topology config. Called on API-mode startup.
  • clear_all_state() — clears everything (runtime + topology). Called on config-mode startup. Internally delegates to clear_runtime_state().
  • persist_segments_to_db() — in config mode, writes expanded segments/links to DB after rebuild_link_graph(), enabling config→API mode transition without losing topology
  • load_topology_from_db() — on API-mode startup, reconstructs in-memory segment graphs from DB

Topology mutation APIs (API mode only)

  • controller segment add <NAME> — create a new segment
  • controller segment remove <NAME> — remove a segment and all its links
  • controller link add --segment <S> <GROUP_A> <GROUP_B> — add inter-group link to a segment
  • controller link remove --segment <S> <GROUP_A> <GROUP_B> — remove inter-group link from a segment
  • Corresponding gRPC RPCs: AddSegment, RemoveSegment, AddTopologyLink, RemoveTopologyLink
  • Guards prevent mutation in config-managed mode

Node reconnection resilience

  • On controller restart, nodes reconnect and rebuild their links/routes automatically
  • Stale nodes (that don't reconnect) are no longer persisted across restarts — cleared by clear_runtime_state()
  • Node disconnect logic properly cleans up routes and reassigns gateway links

DB schema additions

  • topology_segments table — stores segment definitions
  • topology_segment_links table — stores inter-group links within each segment
  • SQLite add_link_to_segment made idempotent (duplicate links ignored)
  • Links allowed for groups that don't have registered nodes yet

Related

Type of Change

  • Bugfix
  • New Feature
  • Breaking Change
  • Refactor
  • Documentation
  • Other (please describe)

Checklist

  • I have read the contributing guidelines
  • Existing issues have been referenced (where applicable)
  • I have verified this change is not present in other open pull requests
  • Functionality is documented
  • All code style checks pass
  • New code contribution is covered by automated tests
  • All new and existing tests pass

micpapal and others added 30 commits June 19, 2026 14:21
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Co-authored-by: Sam Betts <1769706+Tehsmash@users.noreply.github.com>
Signed-off-by: Michele Papalini <49271675+micpapal@users.noreply.github.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
@github-actions

github-actions Bot commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

The latest Buf updates on your PR. Results from workflow ci-buf / buf (pull_request).

BuildFormatLintBreakingUpdated (UTC)
✅ passed✅ passed✅ passed⏩ skippedJun 30, 2026, 12:25 PM

micpapal and others added 11 commits June 26, 2026 17:21
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
…groupdeployment-based-routing

Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
…ment-based-routing' into 1768-config-mode-vs-api-mode-for-topology-management
Signed-off-by: Michele Papalini <micpapal@cisco.com>
…ment-based-routing' into 1768-config-mode-vs-api-mode-for-topology-management

Signed-off-by: Michele Papalini <micpapal@cisco.com>
@micpapal micpapal marked this pull request as ready for review June 29, 2026 08:05
@micpapal micpapal requested a review from a team as a code owner June 29, 2026 08:05
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Base automatically changed from 1745-update-slimctl-controller-commands-for-groupdeployment-based-routing to main June 29, 2026 13:13
Signed-off-by: Michele Papalini <micpapal@cisco.com>
@micpapal micpapal force-pushed the 1768-config-mode-vs-api-mode-for-topology-management branch from 9dde01c to bbe416c Compare June 29, 2026 14:04
…nagement

Signed-off-by: Michele Papalini <micpapal@cisco.com>
@micpapal micpapal linked an issue Jun 29, 2026 that may be closed by this pull request
micpapal and others added 7 commits June 29, 2026 16:51
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Signed-off-by: Michele Papalini <micpapal@cisco.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Config mode vs API mode for topology management

2 participants