Add crio config --migrate feature

[saschagrunert]

What type of PR is this?

/kind feature

What this PR does / why we need it:

We now offer a new option crio config -m/--migrate to migrate the current provided config to the latest version. The feature also logs which changes will be done to the config before printing the result:

> sudo ./bin/crio config -m 1.17
INFO Migrating config from 1.17
INFO Checking for NET_RAW and SYS_CHROOT capabilities, which have been removed per default
INFO Removing "default_capabilities" entry "NET_RAW"
INFO Removing "default_capabilities" entry "SYS_CHROOT"
INFO Checking for default AppArmor profile, which does not contain the version number any more
INFO Checking for the log level, which has changed from error to info
INFO Checking for ctr_stop_timeout, which now has a minimum value of 30
INFO Changing "ctr_stop_timeout" to 30
# The CRI-O configuration file specifies all of the available configuration
# options and command-line flags for the crio(8) OCI Kubernetes Container Runtime
# daemon, but in a TOML format that can be more easily modified and versioned.
#
# Please refer to crio.conf(5) for details of all configuration options.
…

Which issue(s) this PR fixes:

None

Special notes for your reviewer:

I will add tests if we agree that this is useful for users.

Does this PR introduce a user-facing change?

- Add `crio config -m/--migrate` option which supports migrating a v1.17.0 configuration file to the latest version.

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: saschagrunert

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [saschagrunert]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: saschagrunert

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [saschagrunert]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[haircommander]

hm often I do
crio config > config.toml, but this would add a bunch of debug logs to it. Could make logrus log to stderr for this command only? (here's a thread, it's not simple but not impossible)

[haircommander]

also this seems more as a --defaults-migrate. We would migrate the format by calling crio config anyway, but this migrates to new defaults

[haircommander]

finally, in the help docs we should mention that this will rewrite the whole config, and that users should move their user changed config values to drop-in files if they don't want to lose potentially their values

[saschagrunert]

hm often I do
crio config > config.toml, but this would add a bunch of debug logs to it. Could make logrus log to stderr for this command only? (here's a thread, it's not simple but not impossible)

I think logrus already logs to stderr, so this scenario should be fine.

[saschagrunert]

also this seems more as a --defaults-migrate. We would migrate the format by calling crio config anyway, but this migrates to new defaults

We could also migrate configs like this, which already works:

crio --config old.conf config --migrate v1.17 > new.conf

It does not only migrate to defaults. For example lets take the capabilities: All custom specified capabilities will be still in afterwards, whereas we only remove the NET_RAW and SYS_CHROOT ones.

[saschagrunert]

finally, in the help docs we should mention that this will rewrite the whole config, and that users should move their user changed config values to drop-in files if they don't want to lose potentially their values

Sure, I will write a explicit documentation if we think we should continue here.

[haircommander]

also this seems more as a --defaults-migrate. We would migrate the format by calling crio config anyway, but this migrates to new defaults

We could also migrate configs like this, which already works:

crio --config old.conf config --migrate v1.17 > new.conf

It does not only migrate to defaults. For example lets take the capabilities: All custom specified capabilities will be still in afterwards, whereas we only remove the NET_RAW and SYS_CHROOT ones.

right, but that's a default change. It is also migrating the config structure, but that's happening as part of the crio config without the --migrate

it's a pedantic difference, and I'm not that invested in the change, but I think we should be clear that this flag is going to change the defaults from the 1.17 defaults to 1.18 defaults.

[saschagrunert]

/retest

[saschagrunert]

Updated the PR with documentation and testing. PTAL

[haircommander]

one nit, otherwise LGTM

[saschagrunert]

/retest

[saschagrunert]

/retest

@haircommander I think this might be ready to be merged if we want to have it

[haircommander]

/lgtm