engine: fix logging interactions with fetch-offline #1075
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Right now, even if `fetch-offline` gets `ErrNeedNet`, it might've still logged info about configs which it did fetch before hitting the error. This then results in double-logging of e.g. the base config and at least the first layer of user configs when `fetch` re-fetches them. But it's also misleading, because anything which runs between `fetch-offline` and `fetch` and sees the journal messages will think that Ignition did successfully fetch and cache the merged user config, when it did not. And sadly, we still have code which peek at the cached config for `$reasons` (legacy-style RHCOS LUKS is one of them, RHCOS FIPS support is another), and those bits get thrown off by seeing the logging messages yet not seeing a cached Ignition config. Let's tweak things so that we buffer those messages and only actually write them out once we've successfully acquired the configs. While we're here, clean up the base config logging hack now that the `fetch` stages are canonical.
|
Only compile-tested for now. |
|
Using the journal to communicate is trickier than we thought. Well, I guess in general all IPC is tricky. Problem description makes total sense to me. The patch looks right to me superficially but I don't know the fetch code very well. |
|
OK, tested this now and ready for review! And also added another commit which fixes something else worth mentioning: in cases where |
jlebon
force-pushed
the
pr/logging-tweaks
branch
from
5c44542 to
0b5a9e5
Compare
cgwalters
approved these changes
Sep 1, 2020
There was a problem hiding this comment.
LGTM, though CI is hitting https://github.com/coreos/fedora-coreos-config/issues/591
lucab
reviewed
Sep 2, 2020
lucab
reviewed
Sep 2, 2020
It's possible that `fetch-offline` does successfully fetch and cache a config but still touch `/run/ignition/neednet`. That stamp file is an API between Ignition and the OS that Ignition will need networking to fully process it. But the config itself might've successfully been fetched (and the only thing that requires networking is e.g. a remote file). In those cases, there's no point in running `fetch` and have it query the provider again.
jlebon
force-pushed
the
pr/logging-tweaks
branch
from
0b5a9e5 to
ad76955
Compare
lucab
approved these changes
Sep 9, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Right now, even if
fetch-offlinegetsErrNeedNet, it might've stilllogged info about configs which it did fetch before hitting the error.
This then results in double-logging of e.g. the base config and at least
the first layer of user configs when
fetchre-fetches them.But it's also misleading, because anything which runs between
fetch-offlineandfetchand sees the journal messages will thinkthat Ignition did successfully fetch and cache the merged user config,
when it did not.
And sadly, we still have code which peek at the cached config for
$reasons(legacy-style RHCOS LUKS is one of them, RHCOS FIPS supportis another), and those bits get thrown off by seeing the logging
messages yet not seeing a cached Ignition config.
Let's tweak things so that we buffer those messages and only actually
write them out once we've successfully acquired the configs.
While we're here, clean up the base config logging hack now that the
fetchstages are canonical.