Configurable mixer cluster names for mixer filter #358
Conversation
googlebot
added
the
cla: yes
|
fyi @elevran |
|
In general, I don't have any problems with this change. It does impact some of the assumptions hardcoded in the mixer grafana dashboard. I'm not sure what the right approach is to making that more flexible is, but I'm not sure it should block this feature (if needed). |
|
I think those dashboards won't break. We could document that if you change the default names of check/report cluster, it is the user's responsibility to update the out-of-box dashboards that Istio provides. |
| // checkCluster and reportCluster, it is possible to have one set of | ||
| // mixer servers handle check calls, while another set of mixer servers | ||
| // handle report calls. | ||
| string report_cluster = 7; |
There was a problem hiding this comment.
Please add a comment about the impact of renaming these clusters on downstream things like the dashboards.
Please replicate the comments between check_cluster and report_cluster. That is, don't assume someone reads the comment of report_cluster when they're looking at the check_cluster field.
|
This is great. I was going to add this for Mixer HA story anyway. |
Automatic merge from submit-queue. make mixer cluster name configurable Please see istio/api#358 for context. Essentially remove hardcoded "mixer_server" and allow users to override the name, in addition to allowing separate clusters for check vs reports so that it makes it easier to load balance/manage the system.
Automatic merge from submit-queue. [DO NOT MERGE] Auto PR to update dependencies of mixerclient This PR will be merged automatically once checks are successful. ```release-note none ```
The mixer cluster names is hardcoded to "mixer_server". This name is prone to collisions if user has one by the same name. Also, it is quite inconvenient to have a hardcoded cluster that one cannot control/customize.
This PR introduces configuration options for check cluster and report cluster. By default, they will continue to use the currently hardcoded "mixer_server" as the cluster names. Over time, we can expose global configs that will let users point to separate upstream clusters for mixer check and report calls (for load distribution/management/etc.).