nri
nri copied to clipboard
Allow to adjust LinuxNamespaces
2 use cases I have in mind:
- add cgroup namespace for k8s privileged pods
- enable time namespace (depends at least on https://github.com/opencontainers/runtime-tools/issues/783)
@champtar AFAICT, this is an alternative implementation of #124.
@klihub indeed ... Now that I've written it, mine is more fine grained, ie you can add / modify / remove individual namespaces
Ci is broken: /bin/sh: 2: protoc: not found
@klihub as there is some interest in having namespaces adjustment, can you ping the right persons to move this PR or #124 forward ?
Ci is broken:
/bin/sh: 2: protoc: not found
It's not CI per se IMO, rather I think some github-related PITA that hits us with regular irregularity.
What happens is that every once in a while for some reason the protobuf source is cloned with a newer timestamp than the compiled bindings. When this happens our build system tries to rebuild them, but can't since we deliberately leave protoc uninstalled... because commits touching the protocol should commit both the protobuf and the generated sources.
Maybe the right thing to do would be to always install protoc and the plugins we need, then always force a recompilation, and finally check that there are no changes. Why I'm reluctant to do that is that it would also implicitly/indirectly force everyone to use the same protoc{-gen-go,} versions, since those are emitted to the generated sources...
Anyway, I retriggered the workflow for you, and it looks like the coin flipped the other way this time, because it succeeded.
@klihub indeed ... Now that I've written it, mine is more fine grained, ie you can add / modify / remove individual namespaces
Currently there is a pair of PRs (#123, #124) with security implications, and it's actively being discussed what additional infra bits we'd need (mostly the ability to lock down selected adjustment capabilities in NRI administratively) so that everybody would feel confident enough about taking those changes in. Your PR is an alternative implementation of #124, so if you have valid uses cases for all of these additional capabilities, could you chime in #124 and point to this PR of yours as an alternative ?
@champtar We should rebase this on latest main/HEAD and allow namespace adjustment to be locked via validation. For instance, like this: https://github.com/klihub/nri/tree/devel/champtar/adjustment-namespaces
@klihub if you've already done the work, do not hesitate to update this PR https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork
@klihub if you've already done the work, do not hesitate to update this PR https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork
Ah, ok. Thanks for the tip. I did not realize that was possible. I pushed the updates. Is it okay with you if I leave you as the author of the updated original commits ?
Ah, ok. Thanks for the tip. I did not realize that was possible. I pushed the updates. Is it okay with you if I leave you as the author of the updated original commits ?
What I usually do in this situation is keep the same commit author and add what was modified in [] + my signed-off-by
Signed-off-by: original author
[rework x y z / fix typo / ...]
Signed-off-by: me
let's wait to rebase this on #123
pls rebase...
pls rebase...
@mikebrow Rebased and pushed.