From 149f2b13d110f34f048e5942466faea4e1a4a870 Mon Sep 17 00:00:00 2001 From: Dave Henderson Date: Tue, 5 Dec 2017 08:10:13 -0500 Subject: Pruning dependencies with `dep prune` Signed-off-by: Dave Henderson --- .../github.com/docker/libkv/docs/compatibility.md | 82 ----------- vendor/github.com/docker/libkv/docs/examples.md | 157 --------------------- 2 files changed, 239 deletions(-) delete mode 100644 vendor/github.com/docker/libkv/docs/compatibility.md delete mode 100644 vendor/github.com/docker/libkv/docs/examples.md (limited to 'vendor/github.com/docker/libkv/docs') diff --git a/vendor/github.com/docker/libkv/docs/compatibility.md b/vendor/github.com/docker/libkv/docs/compatibility.md deleted file mode 100644 index c4f27e9c..00000000 --- a/vendor/github.com/docker/libkv/docs/compatibility.md +++ /dev/null @@ -1,82 +0,0 @@ -#Cross-Backend Compatibility - -The value of `libkv` is not to duplicate the code for programs that should support multiple distributed K/V stores like the classic `Consul`/`etcd`/`zookeeper` trio. - -This document provides with general guidelines for users willing to support those backends with the same code using `libkv`. - -Please note that most of those workarounds are going to disappear in the future with `etcd` APIv3. - -##Etcd directory/key distinction - -`etcd` with APIv2 makes the distinction between keys and directories. The result with `libkv` is that when using the etcd driver: - -- You cannot store values on directories -- You cannot invoke `WatchTree` (watching on child values), on a regular key - -This is fundamentaly different than `Consul` and `zookeeper` which are more permissive and allow the same set of operations on keys and directories (called a Node for zookeeper). - -Apiv3 is in the work for `etcd`, which removes this key/directory distinction, but until then you should follow these workarounds to make your `libkv` code work across backends. - -###Put - -`etcd` cannot put values on directories, so this puts a major restriction compared to `Consul` and `zookeeper`. - -If you want to support all those three backends, you should make sure to only put data on **leaves**. - -For example: - -```go -_ := kv.Put("path/to/key/bis", []byte("foo"), nil) -_ := kv.Put("path/to/key", []byte("bar"), nil) -``` - -Will work on `Consul` and `zookeeper` but fail for `etcd`. This is because the first `Put` in the case of `etcd` will recursively create the directory hierarchy and `path/to/key` is now considered as a directory. Thus, values should always be stored on leaves if the support for the three backends is planned. - -###WatchTree - -When initializing the `WatchTree`, the natural way to do so is through the following code: - -```go -key := "path/to/key" -if !kv.Exists(key) { - err := kv.Put(key, []byte("data"), nil) -} -events, err := kv.WatchTree(key, nil) -``` - -The code above will not work across backends and etcd will fail on the `WatchTree` call. What happens exactly: - -- `Consul` will create a regular `key` because it has no distinction between directories and keys. This is not an issue as we can invoke `WatchTree` on regular keys. -- `zookeeper` is going to create a `node` that can either be a directory or a key during the lifetime of a program but it does not matter as a directory can hold values and be watchable like a regular key. -- `etcd` is going to create a regular `key`. We cannot invoke `WatchTree` on regular keys using etcd. - -To be cross-compatible between those three backends for `WatchTree`, we need to enforce a parameter that is only interpreted with `etcd` and which tells the client to create a `directory` instead of a key. - -```go -key := "path/to/key" -if !kv.Exists(key) { - // We enforce IsDir = true to make sure etcd creates a directory - err := kv.Put(key, []byte("data"), &store.WriteOptions{IsDir:true}) -} -events, err := kv.WatchTree(key, nil) -``` - -The code above will work for the three backends but make sure to not try to store any value at that path as the call to `Put` will fail for `etcd` (you can only put at `path/to/key/foo`, `path/to/key/bar` for example). - -##Etcd distributed locking - -There is `Lock` mechanisms baked in the `coreos/etcd/client` for now. Instead, `libkv` has its own implementation of a `Lock` on top of `etcd`. - -The general workflow for the `Lock` is as follows: - -- Call Lock concurrently on a `key` between threads/programs -- Only one will create that key, others are going to fail because the key has already been created -- The thread locking the key can get the right index to set the value of the key using Compare And Swap and effectively Lock and hold the key -- Other threads are given a wrong index to fail the Compare and Swap and block until the key has been released by the thread holding the Lock -- Lock seekers are setting up a Watch listening on that key and events happening on the key -- When the thread/program stops holding the lock, it deletes the key triggering a `delete` event that will notify all the other threads. In case the program crashes, the key has a TTL attached that will send an `expire` event when this TTL expires. -- Once everyone is notified, back to the first step. First come, first served with the Lock. - -The whole Lock process is highly dependent on the `delete`/`expire` events of `etcd`. So don't expect the key to be still there once the Lock is released. - -For example if the whole logic is to `Lock` a key and expect the value to still be there after it has been unlocked, it is not going to be cross-backend compatible with `Consul` and `zookeeper`. On the other end the `etcd` Lock can still be used to do Leader Election for example and still be cross-compatible with other backends. \ No newline at end of file diff --git a/vendor/github.com/docker/libkv/docs/examples.md b/vendor/github.com/docker/libkv/docs/examples.md deleted file mode 100644 index 09752db1..00000000 --- a/vendor/github.com/docker/libkv/docs/examples.md +++ /dev/null @@ -1,157 +0,0 @@ -#Examples - -This document contains useful example of usage for `libkv`. It might not be complete but provides with general informations on how to use the client. - -##Create a store and use Put/Get/Delete - -```go -package main - -import ( - "fmt" - "time" - "log" - - "github.com/docker/libkv" - "github.com/docker/libkv/store" - "github.com/docker/libkv/store/consul" -) - -func init() { - // Register consul store to libkv - consul.Register() - - // We can register as many backends that are supported by libkv - etcd.Register() - zookeeper.Register() - boltdb.Register() -} - -func main() { - client := "localhost:8500" - - // Initialize a new store with consul - kv, err := libkv.NewStore( - store.CONSUL, // or "consul" - []string{client}, - &store.Config{ - ConnectionTimeout: 10*time.Second, - }, - ) - if err != nil { - log.Fatal("Cannot create store consul") - } - - key := "foo" - err = kv.Put(key, []byte("bar"), nil) - if err != nil { - fmt.Errorf("Error trying to put value at key: %v", key) - } - - pair, err := kv.Get(key) - if err != nil { - fmt.Errorf("Error trying accessing value at key: %v", key) - } - - err = kv.Delete(key) - if err != nil { - fmt.Errorf("Error trying to delete key %v", key) - } - - log.Info("value: ", string(pair.Value)) -} -``` - -##List keys - -```go -// List will list all the keys under `key` if it contains a set of child keys/values -entries, err := kv.List(key) -for _, pair := range entries { - fmt.Printf("key=%v - value=%v", pair.Key, string(pair.Value)) -} - -``` - -##Watching for events on a single key (Watch) - -You can use watches to watch modifications on a key. First you need to check if the key exists. If this is not the case, we need to create it using the `Put` function. - -```go -// Checking on the key before watching -if !kv.Exists(key) { - err := kv.Put(key, []byte("bar"), nil) - if err != nil { - fmt.Errorf("Something went wrong when initializing key %v", key) - } -} - -stopCh := make(<-chan struct{}) -events, err := kv.Watch(key, stopCh) - -select { - case pair := <-events: - // Do something with events - fmt.Printf("value changed on key %v: new value=%v", key, pair.Value) -} - -``` - -##Watching for events happening on child keys (WatchTree) - -You can use watches to watch modifications on a key. First you need to check if the key exists. If this is not the case, we need to create it using the `Put` function. There is a special step here though if you want your code to work across backends. Because `etcd` is a special case and it makes the distinction between directories and keys, we need to make sure that the created key is considered as a directory by enforcing `IsDir` at `true`. - -```go -// Checking on the key before watching -if !kv.Exists(key) { - // Don't forget IsDir:true if the code is used cross-backend - err := kv.Put(key, []byte("bar"), &store.WriteOptions{IsDir:true}) - if err != nil { - fmt.Errorf("Something went wrong when initializing key %v", key) - } -} - -stopCh := make(<-chan struct{}) -events, err := kv.WatchTree(key, stopCh) - -select { - case pairs := <-events: - // Do something with events - for _, pair := range pairs { - fmt.Printf("value changed on key %v: new value=%v", key, pair.Value) - } -} - -``` - -## Distributed Locking, using Lock/Unlock - -```go -key := "lockKey" -value := []byte("bar") - -// Initialize a distributed lock. TTL is optional, it is here to make sure that -// the lock is released after the program that is holding the lock ends or crashes -lock, err := kv.NewLock(key, &store.LockOptions{Value: value, TTL: 2 * time.Second}) -if err != nil { - fmt.Errorf("something went wrong when trying to initialize the Lock") -} - -// Try to lock the key, the call to Lock() is blocking -_, err := lock.Lock(nil) -if err != nil { - fmt.Errorf("something went wrong when trying to lock key %v", key) -} - -// Get should work because we are holding the key -pair, err := kv.Get(key) -if err != nil { - fmt.Errorf("key %v has value %v", key, pair.Value) -} - -// Unlock the key -err = lock.Unlock() -if err != nil { - fmt.Errorf("something went wrong when trying to unlock key %v", key) -} -``` \ No newline at end of file -- cgit v1.2.3