Show current runtime configuration during startup #7704
Assignees
Labels
good first issue
Denotes an issue ready for a new contributor, according to the "help wanted" guidelines.
help wanted
Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.
Comments
|
/help |
|
@kwilczynski: Please ensure the request meets the requirements listed here. If this request no longer meets these requirements, the label can be removed In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
openshift-ci
bot
added
good first issue
|
I'd be interested in taking this issue! |
|
@LenkaSeg, it's all yours! Feel free to reach out if you have any questions. Happy to help clarify things, etc, etc. |
|
So any reason why we shouldn't just log the config to disk? similar to /etc/kubernetes/kubeletconfig.yaml? |
|
@kannon92, we could save the current runtime configuration after startup and following a reload, to some runtime location such as |
|
I'd think that would be useful. Or maybe /etc/crio/crio.toml? Trying to follow other kube configs (like storage). |
|
@kannon92, I wanted to avoid |
|
I think printing the internal representation of the config is a good idea. a user can piece it together but they have to take into account env vars, cli flags and multiple dropin files. a user can alrady print with |
|
Since we mentioned kubelet, this is how it currently does it. For reference only:
There are also common Go runtime options and environment variables printed, which is a nice touch. |
LenkaSeg
added a commit
to LenkaSeg/cri-o
that referenced
this issue
Feb 14, 2024
Part od the issue cri-o#7704. Function LogConfig prints current config at startup, following a kubelet example. Signed-off-by: Lenka Segura <lsegura@redhat.com>
LenkaSeg
added a commit
to LenkaSeg/cri-o
that referenced
this issue
Feb 16, 2024
Part od the issue cri-o#7704. Function LogConfig prints current config at startup, following a kubelet example. Signed-off-by: Lenka Segura <lsegura@redhat.com>
LenkaSeg
added a commit
to LenkaSeg/cri-o
that referenced
this issue
Feb 19, 2024
Part od the issue cri-o#7704. Function LogConfig prints current config at startup, following a kubelet example. Signed-off-by: Lenka Segura <lsegura@redhat.com>
LenkaSeg
added a commit
to LenkaSeg/cri-o
that referenced
this issue
Feb 20, 2024
Part od the issue cri-o#7704. Function LogConfig prints current config at startup, following a kubelet example. Signed-off-by: Lenka Segura <lsegura@redhat.com>
LenkaSeg
added a commit
to LenkaSeg/cri-o
that referenced
this issue
Mar 1, 2024
Part od the issue cri-o#7704. Function LogConfig prints current config at startup, following a kubelet example. Signed-off-by: Lenka Segura <lsegura@redhat.com>
|
A friendly reminder that this issue had no activity for 30 days. |
github-actions
bot
added
the
lifecycle/stale
sohankunkerkar
removed
the
lifecycle/stale
|
The part of this issue which handles exposing the current config and CLI options is here in this PR #7783 Would it be ok to split these two things (exposing and storage) into two separate PRs? For the storage part, do we want to persist both config and CLI options? Or are there any suggestions how to go about it? |
|
I personally don't agree with the need to store the current configuration anywhere. I think printing it is fine. the config is reconstructable from the sources cri-o is being configured with. The debugging case of printing the config is sufficient IMO |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, CRI-O shows only a handful of information about its runtime configuration during startup, for example:
(running with default INFO log level)
Not much more will be added when running CRI-O with an increased log level, per:
(running with default DEBUG log level; Request and Response log lines have been omitted for brevity)
However, it would be useful to capture the runtime configuration at startup, so that it will also be captured as part of the dedicated CRI-O process log or a system log. This is also useful should the log be forwarded to an external log storage or indexing service.
Granted, the
crio status config(from CRI-O release 1.29 onwards) can be used to capture the current runtime configuration, which would be shown as a TOML file, but even though this functionality is available, a lot of users do not know about it or simply forgets about it when submitting a bug report of a feature request—it's often too late then to collect initial runtime configuration data, as the CRI-O process might have been restarted or crashed, etc.Thus, similarly to the familiar kubelet from Kubernetes, we should add an ability for CRI-O to display its runtime configuration on startup, so that we can ensure that it will be captured for reference later via a log file somewhere, but also should CRI-O be run interactively in the current terminal, then the user will have an immediate insight into current settings and each option value.
The
crio status configcommand mentioned earlier behind the scenes works as an HTTP client connecting over CRI-O's exposed control Unix socket, and as such, it would be equivalent to making a request usingcurl(or any other HTTP client capable of establishing a connection over a Unix socket), for example:(making a request manually using
curl -v --unix-socket /var/run/crio/crio.sock http://0/config...)The relevant code, which also showcases how the runtime configuration has been serialised, can be found in the following:
(the code below comes from the
func (s *Server) GetExtendInterfaceMux(bool) *chi.Muxfunction)cri-o/server/inspect.go
Lines 135 to 146 in 91816d7
cri-o/pkg/config/config.go
Lines 799 to 811 in 91816d7
The question would be how the output of the runtime configuration should look like? Should it be similar to how kubelet prints its configuration? Or perhaps a pretty printer such as go-spew (no longer actively maintained, sadly) would print the values? Or, should it be the style of the
Printf()function from the built-infmtpackage, such as the%#vand%+vformat strings? The most one would need to be picked up—or a custom format and/or a printer could be introduced at this point.The obvious place where to put the code to print the startup configuration would be to follow the configuration validation:
(the code below comes from the
app.Actioncallback)cri-o/cmd/crio/main.go
Lines 265 to 269 in 91816d7
However, this wouldn't service the configuration hot reload (following the SIGHUP signal being sent to the CRI-O process), which would potentially include changes to the current runtime configuration. Handling both cases is potentially one of the challenges here (aside from the output format for the configuration when printing it on the screen).
The text was updated successfully, but these errors were encountered: