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 1 commit into
base: master
Choose a base branch
from
Open

Adding initial draft of the Containerz yang model #1389

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
139 changes: 139 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,139 @@
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
[email protected]";

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 2025-11-09 {
description
"Initial revision.";
reference "0.1.0";
}



// gRPC server related definitions.
// Success/failure counters.
grouping grpc-server-containerz-counters {
description
"A collection of counters that were collected while evaluating
access to the gRPC server.";

container counters {
Copy link
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.

This appears to try to add an overlapping container under /system/grpc-servers/grpc-server/state. Suggest consideration of bucketizing "containerz" specific state/counters under it's own hierarchy specific to this set of services

Copy link
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.

@alshabib see:

/system/grpc-servers/grpc-server/connections/connection/state/counters

config false;
description
"A collection of counters that were collected by the gRPC during
the authentication process.";

leaf connection-rejects {
Copy link
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.

What are these connection-* related leafs meant to convey or were they copied from other model?

Copy link
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.

They seem to be a duplicate of the counters in /system/grpc-servers/grpc-server/connections/connection/state/counters. I think they are not needed because they are already present.

/system/grpc-servers/grpc-server/containerz/state/counters could be created if there are containerz specific counters. But all generic "grpc-servers" counters regarding client connections should appear in:
/system/grpc-servers/grpc-server/connections/connection/state/counters

type oc-yang:counter64;
description
"The total number of times that gRPC clients have failed
in establishing a connection to the server.";
}
leaf last-connection-reject {
type oc-types:timeticks64;
description
"A timestamp of the last time a gRPC client failed
in establishing a connection to the server.";
}
leaf connection-accepts {
type oc-yang:counter64;
description
"The total number of times that gRPC clients have succeeded
in establishing a connection to the server.";
}
leaf last-connection-accept {
type oc-types:timeticks64;
description
"A timestamp of the last time a gRPC client succeeded
in establishing a connection to the server.";
}
leaf running-containers {
Copy link
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.

Is this a useful metric if we also have the list of containers?

type oc-yang:counter64;
description
"The number of containers currently running on the system.";
}
}
}

grouping grpc-server-containerz-state {
description
"gRPC server containerz freshness-related data.";

container containers {
Copy link
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
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)?

list container {
Copy link
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?

key "name";

leaf name {
Copy link
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.";
}

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 version {
type string;
description
"The version of the of the container. This corresponds to the
tag of of the image associated to this container.";
}
}
}
}

// Augments section.

augment "/oc-sys:system/oc-sys-grpc:grpc-servers/oc-sys-grpc:grpc-server/" +
Copy link
Contributor

@brianneville brianneville Nov 20, 2025

Choose a reason for hiding this comment

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

I'm not sure if we really should be augmenting the grpc-servers list with information about something which is system-level (i.e. containers are not tied to a particular gRPC server in any way).
maybe something like /system/containers would be more appropriate?

Copy link
Contributor

@brianneville brianneville Nov 20, 2025

Choose a reason for hiding this comment

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

(likewise for the augment below)

"oc-sys-grpc:state" {
when "../config[contains(services, 'oc-containerz:CONTAINERZ')]/enable = 'true'";
description
"A gRPC server containerz freshness information.";

uses grpc-server-containerz-state;
}

augment "/oc-sys:system/oc-sys-grpc:grpc-servers/oc-sys-grpc:grpc-server/" +
"oc-sys-grpc:state" {
when "../config[contains(services, 'oc-containerz:CONTAINERZ')]/enable = 'true'";
Copy link
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.

This identity does not exist. For new gRPC services, there is current way and potential future for expansion but you'll want to at a min follow what you should see for P4RT and GRIBI

Copy link
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.

We don't allow for this kind of when statement using contains AFAIK.

Copy link
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.

This concept was introduced in the gNSI related models

https://github.com/openconfig/public/blob/master/release/models/gnsi/openconfig-gnsi-authz.yang#L205

But this identity does not exist and each gRPC service domain should really bring in a distinct related container and group everything related underneath (commented above)

uses grpc-server-containerz-counters;
description
"gNOI Containerz server access counters.";
}
}
Loading