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
Is your feature request related to a problem? Please describe.
If multiple stacker instances are invoked for the same tag/target, they may step on each other since the lxc control socket is not unique per container.
Describe the solution you'd like
Make the lxc control socket unique per container.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
note that the simplest way to do this is probably to make the container name used for a build include some randomness.
lxc uses the lxcpath and container name to name the control socket, and nothing outside of stacker really cares what the container name is.
however for the lxcpath, stacker uses the --roots-dir argument - since this comes from the user, uniquifying it might be slightly more involved. (we could make a unique subdir, but we'd have to thread that through the stacker code)
How does it happen that two stackers use the same roots-dir argument but shouldn't conflict?
in some cases, concurrent runs of stacker on the same host might have the same path for the roots-dir arg, even though they aren't actually sharing it - e.g. if they are running in separate mount ns's.
Is your feature request related to a problem? Please describe.
If multiple stacker instances are invoked for the same tag/target, they may step on each other since the lxc control socket is not unique per container.
Describe the solution you'd like
Make the lxc control socket unique per container.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: