Documentation of SDC lives in https://docs.sdcio.dev/

The GitHub organization for SDC (sdcio) has several repositories due to the architecture of the project.

The schema server component is a versatile repository for schemas from diverse vendors and versions. It features a gRPC API for seamless schema querying and dynamic management, allowing users to load and unload schemas in real time. The integration of a CLI enhances user interaction, providing a familiar command-line interface. Operating in a stateless architecture, it offers scalability, while optional schema persistence caters to users requiring persistent storage. In essence, the schema server combines flexibility, efficiency, and user-friendliness for effective schema management in dynamic API environments. Schema-server is developed in the schema-server repository.

The data-server component serves as a versatile intermediary, connecting the config-server, schema-server, cache, and xNF/Device in a stateless design for scalability. It features a North-bound API for both imperative and declarative interactions and supports various South-bound protocols. With dedicated DataStores per target, flexible synchronization options, candidate-based interactions, and the ability to connect multiple data servers per device, it provides a resilient and adaptable foundation for managing and synchronizing data in dynamic system environments. The Data-server is developed in the data-server repository.

The cache component manages multiple datastores, including Config, State, and Intended, along with Intent metadata. It offers the option for persistent data storage, complemented by a gRPC API for seamless interaction. Additionally, the cache component provides a derived Command Line Interface (CLI) for user-friendly access and configuration. The Cache is developed in the cache repository.

The config-server is a Kubernetes-based Operator and comprises several controllers:

• Schema Controller: Manages the lifecycle of schemas using Schema Custom Resources (CR).
• Discovery Controller: Manages the lifecycle of targets through DiscoveryRule CR, discovering devices/NF(s)
• Target Controller: Manages the lifecycle of Target DataStores using Target CR.
• Config API Server: Manages the lifecycle of Config resources.
  • Utilizes its storage backend (not etcd).
  • Interacts declaratively with the data-server through Intent transactions.
  • Implements validation checks, rejecting configurations that fail validation. The Config-server is developed in the config-server repository.

A YANG parser.

Home of the code of the project homepage.

Report component specific issues as individual issues in each components repository.

Report project level issues to the .github repo.

In case of any questions ask us on our discord channel.

• Schema's: YANG, others TBD
• Targets: Physical devices (PNF), Containers (CNF), Virtual Machines (VNF)
• Vendor agnostic
• Flexible deployments: Small, medium or large-scale scaled-out deployments
• Target Protocols: gNMI, Netconf
• Full Config or Config Snippets
• Declarative Operation

Adopters of the porject are collected in the ADOPTERS file.

The SDC code in the sdcio organisations public repositories is licensed under the Apache License 2.0 Apache License 2.0, documentation is licensed under CC BY 4.0.

The SDC project is following the CNCF Code of Conduct. More information and links about the CNCF Code of Conduct are here.

The project is governed by the maintainers of the project.

On the long run we plan to define a written governance.

Presentations about SDC:

• Container Days 2025: The Cloud-Native Advantage: Intent-based Network Automation - Alexander North & Markus Vahlenkamp , video
• ONE Summit 2024: Cloud Native YANG Mgmt - Wim Henderickx, Nokia, video

2H 2026

• sensitive configs / secrets
• NETCONF actions

1H 2027

• network wide transactions
• Scale
• High availability

Have questions, ideas, bug reports or just want to chat? Come join our discord channel.