Mitchell Hashimoto
efe754183b
state/remote: export ClientLocker, test for implementation
...
This adds unit tests (that will fail at compile time) if various structs
don't implement the right interfaces for locking
2017-02-15 14:20:59 -08:00
James Bardin
ec00564be6
Clean up LockInfo and LockError and use them
...
Gove LockInfo a Marshal method for easy serialization, and a String
method for more readable output.
Have the state.Locker implementations use LockError when possible to
return LockInfo and an error.
2017-02-15 14:44:43 -05:00
James Bardin
67bbebce08
Have consul state reutrn the lock ID
...
The lock ID isn't used because the lock is tied to the client, but
return the lock ID to match the behavior of other locks.
2017-02-15 14:44:43 -05:00
James Bardin
cd233fef6a
make consul client pass state.Locker tests
2017-02-15 14:41:55 -05:00
James Bardin
80fab23e04
Don't test consul using demo.consul.io
...
We shoudn't require an external service for unit test.
TODO: create some proper acceptance tests for consul
2017-02-08 11:34:31 -05:00
James Bardin
14d965722e
Use single state.LockInfo struct
...
Remove redundant structures
2017-02-08 11:34:31 -05:00
James Bardin
9b76f6e138
Move TestRemoteLocks to state/remote
...
This was legacy remote state client and backends can use this test
function without an import cycle.
2017-02-08 11:25:52 -05:00
James Bardin
54cac349a3
Add state locking to consul backend
...
Use consul locks to implement state locking. The lock path is state path
+ "/.lock" which matches the consul cli default for locks. Lockinfo is
stored at path + "/.lockinfo".
2017-02-08 11:25:52 -05:00
Mitchell Hashimoto
1f5d425428
backend/remote-state
...
This allows migration of the remote state implementations to a richer
experience including input asking.
2017-01-26 14:33:49 -08:00
