The linter found staticcheck and errorcheck issues. Deferred statements now use join to combine any new error with an existing one, preventing error information from being lost. Other minor error checks, like for printing text and flushing data have also been addressed.
This new entrypoint takes an Ignition config and applies it to the
current rootfs (or one provided by `-root`). This tool could then be
used as part of build processes where we want to bake an Ignition
config, such as in CoreOS layering:
https://github.com/coreos/enhancements/blob/main/os/coreos-layering.md
This in turn should also help drain from the MCO the re-implementation
of large parts of the Ignition spec.
Another approach would be to build on top of `ignition -stage=files`,
but in the end I think we want a cleaner dedicated UX for this workflow
long-term (and in fact we should clean up the hacky places where we call
Ignition like this).
It shouldn't be used by end-users to live apply changes to their
Ignition config. A check that we are in a container is added as a
safeguard against this.
By default, unsupported modifications (like partitioning) trigger
errors, though one may pass `-ignore-unsupported` to override this. Also
by default, remote resources are automatically fetched, though one may
pass `-offline` to override this.
In Ignition 2.x, the Parse() function from an individual config package
doesn't chain to earlier specs, but this code still assumed it does.
As a result, all configs with stable spec versions would fail on
ErrUnknownVersion, but we wouldn't notice because we were only looking
at the report and not the error return.
Switch to the high-level chaining parse function. Also, check for parse
errors that aren't included in the report.
To improve compatibility with Jekyll Markdown support, use an different
marker to signal valid Ignition configs that should be tested in the
documentation.
Right now Ignition will incorrectly report that it needs networking when
an empty scheme is given. Modify the `UrlNeedsNet` function to allow
both `data` & empty schemes.
A common case that could hit this is a config that writes a file with
empty contents.
Add a new `fetch-offline` stage which can optionally be run before the
`fetch` stage. The major difference between the two is that the former
tries to operate in offline mode: if it encounters any resource which
requires network access, it quietly exits, creating a stamp file on the
way out.
This allows OS integrators to make use of this to only bring up
networking if Ignition actually requires it. It does not solve the
harder problem of "partially" up networking, where some fetches might
succeed and some others might fail. However, it provides an incremental
step to get there by reusing the same signalling mechanism.
Bumps the import path to be `github.com/coreos/ignition/v2`, this is
required to be able to import the v2 of Ignition alongside v0 in other
repositories.
Lets use config/version instead of copying that to internal/config and
translating to it. This allow us to define extra functions on the types
for use by the internal code. This enable us to define functions
describing the "primary key" of all list entries in the config.
Without logic specific to the schema structs in internal/config (keeping
it out of there simplifies stable spec bumps), this logic must be
duplicated into internal.
A following commit will have code in internal/resource use things from
the moved file, and having internal/resource import internal/exec would
result in a dependency loop.
If a value is passed to root other than the default of '/' then
the baseConfig will point to the given value rather than
'/sysroot'.
Also updates the RenderFile function from
'internal/exec/util/file.go' to be a member function of Util to
allow the given root parameter to be used rather than always using
'/sysroot'.
Recent changes allowing node owners to be referenced by user/group names
changed the id field for the user and group to be a pointer, so that it
could be detected when it was left empty vs when it was specified to be
0. The simple example given to justify this was when a user provided a
config saying that the node should be owned by user "core" and uid "0",
if the id was not a pointer it would appear to Ignition as if they had
not provided a uid.
The logic dealing with setting the UID failed to properly handle nil
values here, and can cause nil pointer dereferences. This commit adds a
check and an assignment to fix this for both of these fields.
If a node's owner is unspecified, it will default to the root user and
group.
Ignition now ships with support for an experimental config. Because this
config is experimental, it is denoted with a semantic version
pre-release tag.
This now ensures that all fetching goes through the same entry point,
regardless of URL scheme. This bit us before because providers were
calling into the HttpClient directly, bypassing the scheme-check.
The original intention of this code was to retry requests if the remote
server didn't return content. This caused issues for the HTTP-based
providers because they will return a 404 when there is no userdata.
Since the underlying purpose of this retry is to handle transient
errors, it makes sense to only retry if there is a network error or if
the remote system returned a 5xx error.
This will allow the cmdline provider to accept data URLs, files to
reference contents on the OEM partition, and configs to reference remote
configs on the OEM partition.
