Also rename some to other names that make better reading. There are still a
bunch of "make" functions but they do things like assemble a string from parts
or build an array of things. It seemed that "make" there seemed fine. "New"
is for "constructors".
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.
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.
Ensure that pods coming from the unit test configuration validate,
and that proper names are generated.
Lowercases source filenames, strips all but a-z0-9, and tests
for consistent results.
math.MaxInt64 represents 8 exabytes, which is a good limit for memory.
Also, this is the type used by Docker, so it's not possible to get any
value bigger than math.MaxInt64 as memory limit (both ram and swap) on a
Docker container.
Relevant discussion at #589 (more precisely,
https://github.com/GoogleCloudPlatform/kubernetes/pull/589#issuecomment-50640605).
Currently all commands are being build with extra flags. The extra
flags appear because of a direct import of the testing package from
the fake_etcd_client.go source file.
Remove the direct import of the testing package. Add a tools.T
interface to support existing behavior. Also clean up two TODO items
by remove using of the expectError and expectNoError functions.
Fixes#579
This makes two main changes:
- Runs syncPod in a separate Go routine (and enforces only one of those
runs at a time).
- Uses the pod list to determine if a container should be running or
should be killed (used to use the output of syncPod).
Since Docker pulls are synchronized by the Docker daemon we still block
on that, but pods can now be removed and prepared for starting without
blocking on long pulls.
Daniel Smith