As I outlined in the design docs this is broken, there are several
data races here because we write to the config files that can be read by
other goroutines in parallel which violates the go memory model and
thus can lead to runtime panics and undefined behavior.
One could fix with a mutex but that would make the whole code base much
more ugly and there is still the risk that something would access this
field without the mutex held.
I am not sure we have any users using this, it never worked for the
storage side and since the service is a not a daemon any user could just
stop and start it again to re-read the files without having to stop
running containers.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
a1afa58e27