add size labels we'll use manually for now and perhaps add in a bot at some point in the future.

Per @shashankram's recommendation here: #67 (comment)

It'd be great to improve the logging system overall.

may need to be done in SMI. will prioritize later once we have the whole smc service mesh running.

We need to find a secure way to provide the CI system for this repo with k8s credentials so we can run integration tests.

to make sure all systems are go before running install command

#217

In AGIC we introduced a few levels of tests:

1. Unit tests
2. Functional tests
3. Integration tests (not in the repo yet)

Creating this issues for us to track progress on creating Functional and Integration tests for the SMC.

Note on the AGIC tests: What is now called functional tests, runs a bunch of components together to ensure that they all mesh together as expected. This we run with go test -v $(go list ./functional_tests/... | grep -v /vendor/); echo $?. This is not quite an integration test because it does not use a k8s cluster or an actual App Gway / ARM API.

A good pointer on writing good tests is the following suite in AGIC
Here are examples of starting the Kubernetes informers.

A good starting point for this task would be to perhaps tackle the pkg/smi module, which is very similar to AGIC.

These examples use the Ginkgo test framework.

@asridharan had some great suggestions in this PR comment.

• Minor NIT, can we capitalize the beginning of each of the sentence.
• An overview section would be really helpful. Users will have to build a lot of context to actually run the demo at this point, and most would be lost without explicitly talking to us. I believe the objective is to show traffic split? Would be good to state the goals and than get into the instructions.

The current Integration Test is invoked with kubectl + creds baked into Github secrets + some bash.
The Go + Bash code needs to be moved behind some sort of a Test infrastructure, so that we don't expose k8s credentials in Github secrets. Github should be making API calls to the test infrastructure to request for a certain commit to be tested. Logs and results will be streamed back.

outlines lgtm policy, commit messages, and general working agreement between maintainers discussed in person

Currently, we're passing the kube config file to generate a kubernetes client within each xDS component that it can communicate with the Kubernetes api server. There are ways of generating a client without passing in a kube config file. We'll need to mount a service account to each xDS pod so that it can authenticate inside the cluster like shown here.

We'll want to update https://github.com/deislabs/smc/blob/4e2a8c40c37b5053a75030fd12d19ba7b0fb91fe/GNUmakefile#L55-L79

$ osm mesh health MESH_NAME

This could be implemented with helm test.

depends on #41

When service mesh is rolled out to a brownfield a service may need to be mTLS-optional.
If two existing services A-B are enabled for mTLS, there will be before and after mTLS is enabled. Not all pods will be mTLS ready at the same time. This will result in some old pods connecting to new mTLS pods and most likely 503 errors.
To prevent that we need mTLS-optional for a period of time, where if mTLS does not work we switch to non-mTLS.

What about traffic split, where one group is mTLS the other is not?

The options so far are (and they need to be fleshed out a bit more)

• web service that we expose
• smc cli command (see #84)
• rely on kubectl (link to AzureResource CRD) -- @draychev if you wouldn't mind filling in this workflow
• integrate with azure Key Vault

GitHub release, public container registry, update docs

As outlined in this discussion: #5 (comment)
and here: #7 (review)

Service mesh should provide certs and user should put certs on VM themselves

so that there are not separate bins running xDS components in cluster with repeated code

github.com/deislabs/smi-metrics

Some of us have observed that traffic target does not work as expected.

Here, only "/counter" is allowed based on the TrafficTarget spec but the demo is allowing
"/incrementcounter" as well.

---[ 29 ]-----------------------------------------
Fetching http://bookstore.mesh/counter
Identity: bookstore-1--25412f8
Counter: 12
Server: envoy
Date: Tue, 03 Mar 2020 17:53:24 GMT
Status: 200 OK

Fetching http://bookstore.mesh/incrementcounter
Identity: bookstore-1--25412f8
Counter: 13
Server: envoy
Date: Tue, 03 Mar 2020 17:53:24 GMT
Status: 200 OK

kind: TrafficTarget
apiVersion: access.smi-spec.io/v1alpha1
metadata:
name: bookstore-service
namespace: "$K8S_NAMESPACE"
destination:

(todo): use service account

kind: ServiceAccount
name: bookstore-1-serviceaccount
namespace: "$K8S_NAMESPACE"
specs:

• kind: HTTPRouteGroup
  name: bookstore-service-routes
  matches:
  • counter
    sources:

(todo): use service account

• kind: ServiceAccount
  name: bookbuyer-serviceaccount
  namespace: "$K8S_NAMESPACE"

stream metrics configuration messages to envoy proxies. need to still flesh out this story. making sure not to DDoS / throttle / buffer.

We need someone to think more about this and can split this into more issues

require at least 1 review/lgtm
larger PRs must have two reviews but that is at the discretion of the author of the PR for now.

open service mesh is the only suggestion as of now. Does anyone else have any suggestions?

Demo outline

• install control plane on k8s via osm install
• install demo application v1 using kubectl apply -f
• Follow SMI workflow for TrafficSplit using demo outlined here

Document steps in cmd/smc/README.md for now

After running ./demo/run-demo.sh, this is what I'm getting:

$ k logs bookstore-7c7c8f78c4-mh7r7 -n smc envoyproxy
[2020-02-27 22:37:08.327][1][debug][http] [source/common/http/async_client_impl.cc:96] async http request response headers (end_stream=true):
':status', '200'
'content-type', 'application/grpc'
'grpc-status', '14'
'grpc-message', 'upstream connect error or disconnect/reset before headers. reset reason: connection termination'

[2020-02-27 22:37:08.327][1][warning][config] [bazel-out/k8-opt/bin/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:92] StreamAggregatedResources gRPC config stream closed: 14, upstream connect error or disconnect/reset before headers. reset reason: connection termination
[2020-02-27 22:37:08.327][1][debug][config] [source/common/config/grpc_subscription_impl.cc:85] gRPC update for type.googleapis.com/envoy.api.v2.Listener failed
[2020-02-27 22:37:08.327][1][debug][config] [source/common/config/grpc_subscription_impl.cc:85] gRPC update for type.googleapis.com/envoy.api.v2.Cluster failed
[2020-02-27 22:37:08.327][1][debug][pool] [source/common/http/conn_pool_base.cc:265] [C12] client disconnected, failure reason: TLS error: 268436498:SSL routines:OPENSSL_internal:SSLV3_ALERT_BAD_CERTIFICATE

From the bookbuyer:

---[ 159 ]-----------------------------------------
Fetching http://bookstore.mesh/counter
Error fetching http://bookstore.mesh/counter: Get http://bookstore.mesh/counter: dial tcp 127.0.0.1:80: connect: connection refused

Fetching http://bookstore.mesh/incrementcounter
Error fetching http://bookstore.mesh/incrementcounter: Get http://bookstore.mesh/incrementcounter: dial tcp 127.0.0.1:80: connect: connection refused

Currently a single 'announcement' channel is used across the code to announce topology changes to envoy proxies. Since a Go channel is between 2 endpoints only, it is not possible to announce changes from informers to multiple proxies as is.
Introduce a message broker to distribute announcements from informers to subscribed proxies.

update azure pipelines file with the test scripts

How to integrate service mesh with external traffic if everything is mTLS enabled

right now we're sending all the info on all the services to all the envoys.

one possible way to do it: trigger with SMI TrafficSplit deployment

something is wrong when we issue root cert with CA

to debug:
generate with openssl and our tool and compare