- upgrade helm to 2.14, and install the [helm-tiller](https://github.com/rimusz/helm-tiller) plugin to run in "tillerless" mode - with a local tiller instance
- also add support to create RBAC resources in the loadtester chart, because when running in tillerless mode, the pod service account will be used instead of the tiller one - so we need to give him specific permissions
this allow the use of the loadtester to run `helm test` in tillerless mode, with `helm tiller run -- helm test` for example
Copy this file https://github.com/grpc/grpc-proto/blob/master/grpc/health/v1/health.proto into the ghz folder for use when promoting a canary running a grpc service.
This repo describes the file:
> This repository contains common protocol definitions for peripheral services around gRPC such as health checking, load balancing etc..
Any app that chooses to implement this interface (which imo should be any grpc service exposing a health check) will then be able to use this without providing reflection.
I'm not a grpc expert so I'm not sure what the best practices are around allowing reflection on the server but this seems like a simple solution for those who choose not to enable it.
Slack discussion on the weave users slack is here - https://weave-community.slack.com/archives/CGLQLLH9Q/p1566358441123400
You can utilize this file like so
`/ghz --proto=/tmp/health.proto --call=grpc.health.v1.Health/Check ...`
This commit fixes two things:
- it ensures the code generation works no matter the location of the
project directory
- as a side effect; fixes the `hack/verify-codegen.sh` ran during CI
The previous script (or more specific: the `code-generator` library)
made the assumption during execution that the project was placed
inside `$GOPATH/src` and made the modifications there.
The idea of Go Modules is however that a project and/or package can
be placed anywhere, and this is also what the CI did, resulting in a
comparison of two identical `cp -r` copied directories. Giving a
false green light on every CI run.
To work around this limitation in `code-generator`: create a
temporary directory, use this as an output base and copy
everything back once generated.
This fixes issue https://github.com/weaveworks/flagger/issues/263
We actually don't need to specify any ports in the VirtualService
and DestinationRules.
Istio will create clusters/listerners for each named port we have declared in
the kubernetes services and the router can be shared as it operates only on L7 criterias
Also contains a tiny clean-up of imports
