Sidecar or Monitor? I chose Sidecar #1
Conversation
Sidecar is used in the specification (in one place, but not another). I like the sidecar approach because it is general enough to handle almost everything, and monitoring isn't the only function that might need to be implemented. The downside is that it can be abused, but that won't be the specification's fault.
|
cc @gabrtv thoughts? |
|
I don't feel strongly but I lean Sidecar. Sidecar is less purist from a resource modeling perspective, but it'll allow us to evolve more sidecar management capabilities as @craiglpeters suggests. |
|
FWIW, I like the sidecar approach when you own everything, so that you can manage sidecars with transparency. With multiple sidecars potentially used in same environment, I like Gabe's words: |
|
Sidecar is very generic mechanism to implement many abilities, including mTLS and Monitor. If we go with sidecar, then we are losing the context in which the API spec specifies the purpose of this side car. It might be better to specify the ability we want in API as opposed to how it should be implemented. |
|
Closing this PR, we've moved to TrafficMetrics over Sidecar/Monitor. |
Sidecar is used in the specification (in one place, but not another). I like the sidecar approach because it is general enough to handle almost everything, and monitoring isn't the only function that might need to be implemented. The downside is that it can be abused, but that won't be the specification's fault.