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

lxcfs: per instance configuration #638

Open
wants to merge 17 commits into
base: main
Choose a base branch
from

Conversation

mihalicyn
Copy link
Member

@mihalicyn mihalicyn commented Apr 29, 2024

This adds ability to set per-container configuration parameters (boolean).

This can be very useful in some workloads if system administrator (or container administrator) want's to have some specific LXCFS configuration in some instances, while having defaults on the other ones.

Change is forward compatible and LXCFS can be updated with live reload. Nothing will crash. Obviously, to make new configuration sub-tree accessible full daemon reload is required.

@mihalicyn mihalicyn requested review from stgraber, brauner and a team April 29, 2024 12:09
@mihalicyn mihalicyn force-pushed the lxcfs_per_inst_config branch 4 times, most recently from ab6ec5e to 7d47c99 Compare May 8, 2024 12:31
@mihalicyn mihalicyn force-pushed the lxcfs_per_inst_config branch 3 times, most recently from e2b98ef to 78f2fd3 Compare June 10, 2024 16:27
@stgraber
Copy link
Member

I did a first pass on this, basically looking at the various commits and what's being modified.
General change seems fine but I'll take a closer look later.

For now, a few things I think that should be done:

  • Split off all the bugfixes/refactor/cleanup changes and send those through a separate PR as we'll want to backport them to stable
  • Rebase that branch which should then basically just be the per-instance config stuff
  • Try to find a way to have this be tested by GH actions

Let's reduce code duplication by using macro for this.

Signed-off-by: Alexander Mikhalitsyn <[email protected]>
Let's allocate pidns_hash_table memory dynamically and hold
pointers to it from a new lxcfs_data structure.

Previously, pidns_hash_table was a statically allocated in liblxcfs,
which means that it won't survive across liblxcfs reloads.

Let's introduce a versionized lxcfs_data structure to keep persistent
data that should survive reloads.

Signed-off-by: Alexander Mikhalitsyn <[email protected]>
It's necessary as we want to be able to easily extend it
and use live reloads update mechanism.

This change does not break compatibility, because struct pidns_store
lifetime is limited to liblxcfs lifetime. But we'll make pidns_store
lifetime bigger that's why we need to start versionizing it.

Signed-off-by: Alexander Mikhalitsyn <[email protected]>
Let's add keep_on_reload field to struct pidns_store.
The idea behind it is that if this flag is set to true, then
pidns_store entry won't be considered as a cache item which can
be dropped. But instead, it will be kept across liblxcfs reloads
and droped only if a pid namespace it refers die.

Signed-off-by: Alexander Mikhalitsyn <[email protected]>
Signed-off-by: Alexander Mikhalitsyn <[email protected]>
This bitmask can be used to represent a per-instance (technically,
per pid namespace) features configuration (toggle-like).

Signed-off-by: Alexander Mikhalitsyn <[email protected]>
Signed-off-by: Alexander Mikhalitsyn <[email protected]>
Like we have "cgroup", "sys", "proc" subtrees,
let's introduce the "lxcfs" subtree which will
contain LXCFS filesystem-related data and will
be used as an interface to interact and configure
LXCFS in runtime.

Signed-off-by: Alexander Mikhalitsyn <[email protected]>
Signed-off-by: Alexander Mikhalitsyn <[email protected]>
Signed-off-by: Alexander Mikhalitsyn <[email protected]>
@hallyn
Copy link
Member

hallyn commented Nov 13, 2024

Looks like some good stuff. Will take some time to review, though. Would be cool if there was an easy way on github to say "patch 1/N is approved and separate, merge it". Perhaps conceptually the thing to do here (I'm not asking you to change it, just thinking...) would be to create a github project, have an issue for each independent change in this pr, and a pr for each issue. I say this because if you just made this N PRs, i'd possibly be less likely to look at the earlier ones.

Anyway, thanks, I intend to take a close look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants