You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Generally speaking, but specifically in our test rig, we rely on buildkitd running on the host.
This comes with some issues when testing:
buildkitd is started with a hardcoded namespace (nerdctl-test), which makes it impossible to namespace tests (eg: impossible to parallelize, as most of these tests require a clean house)
it is hard or not really possible (again in testing) to change buildkitd settings
I am wondering if there is a strong reason for running buildkitd on the host, instead of running it in a container, on-demand, (possibly inside a nerdctl_protected_system namespace that users would not see) - be it during testing, or at runtime.
Maybe there are structural reasons to have it on the host?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Generally speaking, but specifically in our test rig, we rely on buildkitd running on the host.
This comes with some issues when testing:
nerdctl-test
), which makes it impossible to namespace tests (eg: impossible to parallelize, as most of these tests require a clean house)I am wondering if there is a strong reason for running buildkitd on the host, instead of running it in a container, on-demand, (possibly inside a
nerdctl_protected_system
namespace that users would not see) - be it during testing, or at runtime.Maybe there are structural reasons to have it on the host?
Beta Was this translation helpful? Give feedback.
All reactions