add service mesh controller

add service mesh metrics

remove unused circle yaml

fix travis misconfiguration

fix travis misconfiguration

fix travis misconfiguration

vendor/github.com/go-logr/logr/README.md

@@ -1,36 +0,0 @@
-# A more minimal logging API for Go
-
-Before you consider this package, please read [this blog post by the inimitable
-Dave Cheney](http://dave.cheney.net/2015/11/05/lets-talk-about-logging).  I
-really appreciate what he has to say, and it largely aligns with my own
-experiences.  Too many choices of levels means inconsistent logs.
-
-This package offers a purely abstract interface, based on these ideas but with
-a few twists.  Code can depend on just this interface and have the actual
-logging implementation be injected from callers.  Ideally only `main()` knows
-what logging implementation is being used.
-
-# Differences from Dave's ideas
-
-The main differences are:
-
-1) Dave basically proposes doing away with the notion of a logging API in favor
-of `fmt.Printf()`.  I disagree, especially when you consider things like output
-locations, timestamps, file and line decorations, and structured logging.  I
-restrict the API to just 2 types of logs: info and error.
-
-Info logs are things you want to tell the user which are not errors.  Error
-logs are, well, errors.  If your code receives an `error` from a subordinate
-function call and is logging that `error` *and not returning it*, use error
-logs.
-
-2) Verbosity-levels on info logs.  This gives developers a chance to indicate
-arbitrary grades of importance for info logs, without assigning names with
-semantic meaning such as "warning", "trace", and "debug".  Superficially this
-may feel very similar, but the primary difference is the lack of semantics.
-Because verbosity is a numerical value, it's safe to assume that an app running
-with higher verbosity means more (and less important) logs will be generated.
-
-This is a BETA grade API.  I have implemented it for
-[glog](https://godoc.org/github.com/golang/glog). Until there is a significant
-2nd implementation, I don't really know how it will change.

vendor/github.com/go-logr/zapr/.gitignore

@@ -1,3 +0,0 @@
-*~
-*.swp
-/vendor

vendor/github.com/go-logr/zapr/Gopkg.lock

@@ -1,52 +0,0 @@
-# This file is autogenerated, do not edit; changes may be undone by the next 'dep ensure'.
-
-
-[[projects]]
-  digest = "1:edd2fa4578eb086265db78a9201d15e76b298dfd0d5c379da83e9c61712cf6df"
-  name = "github.com/go-logr/logr"
-  packages = ["."]
-  pruneopts = "UT"
-  revision = "9fb12b3b21c5415d16ac18dc5cd42c1cfdd40c4e"
-  version = "v0.1.0"
-
-[[projects]]
-  digest = "1:3c1a69cdae3501bf75e76d0d86dc6f2b0a7421bc205c0cb7b96b19eed464a34d"
-  name = "go.uber.org/atomic"
-  packages = ["."]
-  pruneopts = "UT"
-  revision = "1ea20fb1cbb1cc08cbd0d913a96dead89aa18289"
-  version = "v1.3.2"
-
-[[projects]]
-  digest = "1:60bf2a5e347af463c42ed31a493d817f8a72f102543060ed992754e689805d1a"
-  name = "go.uber.org/multierr"
-  packages = ["."]
-  pruneopts = "UT"
-  revision = "3c4937480c32f4c13a875a1829af76c98ca3d40a"
-  version = "v1.1.0"
-
-[[projects]]
-  digest = "1:9580b1b079114140ade8cec957685344d14f00119e0241f6b369633cb346eeb3"
-  name = "go.uber.org/zap"
-  packages = [
-    ".",
-    "buffer",
-    "internal/bufferpool",
-    "internal/color",
-    "internal/exit",
-    "zapcore",
-  ]
-  pruneopts = "UT"
-  revision = "eeedf312bc6c57391d84767a4cd413f02a917974"
-  version = "v1.8.0"
-
-[solve-meta]
-  analyzer-name = "dep"
-  analyzer-version = 1
-  input-imports = [
-    "github.com/go-logr/logr",
-    "go.uber.org/zap",
-    "go.uber.org/zap/zapcore",
-  ]
-  solver-name = "gps-cdcl"
-  solver-version = 1

vendor/github.com/go-logr/zapr/Gopkg.toml

@@ -1,38 +0,0 @@
-# Gopkg.toml example
-#
-# Refer to https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md
-# for detailed Gopkg.toml documentation.
-#
-# required = ["github.com/user/thing/cmd/thing"]
-# ignored = ["github.com/user/project/pkgX", "bitbucket.org/user/project/pkgA/pkgY"]
-#
-# [[constraint]]
-#   name = "github.com/user/project"
-#   version = "1.0.0"
-#
-# [[constraint]]
-#   name = "github.com/user/project2"
-#   branch = "dev"
-#   source = "github.com/myfork/project2"
-#
-# [[override]]
-#   name = "github.com/x/y"
-#   version = "2.4.0"
-#
-# [prune]
-#   non-go = false
-#   go-tests = true
-#   unused-packages = true
-
-
-[[constraint]]
-  name = "github.com/go-logr/logr"
-  version = "0.1.0"
-
-[[constraint]]
-  name = "go.uber.org/zap"
-  version = "1.8.0"
-
-[prune]
-  go-tests = true
-  unused-packages = true

vendor/github.com/go-logr/zapr/README.md

@@ -1,45 +0,0 @@
-Zapr :zap:
-==========
-
-A [logr](https://github.com/go-logr/logr) implementation using
-[Zap](go.uber.org/zap).
-
-Usage
------
-
-```go
-import (
-    "fmt"
-
-    "go.uber.org/zap"
-    "github.com/go-logr/logr"
-    "github.com/directxman12/zapr"
-)
-
-func main() {
-    var log logr.Logger
-
-    zapLog, err := zap.NewDevelopment()
-    if err != nil {
-        panic(fmt.Sprintf("who watches the watchmen (%v)?", err))
-    }
-    log = zapr.NewLogger(zapLog)
-
-    log.Info("Logr in action!", "the answer", 42)
-}
-```
-
-Implementation Details
-----------------------
-
-For the most part, concepts in Zap correspond directly with those in logr.
-
-Unlike Zap, all fields *must* be in the form of suggared fields --
-it's illegal to pass a strongly-typed Zap field in a key position to any
-of the logging methods (`Log`, `Error`).
-
-Levels in logr correspond to custom debug levels in Zap.  Any given level
-in logr is represents by its inverse in Zap (`zapLevel = -1*logrLevel`).
-
-For example `V(2)` is equivalent to log level -2 in Zap, while `V(1)` is
-equivalent to Zap's `DebugLevel`.