Do not fetch pod and ctr State on retrieval in Bolt

It's not necessary to fill in state immediately, as we'll be
overwriting it on any API call accessing it thanks to
syncContainer(). It is also causing races when we fetch it
without holding the container lock (which syncContainer() does).
As such, just don't retrieve the state on initial pull from the
database with Bolt.

Also, refactor some Linux-specific netns handling functions out
of container_internal_linux.go into boltdb_linux.go.

Signed-off-by: Matthew Heon <matthew.heon@gmail.com>

Closes: #1186
Approved by: rhatdan

1 files changed, 13 insertions, 1 deletions

diff --git a/libpod/state.go b/libpod/state.go
index 1b82349b3..273e81318 100644
--- a/libpod/state.go
+++ b/libpod/state.go
@@ -1,6 +1,18 @@
 package libpod
 
-// State is a storage backend for libpod's current state
+// State is a storage backend for libpod's current state.
+// A State is only initialized once per instance of libpod.
+// As such, initialization methods for State implementations may safely assume
+// they will be run as a singleton.
+// For all container and pod retrieval methods, a State must retrieve the
+// Configuration struct of the container or pod and include it in the returned
+// struct. The State of the container or pod may optionally be included as well,
+// but this is not a requirement.
+// As such, all containers and pods must be synced with the database via the
+// UpdateContainer and UpdatePod calls before any state-specific information is
+// retrieved after they are pulled from the database.
+// Generally speaking, the syncContainer() call should be run at the beginning
+// of all API operations, which will silently handle this.
 type State interface {
 	// Close performs any pre-exit cleanup (e.g. closing database
 	// connections) that may be required