suggestion: It may be useful to add some coded name of the deprecation and return it as well as version when deprecated and version when plan to be removed as separate columns. So whatever consumer there will be will not need to group by message and instead can group by some shorter name. Also can grep by version which deprecation they interested in.

Short names are already there; see the ID field. (This also shows up in json output.)

It wasn't clear to me whether version-deprecated and removal-target where particularly useful bits to include here; I think the better pattern would be for the user to check the published details on the website as we do end up changing these details occasionally.

Short names are already there; see the ID field. (This also shows up in json output.)

It wasn't clear to me whether version-deprecated and removal-target where particularly useful bits to include here; I think the better pattern would be for the user to check the published details on the website as we do end up changing these details occasionally.

Sorry missed the ID.

As for versions - in example they are part of the message. Maybe including when they were deprecated as it wouldn't change, but not when they will be removed than?

Two new RPCs are added to the existing Introspection service, one for recording and the other for querying.

I don't think these really belong in the introspection service. I could see individual plugins exporting a field to indicate that a deprecated feature is in use, but the record/list functionality is new functionality entirely.

From a backport-able to 1.6/1.7 perspective, it is cleaner to extend the Server response and plugin exports rather than add new functions which will change the generated introspection interface. Is it necessary for Record to be an exported interface rather than having it handled within plugins? The cri plugin itself can report schema 1 usage directly to its exports. We don't have any restriction today that exports can only occur on initialization.

Right now, the usage of RecordDeprecation in the client is useful for the schema v1 images, since the pull + conversion logic occurs in the client. The other callsite now is in the server where config is parsed, that's also not quite in a plugin.

I can take a look at the exports approach. It's a bit more limiting, but maybe that's the right tradeoff. Another idea would be to introduce a new service entirely rather than modifying the introspection service.

I've rewritten this to use the Exports approach and it is cleaner for the most part.

• For the schema v1 warning: the Image service is now responsible for emitting this in its Exports, based on the presence of the label.
• A new Warning service is added for Config-based deprecations. The Warning service can register a ConfigMigration and read all the config.Plugins to emit warnings there.
• For the Go plugin library warning: top-level Config fields are not possible to read from within the Warning service, so the main server.New invokes the Warning plugin for any deprecations found there.

With this rewrite the only API addition is a field in the Server RPC response rather than additional RPCs.

Thanks Sam! This will be helpful when migrating to 2.0.

One concern: Export is a map[string]string and it limits the format of warning reports. For example, when reporting schema v1 images, it would be helpful if we tell users the image names. Can we make the value of Export free text, instead of only allowing timestamps? So it will look like

ID                     LAST OCCURRENCE                                  MESSAGE    
go-plugin-library      [plugin path], 2023-10-17T21:23:18.258330433Z    Dynamically-linked Go plugins as containerd runtimes are deprecated since containerd v2.0 and removed in containerd v2.1.
pull-schema-1-image     nginx:latest, 2023-10-17T22:02:47.305456204Z    Schema 1 images are deprecated since containerd v1.7 and removed in containerd v2.0. Since containerd v1.7.8, schema 1 images are identified by the "io.containerd.image/converted-docker-schema1" label.

I've moved this to a draft for now. #9292 has some discussion and I've also written up a much longer doc covering my thinking in this area.

As for versions - in example they are part of the message. Maybe including when they were deprecated as it wouldn't change, but not when they will be removed than?

For example, when reporting schema v1 images, it would be helpful if we tell users the image names. Can we make the value of Export free text, instead of only allowing timestamps? So it will look like

@SergeyKanzhelev @ruiwen-zhao I've moved this to the bikeshedding section of the proposal doc.