I can't say how exactly those conflicts happen in the tests, but I tried
to randomize more container IDs and namespace names (which both feed
into final abstract unix socket path).
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
The problem was that if container fails to start, it never reaches
'StateRunning' and test hangs waiting for that state. Assertion doesn't
abort whole test (it only aborts goroutine it was called from), so this
doesn't help.
Fix that by signalling back if some containers fail to start.
This is not a fix, but it should expose the actual failure happening in
this test.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This moves from translating a config into an internal config
representation, to using an interface. The idea is that an interface
gives us stronger compile time checks, and will prevent us from having to copy
from on struct to another. As long as a concrete type implements the
Configurator interface, it can be used to provide instructions to Talos.
Signed-off-by: Andrew Rynhard <andrew@andrewrynhard.com>
Looks like containerd creates shim file sockets in Linux abstract
namespace which are fixed (don't depend on containerd root directory)
and depend on container namespace and id. So if two containerd instances
on the same host run same namespace/id pair, that is going to create a
conflict on that shim filesocket.
Avoid that by randomizing namespace name. CRI tests should be fine as
namespace is fixed, but container ID is random.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This makes test launch their own isolated instance of containerd with
its own root/state directories and listening socket address. Each test
brings this instance up/down on its own.
Add options to override containerd address in the code (used only in the
tests).
Enable parallel go test runs once again.
P.S. I wish I could share that 'SetupSuite' phase across the tests, but
afaik there's no way in Go to share `_test.go` code across packages. If
we put it as normal package, this might pull in test dependencies (like
`testify`) into production code, which I don't like.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
