Skip to content

Conversation

@champtar
Copy link
Contributor

2 use cases I have in mind:

@champtar champtar force-pushed the adjustement-namespaces branch from 8e194a2 to 91fba35 Compare January 23, 2025 02:45
@klihub klihub self-requested a review January 23, 2025 06:35
@klihub
Copy link
Member

klihub commented Jan 23, 2025

@champtar AFAICT, this is an alternative implementation of #124.

@champtar champtar force-pushed the adjustement-namespaces branch from 91fba35 to e4ab673 Compare January 23, 2025 13:53
@champtar
Copy link
Contributor Author

@klihub indeed ...
Now that I've written it, mine is more fine grained, ie you can add / modify / remove individual namespaces

@champtar
Copy link
Contributor Author

Ci is broken: /bin/sh: 2: protoc: not found

@champtar
Copy link
Contributor Author

@klihub as there is some interest in having namespaces adjustment, can you ping the right persons to move this PR or #124 forward ?

@klihub
Copy link
Member

klihub commented Jan 23, 2025

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
Copy link
Member

klihub commented Jan 23, 2025

@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 ?

@klihub
Copy link
Member

klihub commented Jun 12, 2025

@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

@champtar
Copy link
Contributor Author

@klihub klihub force-pushed the adjustement-namespaces branch from 29bb2a8 to 1e461b4 Compare June 12, 2025 09:42
@klihub
Copy link
Member

klihub commented Jun 12, 2025

@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 ?

@champtar
Copy link
Contributor Author

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

@klihub klihub requested review from djdongjin, fuweid and mikebrow June 12, 2025 19:00
@klihub klihub force-pushed the adjustement-namespaces branch from 1e461b4 to 3d34356 Compare June 13, 2025 07:18
@klihub klihub force-pushed the adjustement-namespaces branch from 3d34356 to 93c5abe Compare July 14, 2025 13:40
@mikebrow
Copy link
Member

let's wait to rebase this on #123

@mikebrow mikebrow added the v.next to be merged into the next release label Jul 14, 2025
@mikebrow
Copy link
Member

pls rebase...

champtar added 2 commits July 14, 2025 21:27
One line change in api.proto and regenerate the pb.go files.

Signed-off-by: Etienne Champetier <[email protected]>
Signed-off-by: Krisztian Litkey <[email protected]>
Signed-off-by: Etienne Champetier <[email protected]>
Signed-off-by: Krisztian Litkey <[email protected]>
@klihub klihub force-pushed the adjustement-namespaces branch from 93c5abe to ef933bb Compare July 14, 2025 18:52
@klihub
Copy link
Member

klihub commented Jul 15, 2025

pls rebase...

@mikebrow Rebased and pushed.

Copy link
Member

@mikebrow mikebrow left a comment

Choose a reason for hiding this comment

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

just one question around the TODO..

// AddOrReplaceNamespace records the addition or replacement of the given namespace to a container.
func (a *ContainerAdjustment) AddOrReplaceNamespace(n *LinuxNamespace) {
a.initLinuxNamespaces()
a.Linux.Namespaces = append(a.Linux.Namespaces, n) // TODO: should we dup n here ?
Copy link
Member

Choose a reason for hiding this comment

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

What do you mean by this TODO? oci only allows one namespace per type and the func we are calling AddOrReplaceLinuxNamespace ensures that..

Copy link
Member

@klihub klihub Jul 15, 2025

Choose a reason for hiding this comment

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

@mikebrow It's related to the similar comments about the corresponding helpers for mounts and [CDI] devices (as this is done consistently with those).

Basically we append here the user-supplied n *LinuxNamespace as such to the set of adjustments, as opposed to appending a copy of it. That (being a pointer) allows the user, in principle, to modify it once it has been recorded as an adjustment.

Since the plugin can only shoot itself in the foot with that, I think no too big harm is done. But I think it's good to have the comments in place, so that if we ever decide to change one, we update all the others consistently.

@klihub klihub requested a review from mikebrow July 16, 2025 14:09
champtar and others added 6 commits July 16, 2025 17:19
Signed-off-by: Etienne Champetier <[email protected]>

Update adjustment plugin ownership tracking and conflict detection
using the revised pkg/api-based infra.

Signed-off-by: Krisztian Litkey <[email protected]>
Signed-off-by: Etienne Champetier <[email protected]>
Signed-off-by: Krisztian Litkey <[email protected]>
Signed-off-by: Etienne Champetier <[email protected]>
Signed-off-by: Krisztian Litkey <[email protected]>
Add LinuxNamespace plugin/owner lookup for validation.

Signed-off-by: Krisztian Litkey <[email protected]>
Implement configurable restriction of namespace adjustment in
the default validator.

Signed-off-by: Krisztian Litkey <[email protected]>
@klihub klihub force-pushed the adjustement-namespaces branch from ef933bb to 7d06097 Compare July 16, 2025 14:19
Copy link
Member

@mikebrow mikebrow left a comment

Choose a reason for hiding this comment

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

LGTM

@mikebrow mikebrow merged commit c753be1 into containerd:main Jul 16, 2025
7 checks passed
@champtar champtar deleted the adjustement-namespaces branch July 16, 2025 15:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

v.next to be merged into the next release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants