The sync frequency should be part of the syncLoop and resync no
less often than every X seconds. The current implementation runs
even if a config update was delivered less than X seconds ago.
If the docker daemon goes down and comes up, it will try to restart
containers. This will race with our own restart loop. Only one loop should
be controlling restarts, probably.
Different information is needed to perform setup versus teardown. It
makes sense to separate these two interfaces since when we call teardown
from the reconciliation loop, we cannot rely on having the
information provided by the api definition of the volume.
Determines the set of active volumes versus the set of valid volumes
defined by the manifests. If there is an active volume that is not
defined in any of the manifests, deletes and cleans up that volume.
Contains breaking API change on api.Status#Details (type change)
Turn Details from string -> StatusDetails - a general
bucket for keyed error behavior. Define an open enumeration
ReasonType exposed as Reason on the status object to provide
machine readable subcategorization beyond HTTP Status Code. Define
a human readable field Message which is common convention (previously
this was joined into Details).
Precedence order: HTTP Status Code, Reason, Details. apiserver would
impose restraints on the ReasonTypes defined by the main apiobject,
and ensure their use is consistent.
There are four long term scenarios this change supports:
1. Allow a client access to a machine readable field that can be
easily switched on for improving or translating the generic
server Message.
2. Return a 404 when a composite operation on multiple resources
fails with enough data so that a client can distinguish which
item does not exist. E.g. resource Parent and resource Child,
POST /parents/1/children to create a new Child, but /parents/1
is deleted. POST returns 404, ReasonTypeNotFound, and
Details.ID = "1", Details.Kind = "parent"
3. Allow a client to receive validation data that is keyed by
attribute for building user facing UIs around field submission.
Validation is usually expressed as map[string][]string, but
that type is less appropriate for many other uses.
4. Allow specific API errors to return more granular failure status
for specific operations. An example might be a minion proxy,
where the operation that failed may be both proxying OR the
minion itself. In this case a reason may be defined "proxy_failed"
corresponding to 502, where the Details field may be extended
to contain a nested error object.
At this time only ID and Kind are exposed
The bug was that the proxier is passed as value on method decleration.
This caused a copy of Proxier to be created when the method was invoked.
The copy being a shallow copy turned out to have them both reference
a same map instance, but their mutexes were different instances.
This turned out to use different mutexes before operating on a same map
instance, which didn't make sense.
