Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
112 changes: 2 additions & 110 deletions README-v0.1.0.md
Original file line number Diff line number Diff line change
@@ -1,110 +1,2 @@
# nri - Node Resource Interface
Copy link
Member

Choose a reason for hiding this comment

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

leave a short description and a hyper link reference to the new 0.1.0/readme

e.g.
original v0.1.0 CLI invoke style version of NRI has been moved
v0.1.0 docs


*This version of NRI is supported through the included v010-adapter plugin.*

This project is a WIP for a new, CNI like, interface for managing resources on a node for Pods and Containers.

## Documentation

The basic interface, concepts and plugin design of the Container Network Interface (CNI) is an elegant way to handle multiple implementations of the network stack for containers.
This concept can be used for additional interfaces to customize a container's runtime environment.
This proposal covers a new interface for resource management on a node with a structured API and plugin design for containers.

## Lifecycle

The big selling point for CNI is that it has a structured interface for modifying the network namespace for a container.
This is different from generic hooks as they lack a type safe API injected into the lifecycle of a container.
The lifecycle point that CNI and NRI plugins will be injected into is the point between `Create` and `Start` of the container's init process.

`Create->NRI->Start`

## Configuration

Configuration is split into two parts. One is the payload that is specific to a plugin invocation while the second is the host level configuration and options that specify what plugins to run and provide additional configuration to a plugin.

### Filepath and Binaries

Plugin binary paths can be configured via the consumer but will default to `/opt/nri/bin`.
Binaries are named with their type as the binary name, same as the CNI plugin naming scheme.

### Host Level Config

The config's default location will be `/etc/nri/resource.d/*.conf`.

```json
{
"version": "0.1",
"plugins": [
{
"type": "konfine",
"conf": {
"systemReserved": [0, 1]
}
},
{
"type": "clearcfs"
}
]
}
```

### Input

Input to a plugin is provided via `STDIN` as a `json` payload.

```json
{
"version": "0.1",
"state": "create",
"id": "redis",
"pid": 1234,
"spec": {
"resources": {},
"cgroupsPath": "default/redis",
"namespaces": {
"pid": "/proc/44/ns/pid",
"mount": "/proc/44/ns/mnt",
"net": "/proc/44/ns/net"
},
"annotations": {
"qos.class": "ls"
}
}
}
```

### Output

```json
{
"version": "0.1",
"state": "create",
"id": "redis",
"pid": 1234,
"cgroupsPath": "qos-ls/default/redis"
}
```

## Commands

* Invoke - provides invocations into different lifecycle changes of a container
- states: `setup|pause|resume|update|delete`

## Packages

A Go based API and client package will be created for both producers of plugins and consumers, commonly being the container runtime (containerd).

### Sample Plugin

* [clearcfs](examples/clearcfs/main.go)

## Project details

nri is a containerd sub-project, licensed under the [Apache 2.0 license](./LICENSE).
As a containerd sub-project, you will find the:

* [Project governance](https://github.com/containerd/project/blob/main/GOVERNANCE.md),
* [Maintainers](https://github.com/containerd/project/blob/main/MAINTAINERS),
* and [Contributing guidelines](https://github.com/containerd/project/blob/main/CONTRIBUTING.md)

information in our [`containerd/project`](https://github.com/containerd/project) repository.
original v0.1.0 CLI invoke style version of NRI has been moved
[v0.1.0 docs](/plugins/v010-adapter/0.1.0/README.md)
26 changes: 8 additions & 18 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,25 +23,15 @@ The goal is to enable NRI support in the most commonly used OCI runtimes,
[containerd](https://github.com/containerd/containerd) and
[CRI-O](https://github.com/cri-o/cri-o).

## Background
Copy link
Member

Choose a reason for hiding this comment

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

Should we still keep a revisited short 'Background' or 'Introduction' section which briefly tells in a few sentences what NRI is ?

Copy link
Member

Choose a reason for hiding this comment

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

Well, we have the Goal section. Maybe that's good enough then.

Copy link
Member

@mikebrow mikebrow Apr 7, 2025

Choose a reason for hiding this comment

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

I'd leave the background section in, remove the first paragraph .. move the second v0.1.0 paragraph to the new 0.1.0 readme.. and revise the 3rd paragraph with a more forward presence.. vs the change to now perspective.

Copy link
Member Author

Choose a reason for hiding this comment

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

What do you think of adjusting the third paragraph of the reservation to read as follows:

## Background
Plugins in NRI are daemon-like entities. A single instance of a plugin is responsible for handling the full stream of NRI events and requests. A unix-domain socket is used as the transport for communication. 

NRI is defined as a formal, protobuf-based 'NRI plugin protocol' which is compiled into ttRPC bindings. This should result in improved communication efficiency with lower per-message overhead, and enable straightforward implementation of stateful NRI plugins.

Since the Background section no longer contains content related to 0.1.0, the section name seems a bit odd. It reads more like a description of the Plugin.
Do you think it would be better to either make it a subsection within the Goal section or just move it directly into the Goal section?
eg.

## Goal
....

### Plugins
Plugins in NRI are daemon-like entities. A single instance of a plugin is responsible for handling the full stream of NRI events and requests. A unix-domain socket is used as the transport for communication. 
...

Copy link
Member

Choose a reason for hiding this comment

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

both options work for me :-)


The revisited API is a major rewrite of NRI. It changes the scope of NRI
and how it gets integrated into runtimes. It reworks how plugins are
implemented, how they communicate with the runtime, and what kind of
changes they can make to containers.

[NRI v0.1.0](README-v0.1.0.md) used an OCI hook-like one-shot plugin invocation
mechanism where a separate instance of a plugin was spawned for every NRI
event. This instance then used its standard input and output to receive a
request and provide a response, both as JSON data.

### Plugins
Plugins in NRI are daemon-like entities. A single instance of a plugin is
now responsible for handling the full stream of NRI events and requests. A
unix-domain socket is used as the transport for communication. Instead of
JSON requests and responses NRI is defined as a formal, protobuf-based
'NRI plugin protocol' which is compiled into ttRPC bindings. This should
result in improved communication efficiency with lower per-message overhead,
and enable straightforward implementation of stateful NRI plugins.
responsible for handling the full stream of NRI events and requests.
A unix-domain socket is used as the transport for communication.

NRI is defined as a formal, protobuf-based 'NRI plugin protocol' which is
compiled into ttRPC bindings. This should result in improved communication
efficiency with lower per-message overhead, and enable straightforward
implementation of stateful NRI plugins.

## Components

Expand Down
70 changes: 0 additions & 70 deletions examples/clearcfs/main.go

This file was deleted.

20 changes: 0 additions & 20 deletions examples/go.mod

This file was deleted.

92 changes: 0 additions & 92 deletions examples/go.sum

This file was deleted.

17 changes: 17 additions & 0 deletions plugins/v010-adapter/0.1.0/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
# Node Resource Interface v0.1.0

*This version of NRI is supported through the included v010-adapter plugin.*

Refer to the original documentation: [NRI v0.1.0](https://github.com/containerd/nri/blob/v0.9.0/README-v0.1.0.md).
If you're still using *nri v0.1.0*, We recommend refactoring to the latest NRI.

## Background

NRI v0.1.0 used an OCI hook-like one-shot plugin invocation mechanism where a separate instance of a plugin was spawned for every NRI event. This instance then used its standard input and output to receive a request and provide a response, both as JSON data.

## Other Packages

> other 0.1.0 files useful for v0.1.0 cll invoke style NRI plugins

* [v0.1.0 clearcfs example](https://github.com/containerd/nri/blob/v0.9.0/examples)
* [v0.1.0 skel example](https://github.com/containerd/nri/tree/v0.9.0/skel)
2 changes: 1 addition & 1 deletion client.go → plugins/v010-adapter/0.1.0/client.go
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ import (
"os/exec"
"sync"

types "github.com/containerd/nri/types/v1"
types "github.com/containerd/nri/plugins/v010-adapter/0.1.0/types/v1"

oci "github.com/opencontainers/runtime-spec/specs-go"
)
Expand Down
File renamed without changes.
4 changes: 2 additions & 2 deletions plugins/v010-adapter/v010-adapter.go
Original file line number Diff line number Diff line change
Expand Up @@ -23,10 +23,10 @@ import (

"github.com/sirupsen/logrus"

"github.com/containerd/nri"
"github.com/containerd/nri/pkg/api"
"github.com/containerd/nri/pkg/stub"
nriv1 "github.com/containerd/nri/types/v1"
nri "github.com/containerd/nri/plugins/v010-adapter/0.1.0"
nriv1 "github.com/containerd/nri/plugins/v010-adapter/0.1.0/types/v1"
oci "github.com/opencontainers/runtime-spec/specs-go"
)

Expand Down
Loading
Loading