cni

Overview

CNI (Container Network Interface) is a project for container networking on Linux. The upstream CNI project defines the interface used by container runtimes and related tools to set up and tear down network connectivity for containers. The project also provides libraries for implementing CNI-aware software, while the separate containernetworking/plugins repository contains reference and example plugins. (github.com)

In a Linux distribution, this package exists to provide the CNI project components needed by container networking stacks and their integrations. That role is usually most visible to administrators and platform maintainers running container runtimes, developers building CNI-based tooling, and CI/CD or cluster operators who need consistent network setup behavior across systems. The exact integration point in NiceOS should be verified against the packaging metadata if it matters for local deployment. (github.com)

Purpose and typical use cases

Typical uses include:

• providing the CNI interface and libraries that container runtimes can call to configure container network namespaces;
• supporting CNI-based networking in orchestrated environments;
• serving as a dependency or integration point for tools that need to implement or consume CNI behavior;
• packaging a standard networking interface used by multiple container ecosystems. (github.com)

Typical users are:

• container platform administrators;
• developers writing container networking code or plugins;
• CI/CD and release engineers validating container networking behavior;
• security and platform engineers reviewing how container networking is configured;
• maintainers of orchestration or runtime stacks that integrate with CNI. (github.com)

Upstream project

Upstream is the Container Network Interface project. Its main repository describes CNI as a specification plus libraries for writing plugins, and notes that the plugins live in a separate repository. The upstream plugins repository is maintained by the CNI team and contains reference networking plugins and build/test guidance. (github.com)

NiceOS maintainers should verify which upstream repository or release stream is being tracked before each update, especially if the packaging changes between the spec/library repository and the plugin repository. (github.com)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source metadata and manifest files used to describe upstream inputs;
• METADATA/ — package metadata for the dist-git workflow;
• SBOM/ — software bill of materials artifacts when they are present for the package.

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/. That keeps the repository smaller and makes it easier to update packaging metadata without committing bulky upstream payloads. The exact manifest format should be treated as packaging metadata rather than a promise about any specific upstream tarball layout. (github.com)

Source storage and integrity policy

For this package, the source policy is to keep large upstream archives out of Git and track them through SOURCES/ manifests instead. Maintainers should rely on those manifests as the packaging record of what was imported, rather than expecting the archive itself to live in the repository. No concrete digest values are listed here; they are intentionally omitted so this README stays stable across updates.

Before updating sources, verify that:

• the manifest still points to the intended upstream payload;
• any regenerated metadata matches the new upstream content;
• no extra files were added or removed by accident;
• the packaging records still reflect the upstream project being built.

If any of those items are unclear, NiceOS maintainers should verify the local packaging workflow before relying on it. (github.com)

NiceOS maintenance notes

Before updating this package, check the following:

• confirm the upstream repository and release stream being tracked;
• review the spec for changed build steps, renamed subpackages, or new file installation paths;
• update SOURCES/ manifests if the imported upstream content changes;
• regenerate any packaging metadata that depends on upstream files;
• review SBOM/ content if NiceOS generates or stores one for this package;
• check whether the update changes the relationship between the CNI spec/library components and any separately packaged plugins. (github.com)

Risks to consider:

• packaging can drift from the upstream repository if the wrong source stream is imported;
• manifests can become stale if upstream file layout changes;
• build or test assumptions may break if upstream changes the way its libraries or example tools are organized;
• downstream consumers may depend on interfaces that should be checked after any update.

Build and verification checklist

For RPM maintainers, a practical checklist is:

• verify the spec file still references the correct source manifests;
• confirm the imported upstream source matches the intended repository;
• run a clean build in the target NiceOS environment;
• inspect build logs for missing files, renamed paths, or failing tests;
• verify installed files and package ownership with the generated RPM metadata;
• check that any generated docs or SBOM artifacts are still valid;
• test the package in a container-networking workflow if the update may affect runtime integration;
• ensure the resulting package contents match the packaging intent before merging.

If a test or file list is not obvious from the spec, maintainers should verify it manually rather than assuming upstream behavior has not changed. (github.com)

References

• Upstream CNI project
• Upstream plugins repository
• Upstream releases for CNI
• Upstream releases for plugins

Russian documentation

See README_RU.md.

Dist-git repository notes

• Package repository: rpms/cni
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.