{"action":"created","issue":{"url":"https://api.github.com/repos/istio/api/issues/344","repository_url":"https://api.github.com/repos/istio/api","labels_url":"https://api.github.com/repos/istio/api/issues/344/labels{/name}","comments_url":"https://api.github.com/repos/istio/api/issues/344/comments","events_url":"https://api.github.com/repos/istio/api/issues/344/events","html_url":"https://github.com/istio/api/issues/344","id":293715272,"number":344,"title":"Proposal for refactoring mixerclient configuration","user":{"login":"ayj","id":116378,"avatar_url":"https://avatars1.githubusercontent.com/u/116378?v=4","gravatar_id":"","url":"https://api.github.com/users/ayj","html_url":"https://github.com/ayj","followers_url":"https://api.github.com/users/ayj/followers","following_url":"https://api.github.com/users/ayj/following{/other_user}","gists_url":"https://api.github.com/users/ayj/gists{/gist_id}","starred_url":"https://api.github.com/users/ayj/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ayj/subscriptions","organizations_url":"https://api.github.com/users/ayj/orgs","repos_url":"https://api.github.com/users/ayj/repos","events_url":"https://api.github.com/users/ayj/events{/privacy}","received_events_url":"https://api.github.com/users/ayj/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-02-01T23:02:02Z","updated_at":"2018-02-02T00:02:43Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"The current mixerclient protos conflates user intent with implementation specific filter config. We ought to decouple them. User facing config is dimensioned by feature (auth, quota, api-spec) and should be organized according to the [proposed proto package scheme](https://docs.google.com/document/d/1C_NMYj9ZhdUWwZMWUoX_SLU8VoiV8U8V6yUJVYcdSS8/edit#heading=h.qex63c29z2to). Filter config is dimensioned by service (i.e. envoy route).\r\n\r\nThis will allow better independent evolution of the user-facing APIs from filter/proxy specific implementations, e.g. mixerclient, upstream envoy ([auth](https://github.com/envoyproxy/data-plane-api/blob/master/envoy/api/v2/auth/auth.proto), [ratelimit](https://github.com/envoyproxy/data-plane-api/blob/master/envoy/api/v2/ratelimit/ratelimit.proto)).\r\n\r\nWe should also refactor the mixerclient filter configuration to be defined per route (via RDS) instead of per listener (via LDS). This is both more performant, as service config can then be delivered via RDS instead of the more costly LDS, which requires draining listeners, and more consistent with upstream Envoy filters, e.g. [here](https://github.com/envoyproxy/data-plane-api/blob/a07a36853e698d5fee7b011d7abd1dcb87eda45e/envoy/api/v2/route/route.proto#L98).\r\n\r\n- [ ] Introduce a new user-facing AuthenticationPolicy. @diemtvu already started this work (see https://github.com/istio/api/pull/335). Pilot consumes AuthenticationPolicy and produce the corresponding mtls/auth filter configuration for envoy/mixerclient.\r\n\r\n- [ ] Introduce a new user-facing API proto. OpenAPI (v2/v3), gRPC, and generic REST schemes should be considered. Options include a single umbrella type with subtypes per scheme or first-class types for each of the scheme. Pilot consumes these API spec(s) and produces the corresponding normalized [HTTPAPISpec](https://github.com/istio/api/blob/master/mixer/v1/config/client/api_spec.proto) for mixerclient filter.\r\n\r\n- [ ] Introduce a new user-facing Quota proto. Schema is TBD. Config WG probably has useful input on what this should look like. Pilot consums this new proto and produce corresponding [QuotaSpec](https://github.com/istio/api/blob/master/mixer/v1/config/client/quota.proto) for mixerclient filter.\r\n\r\n- [ ] Binding/Scoping API is only needed for user facing APIs. [QuotaSpecBinding](https://github.com/istio/api/blob/a31ac6dbd68579a553367ebb20b1c2b4551404bf/mixer/v1/config/client/quota.proto#L122), [HTTPAPISpecBinding](https://github.com/istio/api/blob/a31ac6dbd68579a553367ebb20b1c2b4551404bf/mixer/v1/config/client/api_spec.proto#L217), and [EndUserAuthenticationPolicySpecBinding](https://github.com/istio/api/blob/a31ac6dbd68579a553367ebb20b1c2b4551404bf/mixer/v1/config/client/auth.proto#L165) should be removed. Equivalent bindings should be created for the user-facing auth, quota, and api-spec definitions. It would be great if there were some consistency with [RouteRule](https://github.com/istio/api/blob/a31ac6dbd68579a553367ebb20b1c2b4551404bf/routing/v1alpha2/route_rule.proto#L119)'s concepts/terminology when possible. For example, it seems reasonable to bind an API spec to service name (i.e. host) and/or entry point to the mesh (i.e. ingress/gateway).\r\n\r\n- [ ] Refactor [mixer/v1/config/client/client_config.proto](https://github.com/istio/api/blob/master/mixer/v1/config/client/client_config.proto) so that per-service configuration can be provided via RDS. \r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/istio/api/issues/comments/362442686","html_url":"https://github.com/istio/api/issues/344#issuecomment-362442686","issue_url":"https://api.github.com/repos/istio/api/issues/344","id":362442686,"user":{"login":"mandarjog","id":800375,"avatar_url":"https://avatars2.githubusercontent.com/u/800375?v=4","gravatar_id":"","url":"https://api.github.com/users/mandarjog","html_url":"https://github.com/mandarjog","followers_url":"https://api.github.com/users/mandarjog/followers","following_url":"https://api.github.com/users/mandarjog/following{/other_user}","gists_url":"https://api.github.com/users/mandarjog/gists{/gist_id}","starred_url":"https://api.github.com/users/mandarjog/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mandarjog/subscriptions","organizations_url":"https://api.github.com/users/mandarjog/orgs","repos_url":"https://api.github.com/users/mandarjog/repos","events_url":"https://api.github.com/users/mandarjog/events{/privacy}","received_events_url":"https://api.github.com/users/mandarjog/received_events","type":"User","site_admin":false},"created_at":"2018-02-02T00:02:43Z","updated_at":"2018-02-02T00:02:43Z","author_association":"CONTRIBUTOR","body":"One issue right now, is that filter config is unnecessarily being populated in unrelated listeners, so I am actually fixing that too. "}}
{"actor":{"display_login":"mandarjog"}}