494b940f14
In containerd 1.5.x, we introduced support for go modules by adding a go.mod file in the root directory. This go.mod lists all the things needed across the whole code base (with the exception of integration/client which has its own go.mod). So when projects that need to make calls to containerd API will pull in some code from containerd/containerd, the `go mod` commands will add all the things listed in the root go.mod to the projects go.mod file. This causes some problems as the list of things needed to make a simple API call is enormous. in effect, making a API call will pull everything that a typical server needs as well as the root go.mod is all encompassing. In general if we had smaller things folks could use, that will make it easier by reducing the number of things that will end up in a consumers go.mod file. Now coming to a specific problem, the root containerd go.mod has various k8s.io/* modules listed. Also kubernetes depends on containerd indirectly via both moby/moby (working with docker maintainers seperately) and via google/cadvisor. So when the kubernetes maintainers try to use latest 1.5.x containerd, they will see the kubernetes go.mod ending up depending on the older version of kubernetes! So if we can expose just the minimum things needed to make a client API call then projects like cadvisor can adopt that instead of pulling in the entire go.mod from containerd. Looking at the existing code in cadvisor the minimum things needed would be the api/ directory from containerd. Please see proof of concept here: github.com/google/cadvisor/pull/2908 To enable that, in this PR, we add a go.mod file in api/ directory. we split the Protobuild.yaml into two, one for just the things in api/ directory and the rest in the root directory. We adjust various targets to build things correctly using `protobuild` and also ensure that we end up with the same generated code as before as well. To ensure we better take care of the various go.mod/go.sum files, we update the existing `make vendor` and also add a new `make verify-vendor` that one can run locally as well in the CI. Ideally, we would have a `containerd/client` either as a standalone repo or within `containerd/containerd` as a separate go module. but we will start here to experiment with a standalone api go module first. Also there are various follow ups we can do, for example @thaJeztah has identified two tasks we could do after this PR lands: github.com/containerd/containerd/pull/5716#discussion_r668821396 Signed-off-by: Davanum Srinivas <davanum@gmail.com>
18 lines
631 B
Go
18 lines
631 B
Go
/*
|
|
Copyright The containerd Authors.
|
|
|
|
Licensed under the Apache License, Version 2.0 (the "License");
|
|
you may not use this file except in compliance with the License.
|
|
You may obtain a copy of the License at
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
See the License for the specific language governing permissions and
|
|
limitations under the License.
|
|
*/
|
|
|
|
package runtimeoptions_v1 //nolint
|