# CNI dropin directories

Issue: https://github.com/containernetworking/cni/issues/928

## GOAL

Make PRs like these go away: https://github.com/cilium/cilium/pull/22358

Stop chained plugins from having to rewrite CNI configs to add themselves to a chain dynamically, whereupon the original plugin may then delete/update the config and blow away the subsequent plugin's changes.

## Behavior changes

When calling `libcni.ConfListFromFile("<dirname>/<filename>.conflist")`:
1. Extract the network name from the supplied configuration file
2. Look for a directory called `<confdir>/<network_name>.d`
3. Read all files that match the pattern `<confdir>/<network_name>.d/*.chain`, and sort them lexicographically
4. For each file in that sorted list, append the content of that file's `plugins` JSON key to the existing configuration.

Notes:

* The sub-files must not declare a `name` or a `cniVersion` key in their JSON. The `name` and `cniVersion` from the "original" configuration file are used. The runtime should (must?) validate that all plugins in the combined chain support the "original" configuration's `cniVersion`
* It is valid to have an "original" configuration file with no plugins. However, there must be at least one plugin defined in total for the network configuration valid.

Potential issues:
* DELETE - what if things change between ADD and DELETE
* this is no different than other changes between ADD and DELETE
* config-cache solves this
* Version incompatibility - what if plugins don't support the same version
* we have a method, `ValidateNetworkList`, that ensures that all plugins in a chain support the given version.
* Feature discovery - how do I know that my runtime supports dropins?
* [Glad you asked!](https://github.com/containernetworking/cni/issues/927) We need to come up with some kind of feature discovery mechanism.
* Must be downgrade-aware