feat: add --force-render-cgroup args to make lxcfs render in view of specific cgroup

[okhowang]

it's useful in some complex container hierarchy,
many container work in same parent cgroup for sharing resource (cpu and other)
but need inspect total usage of parent cgroup in single container

[mihalicyn]

Hi @okhowang,

please, could you sign-off your commit in accordance with our contribution guideline (https://github.com/lxc/lxcfs/blob/main/CONTRIBUTING.md).

Also, please, describe your changes and use case. From what I see in the code, you basically force to always use the same cgroup to take data from.

Kind regards,
Alex

[mihalicyn]

I've left a comment before.

[okhowang]

I use --cgroup-parent and --pid to compose multiple container in a unified resource limit and pid namespace, just like a vm.

# setup main.slice cgroup
docker run --cgroup-parent main.slice --name main debian # as main container
docker run --cgroup-parent main.slice --pid container:main --name sidecar debian # as sidecar container 
# and more container

in the pattern containers can see each others, and share same resource.
but if they inspect their resource limit via lxcfs, lxcfs will always render the pid namespace owner's resource (the main containers)

because docker will create a new cgroup in cgroup-parent
e'g main.slice/docker-a.scope main.slice/docker-b.scope and so on.
all containers will get resource view for main.slice/docker-main.scope, because main containers is pid namespace owner.

I want they all got resource view in main.slice

[mihalicyn]

I want they all got resource view in main.slice

Now this makes sense. Basically, you don't need all the machinery we have to find init process of the container, then figure out in which cgroups it sits, you want LXCFS to always take all the information from a statically defined cgroup.

cc @stgraber, WDYT about this feature?

[stgraber]

cc @stgraber, WDYT about this feature?

At minimum it needs a better name because I still don't understand what it does ;)

In general LXCFS is really meant for the needs of LXC and related projects. I don't mind small changes that make Docker's life easier, but I would push back on larger features that we realistically won't care about, may break at any point and could expose us to additional vulnerabilities.

I'm not saying it's the case here, but I'd definitely prefer such changes be kept as simple as possible.

For us, having LXCFS look up purely based on cgroup isn't useful as 99% of containers we care about run systemd and so create a complex cgroup hierarchy inside the container with basically each process living in a different cgroup.

So again, not necessarily opposed to this, but I'd want:

• A much clearer name for the option
• Documentation on what it does
• Test to ensure we don't regress it down the line (since none of us will care about this)
• Making the change as small as possible and try to make it so we don't have logic spread all over if possible

[okhowang]

I have renamed options to --cgroup-override. Does it meaningful?
testing and unfied cgroup resolving function was added too.