-
Notifications
You must be signed in to change notification settings - Fork 573
separate check and report clusters #362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -117,15 +117,25 @@ message ProxyConfig { | |||
// MeshConfig defines mesh-wide variables shared by all Envoy instances in the | |||
// Istio service mesh. | |||
message MeshConfig { | |||
// Address of the egress Envoy service (e.g. _istio-egress:80_). | |||
string egress_proxy_address = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is egress_proxy_address
being removed as part of the mixer_address
separation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah shux.. It was an unused config item.. We got rid of egress proxy a long time ago. Thought I would remove it as well.
mesh/v1alpha1/config.proto
Outdated
// reported to the mixer for HTTP requests and TCP connections. Default | ||
// Address of the server that will be used by the proxies for policy | ||
// check calls (e.g. _istio-mixer:15004_). By using different names for | ||
// policyCheckServer and telemetryServer, it is possible to have one set |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use mixer_check_server
and mixer_report_server
for consistency with the mixer API service?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a good point. What I am trying to do here is to keep the config at concept level (policies, telemetry, auth, etc.). There are other parts of the config that are essentially pointing to implementation specific things, which to a layman is going to be hard to understand. If I am starting off with Istio, I look at global config and turn off things I don't want/enable things I want. Make sense?
(I am waiting to get rid of those RDSrefresh delays, etc. but haven't found a good way to do it yet).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Somewhat. We seem to be conflating mesh administrator configuration and operator policy config into the same protobuf which makes this difficult. Configuring whether a feature (e.g. auth, telemetry) is enabled globally (or per namespace / service) is a different concept than how the services that enable those features are accessed by the proxies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
Lets not merge this until all tests pass in istio/istio for my PR. Dont want to upset stuff.. |
* separate check and report clusters * fix * nits * nit * backward compat
Pursuant to PR #358 ..
TODO: Once this is implemented in Pilot such that policy_check_cluster and telemetry_cluster are always specified, we need to