363d692f35
After several requests for information about platform support, configuration introspection and feature switches, we now have a solution that should work in all these use cases. The Introspection API hooks into the plugin subsystem registration process. During registration, plugins declare several pieces of information, allowing clients to discover the cababilities and support that a containerd instance provides, including whether or not it loaded with an error. To allow symmetrical error reporting, the `google/rpc.Status` protobuf definitions have been brought in from the googleapis project. Unfortunately, we had to generate these in place to match our protobuf system. Once we like this design, we can add an implementation to integrate it directly with the plugin system. Enjoy! Signed-off-by: Stephen J Day <stephen.day@docker.com> |
||
|---|---|---|
| .. | ||
| services | ||
| types | ||
| next.pb.txt | ||
| README.md | ||
This directory contains the GRPC API definitions for containerd.
All defined services and messages have been aggregated into *.pb.txt
descriptors files in this directory. Definitions present here are considered
frozen after the release.
At release time, the current next.pb.txt file will be moved into place to
freeze the API changes for the minor version. For example, when 1.0.0 is
released, next.pb.txt should be moved to 1.0.txt. Notice that we leave off
the patch number, since the API will be completely locked down for a given
patch series.
We may find that by default, protobuf descriptors are too noisy to lock down API changes. In that case, we may filter out certain fields in the descriptors, possibly regenerating for old versions.
This process is similar to the process used to ensure backwards compatibility in Go.