add service mesh controller

add service mesh metrics

remove unused circle yaml

fix travis misconfiguration

fix travis misconfiguration

fix travis misconfiguration

vendor/github.com/docker/docker/api/README.md

@@ -1,42 +0,0 @@
-# Working on the Engine API
-
-The Engine API is an HTTP API used by the command-line client to communicate with the daemon. It can also be used by third-party software to control the daemon.
-
-It consists of various components in this repository:
-
-- `api/swagger.yaml` A Swagger definition of the API.
-- `api/types/` Types shared by both the client and server, representing various objects, options, responses, etc. Most are written manually, but some are automatically generated from the Swagger definition. See [#27919](https://github.com/docker/docker/issues/27919) for progress on this.
-- `cli/` The command-line client.
-- `client/` The Go client used by the command-line client. It can also be used by third-party Go programs.
-- `daemon/` The daemon, which serves the API.
-
-## Swagger definition
-
-The API is defined by the [Swagger](http://swagger.io/specification/) definition in `api/swagger.yaml`. This definition can be used to:
-
-1. To automatically generate documentation.
-2. To automatically generate the Go server and client. (A work-in-progress.)
-3. Provide a machine readable version of the API for introspecting what it can do, automatically generating clients for other languages, etc.
-
-## Updating the API documentation
-
-The API documentation is generated entirely from `api/swagger.yaml`. If you make updates to the API, you'll need to edit this file to represent the change in the documentation.
-
-The file is split into two main sections:
-
-- `definitions`, which defines re-usable objects used in requests and responses
-- `paths`, which defines the API endpoints (and some inline objects which don't need to be reusable)
-
-To make an edit, first look for the endpoint you want to edit under `paths`, then make the required edits. Endpoints may reference reusable objects with `$ref`, which can be found in the `definitions` section.
-
-There is hopefully enough example material in the file for you to copy a similar pattern from elsewhere in the file (e.g. adding new fields or endpoints), but for the full reference, see the [Swagger specification](https://github.com/docker/docker/issues/27919)
-
-`swagger.yaml` is validated by `hack/validate/swagger` to ensure it is a valid Swagger definition. This is useful for when you are making edits to ensure you are doing the right thing.
-
-## Viewing the API documentation
-
-When you make edits to `swagger.yaml`, you may want to check the generated API documentation to ensure it renders correctly.
-
-Run `make swagger-docs` and a preview will be running at `http://localhost`. Some of the styling may be incorrect, but you'll be able to ensure that it is generating the correct documentation.
-
-The production documentation is generated by vendoring `swagger.yaml` into [docker/docker.github.io](https://github.com/docker/docker.github.io).

vendor/github.com/docker/docker/api/swagger-gen.yaml

@@ -1,12 +0,0 @@
-
-layout:
-  models:
-    - name: definition
-      source: asset:model
-      target: "{{ joinFilePath .Target .ModelPackage }}"
-      file_name: "{{ (snakize (pascalize .Name)) }}.go"
-  operations:
-    - name: handler
-      source: asset:serverOperation
-      target: "{{ joinFilePath .Target .APIPackage .Package }}"
-      file_name: "{{ (snakize (pascalize .Name)) }}.go"

vendor/github.com/docker/docker/api/types/versions/README.md

@@ -1,14 +0,0 @@
-# Legacy API type versions
-
-This package includes types for legacy API versions. The stable version of the API types live in `api/types/*.go`.
-
-Consider moving a type here when you need to keep backwards compatibility in the API. This legacy types are organized by the latest API version they appear in. For instance, types in the `v1p19` package are valid for API versions below or equal `1.19`. Types in the `v1p20` package are valid for the API version `1.20`, since the versions below that will use the legacy types in `v1p19`.
-
-## Package name conventions
-
-The package name convention is to use `v` as a prefix for the version number and `p`(patch) as a separator. We use this nomenclature due to a few restrictions in the Go package name convention:
-
-1. We cannot use `.` because it's interpreted by the language, think of `v1.20.CallFunction`.
-2. We cannot use `_` because golint complains about it. The code is actually valid, but it looks probably more weird: `v1_20.CallFunction`.
-
-For instance, if you want to modify a type that was available in the version `1.21` of the API but it will have different fields in the version `1.22`, you want to create a new package under `api/types/versions/v1p21`.

vendor/github.com/docker/docker/client/README.md

@@ -1,35 +0,0 @@
-# Go client for the Docker Engine API
-
-The `docker` command uses this package to communicate with the daemon. It can also be used by your own Go applications to do anything the command-line interface does – running containers, pulling images, managing swarms, etc.
-
-For example, to list running containers (the equivalent of `docker ps`):
-
-```go
-package main
-
-import (
-	"context"
-	"fmt"
-
-	"github.com/docker/docker/api/types"
-	"github.com/docker/docker/client"
-)
-
-func main() {
-	cli, err := client.NewEnvClient()
-	if err != nil {
-		panic(err)
-	}
-
-	containers, err := cli.ContainerList(context.Background(), types.ContainerListOptions{})
-	if err != nil {
-		panic(err)
-	}
-
-	for _, container := range containers {
-		fmt.Printf("%s %s\n", container.ID[:10], container.Image)
-	}
-}
-```
-
-[Full documentation is available on GoDoc.](https://godoc.org/github.com/docker/docker/client)