Adding initial draft of the Containerz yang model

[alshabib]

Change Scope

This is a yang model for the gNOI.Containerz service.

This change is backwards compatible.

[earies]

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.

[robshakir]

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

[earies]

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)

[alshabib]

Added the identity

[brianneville]

nit: if you're using this when statement, oc-containerz:CONTAINERZ should be oc-gnoi-containerz:CONTAINERZ to match the module prefix oc-gnoi-containerz you defined at the top of the file here

[robshakir]

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?

[alshabib]

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.

[robshakir]

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

[alshabib]

It's gone ;)

[dplore]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit 6d0ec50

[dplore]

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.";
	}

[alshabib]

I remove the other container here.

[dplore]

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

[alshabib]

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

[dplore]

FYI: set project review status to "waiting for author".

[brianneville]

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

[brianneville]

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.