istio-ecosystem / emcee Goto Github PK

If I apply a MeshFedConfig and Secret together it works, but the log looks scary.

To reproduce, kubectl --context $CLUSTER1 apply -f samples/limited-trust/limited-trust-c1.yaml,samples/limited-trust/secret-c1.yaml

The log shows

2019-12-18T13:48:30.119-0500	ERROR	controller-runtime.controller	Reconciler error	{"controller": "meshfedconfig", "request": "limited-trust/limited-trust", "error": "No secrets match map[mesh:limited-trust secret:cluster1]"}
github.com/go-logr/zapr.(*zapLogger).Error
	/Users/snible/go/pkg/mod/github.com/go-logr/[email protected]/zapr.go:128
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
	/Users/snible/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:218
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	/Users/snible/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:192
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).worker
	/Users/snible/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:171
k8s.io/apimachinery/pkg/util/wait.JitterUntil.func1
	/Users/snible/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:152
k8s.io/apimachinery/pkg/util/wait.JitterUntil
	/Users/snible/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:153
k8s.io/apimachinery/pkg/util/wait.Until
	/Users/snible/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:88
2019-12-18T13:48:31.683-0500	DEBUG	controller-runtime.controller	Successfully Reconciled	{"controller": "meshfedconfig", "request": "limited-trust/limited-trust"}

For example, if

KUBECONFIG=/Users/mb/Sandbox/mb1_admin.conf:/Users/mb/.bluemix/plugins/container-service/clusters/istio-test-paid/kube-config-dal13-istio-test-paid.yml:/Users/mb/.bluemix/plugins/container-service/clusters/test-multizone/kube-config-dal10-test-multizone.yml:/Users/mb/.bluemix/plugins/container-service/clusters/free1/kube-config-hou02-free1.yml:/Users/mb/.bluemix/plugins/container-service/clusters/istio-test-paid2/kube-config-dal13-istio-test-paid2.yml:/Users/mb/.bluemix/plugins/container-service/clusters/istio-test-paid3/kube-config-dal13-istio-test-paid3.yml

It is too difficult to test and interactively make changes without one.

Rules: Mode must be valid (currently BOUNDARY or PASSTHROUGH)
No Ingress Port for PASSTHROUGH
No selector (or istio:ingressgateway selector) for PASSTHROUGH

Fixed for passthrough binding pushed ... still working on boundary protection alias.

Current situation:

After running test/integration/bp.sh I can delete samples/limited-trust/helloworld-binding.yaml and apply alias-binding-helloworld-as-holaworld.yaml. I expect to be able to perform kubectl --context $CLUSTER1 exec -it cli1 -- curl --silent holaworld:5000/hello -v but it fails with a 503. I have tried manually tinkering with the mc2019 created Istio config but have not yet had success.

The issue is incorrect VS on the expose side.
In particular the match/sniHosts should refer to the alias not the sac name.

clean up the integration test scripts; preferably unify as much as possible

Currently, we have a single controller per cluster. We may want to have a single cluster per federation or something in between. This will allow that flexibility with the aim of reducing the cost of operations wrt maintenance and upgrade.

Each entry for an exposed service should include the zone/region information such that the "locality" for the SE being created on the binding side can be set appropriately.

I start up the controller like this:

kubectl config use-context $CTX_CLUSTER2
KUBECONFIG=~/.kube/config ISTIO_PROXY_IMAGE=docker.io/istio/proxyv2:1.4.0 make run

I am using the latest IBM ibmcloud, which likes to add a context to an existing file rather than creating a file per cluster.

I have found it error-prone.

Please make the controller take an argument for the context.

Add a script or example of how to start two controllers, one with each context.

Right now, each discovery message contains all exposed services. For scalability, we need to support incremental updates as well.

Terminate the connection if the svc for discovery is deleted/changed.

Currently, we use a hack and use "9.9.9.9" to mean localhost and in the controller we use localhost instead. The reason being the endpoint address for a service cannot be set to the localhost. We need a better solution.

config/rbac/role.yaml needs more permissions.

I am working on a list of what it needs. For sure it needs to be able to create serviceentries cluster-wide and update services cluster-wide.

It should probably be renamed to emcee-role (the ClusterRole, not the .yaml file).

It is unclear if I should be writing the ClusterRole by hand or using KubeBuilder "markers" (e.g. +kubebuilder:rbac ...) in the code and running something to regenerate.