[Sandbox] SDC

[CsatariGergely]

Project summary

Schema Driven Configuration

Project description

The paradigm of schema-driven API approaches is gaining increasing popularity as it facilitates programmatic interaction with systems by both machines and humans. While OpenAPI schema stands out as a widely embraced system, there are other notable schema approaches like YANG, among others. This project endeavors to empower users with a declarative and idempotent method for seamless interaction with API systems, providing a robust foundation for effective system configuration.
SDC exposes any schema based configuration as Kubernetes resources.

Org repo URL (provide if all repos under the org are in scope of the application)

https://github.com/sdcio

Project repo URL in scope of application

N/A

Additional repos in scope of the application

N/A

Website URL

https://docs.sdcio.dev/

Roadmap

We are working on the roadmap

Roadmap context

We are working on the roadmap

Contributing guide

https://docs.sdcio.dev/dev/1_about/

Code of Conduct (CoC)

https://github.com/sdcio/.github/blob/main/code-of-conduct.md

Adopters

sdcio/docs#118

Maintainers file

https://github.com/sdcio/.github/blob/main/maintainers.yaml

Security policy file

https://github.com/sdcio/.github/blob/main/SECURITY.md

Standard or specification?

N/A

Business product or service to project separation

This project is unrelated to any product or service.

Why CNCF?

SDC is an extension of Kubernetes to access YANG based systems, like AI, telecom, WIFI, campus and enterprise infrastructure. As Kubernetes is part of CNCF this is the natural choice of SDC.

Benefit to the landscape

There is a lack in the CNCF landscape to interact with YANG base systems. This is the only project which provides this functionality.

Cloud native 'fit'

SDC fits to the orchestration or provisioning part of the Cloud Native landscape.

Cloud native 'integration'

Kubernetes, SDC is an extension of Kubernetes.

Cloud native overlap

None

Similar projects

N/A

Landscape

• yes

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

IP policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Will the project require a license exception?

No

Project "Domain Technical Review"

Not yet.

Application contact email(s)

gergely.csatari@nokia.com

Contributing or sponsoring entity signatory information

If an organization:

Name	Address	Type (e.g., Delaware corporation)	Signatory name and title	Email address
Nokia	Karakaari 7, Espoo, Finland		Gergely Csatari	gergely.csatari@nokia.com

CNCF contacts

Ricardo Rocha, Faseela K, Ricardo Aravena

Additional information

Couple of presentations about SDC:

• Cloud Native Telco Day EU 2025 - Kubenet: Harnessing Kubernetes for Network Automation - Wim Henderickx & Ashan Senevirathne
• Autocon1 - Introduction of Kubenet by Wim on stage and interview by Packet Pushers
• ONE Summit 2024 - Cloud Native YANG Mgmt - Wim Henderickx, Nokia
• KubeCon EU 2024 - How We Are Moving from GitOps to Kubernetes Resource Model in 5G Core - Joel Studler & Ashan Senevirathne, Swisscom, slides
• ContainerDays 2025 - The Cloud-Native Advantage: Intent-based Network Automation - Alexander North, Swisscom & Markus Vahlenkamp, Nokia

[krook]

@CsatariGergely the Contribution Agreement draft has been sent by email for your review. We will execute it if the TOC votes to accept your project.

[JoelSpeed]

@CsatariGergely Hi, I've been reviewing the documentation for this project and wanted to know if I've understood correctly what the purpose is. Can you help?

If I have understood correctly:

• YANG is a schema definition similar to openapi
• There are many devices that can be programmed with APIs, but expose YANG as a way to tell folks how to program them/what valid data looks like
• SDC accepts these schemas (loading them from repositories), and then discover targets that match these schemas through some mapping(?)
• Users can then write a Kubernetes object (I didn't get whether this was unique to each schema or generic?), which contains YAML, and SDC will apply (and reconcile?) this config on the backend device that it found
• SDC will validate the input Kubernetes obejcts using the YANG schema before attempting to apply to the backend

Did I get that right?

[henderiw]

@CsatariGergely Hi, I've been reviewing the documentation for this project and wanted to know if I've understood correctly what the purpose is. Can you help?

If I have understood correctly:

• YANG is a schema definition similar to openapi
• There are many devices that can be programmed with APIs, but expose YANG as a way to tell folks how to program them/what valid data looks like
• SDC accepts these schemas (loading them from repositories), and then discover targets that match these schemas through some mapping(?)
• Users can then write a Kubernetes object (I didn't get whether this was unique to each schema or generic?), which contains YAML, and SDC will apply (and reconcile?) this config on the backend device that it found
• SDC will validate the input Kubernetes obejcts using the YANG schema before attempting to apply to the backend

Did I get that right?

Joel, your understanding is correct. The way we map the schema to a target is through the discovery module and each Target CR maps the schema it serves (this can be static or dynamically done). If the target gets a different schema the mapping is updated and subsequent validation is performed.

[JoelSpeed]

Users can then write a Kubernetes object (I didn't get whether this was unique to each schema or generic?), which contains YAML, and SDC will apply (and reconcile?) this config on the backend device that it found

@henderiw are you able to help me understand a bit more about as an end user, how I actually configure the backend target? I couldn't work out what resource I would apply to apply a configuration to a backend target. Do you have any examples or a detailed end user workflow example?

[henderiw]

Users can then write a Kubernetes object (I didn't get whether this was unique to each schema or generic?), which contains YAML, and SDC will apply (and reconcile?) this config on the backend device that it found

@henderiw are you able to help me understand a bit more about as an end user, how I actually configure the backend target? I couldn't work out what resource I would apply to apply a configuration to a backend target. Do you have any examples or a detailed end user workflow example?

indeed. also we have drift detection and you can apply revertive or non revertive behavior -> meaning the config is adjusted to the config applied or we create a deviation. So everything under config is for k8s agnostic to the schema but is validated and applied via YANG protocols/schemas

here are some examples.

https://docs.sdcio.dev/user-guide/configuration/config/config/#example

https://docs.sdcio.dev/user-guide/configuration/config/configset/#example

https://docs.sdcio.dev/user-guide/deviation/#revertive-vs-non-revertive-behavior

[henderiw]

also here you have a basic usage example

https://docs.sdcio.dev/getting-started/basic-usage/