Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

install: Add --copy-etc #267

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

cgwalters
Copy link
Collaborator

@cgwalters cgwalters commented Jan 17, 2024

This allows injection of arbitrary config files from an external source into the target root.

This is pretty low tech...I'd really like to also support structured, cleanly "day 2" updatable configmaps, etc.

But there is simply no getting away from the generally wanting the ability to inject arbitrary machine-local external state today. It's the lowest common denominator that applies across many use cases.

We're agnostic to how the data is provided; that could be fetched from cloud instance metadata, the hypervisor, a USB stick, config state provided for bootc-image-builder, etc.

Just one technical implementation point, we do handle SELinux labeling here in a consistent way at least.

Closes: #531

Copy link

openshift-ci bot commented Jan 17, 2024

@cgwalters: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/kola-run 310a6fa link true /test kola-run

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

@cgwalters
Copy link
Collaborator Author

(OK yeah, need to wean this project off of FCOS for testing...gets into the messy topic of what other framework)

}
r += copy_unmanaged_etc(sepolicy, src, dest, path)?;
} else {
dest.remove_file_optional(&path)?;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or, like Ignition should we default to failing when there is an extant file there? That gets annoying though because suddenly one needs an extra override flag for when it's truly necessary.

@cgwalters
Copy link
Collaborator Author

That said...hmm. Maybe even without a registry, we should really still track this filesystem state in a somewhat more rigorous way by keeping each individual provided path as an extra hidden layer (ostree commit/ref), something like bootc-<staterootname>-etc-<name> or so. Or more ideally in the future creating local composefs. The more I think about this the more I like it because it means that we can at least always factory reset - and we can even remove things individually.

And now that we effectively have 3 sources for /etc content:

  • upstream OS
  • initial provisioning state
  • current state

We can diff all three of these. How exactly we make this visible gets tricky...and does still beg the question of supporting more useful metadata for them, and remote fetches.

@cgwalters
Copy link
Collaborator Author

One technical difference here I am seeing vs systemd confext is that we definitely need to support configuring systemd units via this mechanism.

@cgwalters
Copy link
Collaborator Author

FWIW, I rebased this and cleaned it up a bit. I'm still not totally sure about it though.

This allows injection of arbitrary config files from an external
source into the target root.

This is pretty low tech...I'd really like to also support
structured, cleanly "day 2" updatable configmaps, etc.

But there is simply no getting away from the generally wanting the
ability to inject arbitrary machine-local external state today.
It's the lowest common denominitator that applies across many
use cases.

We're agnostic to *how* the data is provided; that could be fetched
from cloud instance metadata, the hypervisor, a USB stick, config
state provided for bootc-image-builder, etc.

Just one technical implementation point, we do handle SELinux labeling here
in a consistent way at least.

Signed-off-by: Colin Walters <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/install Issues related to `bootc install` do-not-merge/work-in-progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Injecting configuration files after installation, before first boot
1 participant