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 2 times, most recently from df815c2 to e2b98ef Compare June 10, 2024 14:36
Let's reduce code duplication by using macro for this.

Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
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 <aleksandr.mikhalitsyn@canonical.com>
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 <aleksandr.mikhalitsyn@canonical.com>
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 <aleksandr.mikhalitsyn@canonical.com>
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
…pear

Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
This bitmask can be used to represent a per-instance (technically,
per pid namespace) features configuration (toggle-like).

Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
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 <aleksandr.mikhalitsyn@canonical.com>
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
@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

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.

2 participants