Proxy config is now in istio/manager

[kyessenov]

No description provided.

[wora]

Can you provide a link to the new code? Why proxy config sits in manager?

[kyessenov]

https://github.com/istio/manager/blob/master/model/proxy/alphav1/config/cfg.proto

The proxy config that was here operates at a lower level of abstraction - it deals directly with proxy mesh construction from envoy configuration schemas. It seemed it's better that we keep it internal to manager since it's tied to some platform specifics (k8s) and we don't require mixer for it to function. We need another higher-level config that uses mixer attributes and can abstract proxy and platform, and also translation from this general config to manager proxy config.

[wora]

LGTM

[kyessenov]

merge?

[wora]

Suggest you ask the original author to approve this PR as well.

[kyessenov]

@rshriram

[rshriram]

Should we delete this file altogether ? Isn't this repository supposed to contain all the API interfaces to istio (manager and mixer)?

Because the manager's external REST API for setting routes need to be documented to make it easy for people to build tools and integrate it with their internal frameworks. The cli is not the only form of interaction.

[kyessenov]

Wayne wants to make an addendum, and we have two different versions right now. So we do need something here, but not this version of the spec. See comment.

[rshriram]

Which comment ?
"
https://github.com/istio/manager/blob/master/model/proxy/alphav1/config/cfg.proto

The proxy config that was here operates at a lower level of abstraction - it deals directly with proxy mesh construction from envoy configuration schemas. It seemed it's better that we keep it internal to manager since it's tied to some platform specifics (k8s) and we don't require mixer for it to function. We need another higher-level config that uses mixer attributes and can abstract proxy and platform, and also translation from this general config to manager proxy config."

First, there is nothing in the route config specific to k8s. Second, When/where was this decision made to use the mixer style complex attribute config for routing config as well ? And who is going to write yet another config at a "higher level" and translate into current manager config ? Have you thought of the user experience, ease of developing services using these APIs, etc ?

We barely have documentation for the current APIs. And you want to embark on adding another level of indirection and config?

FYI, I spent two full months writing this config and addressing every random nit pick only to end up reverting the entire config to the v2 of my PR in the manager because existing config was too complex. And then today, you are saying "let's chuck the whole thing and make it even more complex"! All this time could have been spent on prototyping and developing the end to end system, adding the required features and getting useful feedback from alpha users.

I am sorry but this is getting out of hand. Too much time has been wasted on our end trying to get such a simple thing incorporated into the system. We need a meeting to decide on this nonsense and decide once and for all what is the exact end to end interaction from top down (not bottom up as has been done in this repository), and nail down every spec down to the T.

I am not willing to complicate the routing API any further until there is a good reason, and I run it though 5-6 end users to see how they feel about it.

cc @frankb

[rshriram]

See comments earlier.

[mandarjog]

@rshriram I don't think we have made a decision :-), so this is a good time to discuss it.
@kyessenov can you be specific about what mixer specific fields are in the config now? what did @qiwzhang request?

[kyessenov]

Let's not discuss in github comments. The message doesn't carry through. We can talk about this at the next standup or have another meeting how to align the config story.