Skip to content

Adding initial draft of the Containerz yang model #1389

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
alshabib wants to merge 2 commits into
base: master
Choose a base branch
from
+155 −0
Open

Adding initial draft of the Containerz yang model #1389

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6d0ec50
Adding initial draft of the Containerz yang model
alshabib Nov 9, 2025
72f9756
Merge remote-tracking branch 'upstream/master' into containerz
alshabib Feb 20, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions release/models/containerz/.spec.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
- name: openconfig-containerz
docs:
- yang/acl/openconfig-containerz.yang
build:
- yang/acl/openconfig-containerz.yang
run-ci: true
149 changes: 149 additions & 0 deletions release/models/containerz/openconfig-containerz.yang
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,149 @@
module openconfig-containerz {
yang-version 1;
namespace "https://github.com/openconfig/yang/gnoi/containerz";
prefix oc-gnoi-containerz;

import openconfig-extensions { prefix oc-ext; }
import openconfig-system {
prefix oc-sys;
}
import openconfig-system-grpc {
prefix oc-sys-grpc;
}
import openconfig-types {
prefix oc-types;
}
import openconfig-yang-types {
prefix oc-yang;
}
organization
"OpenConfig Working Group";

contact
"OpenConfig working group
netopenconfig@googlegroups.com";

description
"This module provides a data model for the metadata of gNOI.containerz
running on this system as well as the containers running on the system.";

oc-ext:openconfig-version "0.1.0";

revision 2026-02-20 {
description
"Initial revision.";
reference "0.1.0";
}

grouping containerz-config {
description
"Containerz gRPC server configuration data.";

leaf vrf {
type string;
description
"The vrf instance where the container runtime should be started.";
}

leaf soft-memory-limit {
type uint64;
units megabytes;
description
"The amount of memory to limit the entire container workload to if
memory contention is detected.";
}

leaf hard-memory-limit {
type uint64;
units megabytes;
description
"The amount of memory to limit the entire container workload.";
}

leaf cpu-limit {
type oc-types:percentage;
description
"The percentage of system cpu to allocate to the entire container
workload.";
}

}


grouping containerz-state {
description
"Containerz base container operational data.";

container containers {
Copy link
Copy Markdown
Contributor

@earies earies Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar suggestion as above - consider grouping under containerz hierarchy first. If this is meant to be similar to docker ps outputs then can align as such. Any counters should go under child counters container at relevant hierarchy.

Copy link
Copy Markdown
Member

@dplore dplore Nov 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider the same fields from a docker ps (or docker ls if the intent is only to show running containers)?

Copy link
Copy Markdown
Author

@alshabib alshabib Feb 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is not entirely possible as restarts or build-label are not directly returned from ps


list container {
Copy link
Copy Markdown
Member

@robshakir robshakir Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see this as duplicative to the ListContainer RPC, which is fine in principle, but how do we expect the two to be used? I presume the thinking here is that some clients will just subscribe through gNMI to understand this state?

Copy link
Copy Markdown
Author

@alshabib alshabib Feb 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes - the idea is to export base container telemetry to such that we do not depend on containers to export base telemetry that may cause a circular dependency.

key "name";
leaf name {
Copy link
Copy Markdown
Member

@dplore dplore Nov 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For openconfig style compliance, this needs to be a leafref to a leaf of the same name in a "state container"

for example:

public/release/models/system/openconfig-system-grpc.yang

Lines 75 to 129 in 1463f23

list grpc-server {
key "name";
description
"The list of gRPC servers that are running on the device. Each
instance within this list corresponds to an individual gRPC listener
that listens on a single TCP port on the specified addresses.
Where there are multiple services that run on a single port, these
are enabled through the service leaf-list which uses the GRPC_SERVICE
identity to list the supported service types.";
leaf name {
type leafref {
path "../config/name";
}
description
"Reference to the name of the service that is to be enabled.";
}
container config {
description
"Configuration parameters relating to the gRPC service.";
uses grpc-server-config;
}
container state {
config false;
description
"Operational state relating to the gRPC service.";
uses grpc-server-config;
}
uses connections-top;
}
}
}
grouping grpc-server-config {
description
"Configuration parameters corresponding to an individual gRPC
server.";
leaf name {
type string;
default "DEFAULT";
description
"The name of the gRPC server instance that is running on
the local system.
If the operator does not designate a name for the protocol
instance (e.g. config), the implementation should use the
name of 'DEFAULT' (e.g. state). In addition, for
implementations that support a single gRPC server instance,
the default value is recommended for consistency.";
}

Copy link
Copy Markdown
Author

@alshabib alshabib Feb 20, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remove the other container here.

type string;
}

leaf created-on {
type oc-types:timeticks64;
description
"The timestamp when the container was created.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).";
}

leaf restarts {
type oc-yang:counter64;
description
"The number of times the container was restarted.";
}

leaf build-label {
type string;
description
"This build-label of the container. This corresponds to the
build label associated to the container if any.";
}

leaf tag {
type string;
description
"The version of the container. This corresponds to the
tag of of the image associated to this container.";
}
}
}
}

grouping containerz-top {
description
"Top level configuration and state data for Containerz";

container state {
config false;
description
"Operational data for Containerz";

uses containerz-state;
}

container config {
config true;
description
"Configuration data for Containerz";

uses containerz-config;
Copy link
Copy Markdown
Contributor

@brianneville brianneville Feb 26, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this config is going to be directly underneath the /oc-sys:system/oc-sys-grpc:grpc-servers/oc-sys-grpc:grpc-server path - should we put it in a container so that it doesnt appear to be config for the gprc-server specifically?

e.g. right now the vrf leaf is at /system/grpc-servers/grpc-server[name=X]/config/vrf, and based on the path people could be misled into thinking that this should be the VRF for the grpc-server itself, rather than for the container runtime.
something like:
/system/grpc-servers/grpc-server[name=X]/containerz/config/vrf
would make it more clear that this is not for the grpc-server specifically

Copy link
Copy Markdown
Contributor

@brianneville brianneville Feb 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still dont think this should be on a per-grpc-server basis though - could you take a look at #1389 (comment) ?
having this config be under a global /system path (e.g. /system/containerz/config and /system/containerz/state) would make a lot more sense imo, and remove the ability for the client to push config that is conflicting across each grpc-server.

}
}
identity CONTAINERZ {
base "oc-sys-grpc:GRPC_SERVICE";
description
"Containerz: gRPC Container Lifecycle Management";
}

augment "/oc-sys:system/oc-sys-grpc:grpc-servers/oc-sys-grpc:grpc-server" {
when "config[contains(services, 'oc-containerz:CONTAINERZ')]/enable = 'true'";
description
"Containerz gRPC Server.";

uses containerz-top;
}
}
Loading