Allow the api to stay at the same v1 go package name and keep using a
1.x version number. This indicates the API is still at 1.x and allows
sharing proto types with containerd 1.6 and 1.7 releases.
Signed-off-by: Derek McGowan <derek@mcg.dev>
NRI is still newer and mostly used by CRI plugin. Keep the package in
internal to allow for interfaces as the project matures.
Signed-off-by: Derek McGowan <derek@mcg.dev>
Fixes#9806
go-grpc-prometheus is deprecated. The new location it was moved to also introduced
an entirely new api, but afaict this matches what we have at the moment.
Signed-off-by: Danny Canter <danny@dcantah.dev>
Followed the Migration Guide at https://cli.urfave.org/migrate-v1-to-v2/
The major changes not pointed out in the migration guide are:
- context.Args() no longer produces a []slice, so context.Args().Slice()
in substitued
- All cli.Global***** are deprecated (the migration guide is somewhat
unclear on this)
Signed-off-by: Derek Nola <derek.nola@suse.com>
Vendor in urfave cli/v2
Signed-off-by: Derek Nola <derek.nola@suse.com>
Fix NewStringSlice calls
Signed-off-by: Derek Nola <derek.nola@suse.com>
Previously, resolveImports would apply a glob filter if
the path contained any '*', or otherwise convert relative
paths to absolute. This meant that it was impossible to
specify globs with paths relative to the main config file.
This commit first resolves relative to absolute paths, then
applies the glob filter (if any). A test case is added to ensure
that this now works as expected.
Signed-off-by: Angelos Kolaitis <neoaggelos@gmail.com>
Ensure migration picks up defaults and correct ordering from the plugin
configuration. Ensures that the migration matches the behavior of the
default output and how the configuration will be loaded.
Signed-off-by: Derek McGowan <derek@mcg.dev>
Merge slices while checking for equal values rather than always
appending. Remove setting Import to prevent migrations from setting
incorrect configuration Imports.
Signed-off-by: Derek McGowan <derek@mcg.dev>
This change simplifies the CRI plugin dependencies by not requiring the
CRI image plugin to depend on any other CRI components. Since other CRI
plugins depend on the image plugin, this allows prevents a dependency
cycle for CRI configurations on a base plugin.
Signed-off-by: Derek McGowan <derek@mcg.dev>
