Add ability to generate headers from templates via routing rules

[Adiqq]

Hi,

Opening new issue according to suggestion from @rshriram , istio/istio#4971 .

Edit:
This issue is not about automatic header propagation through inference. This issue is about generating headers based on templates, nginx style
e.g.,
set-header proxy-pass $proxy_ip
this should cause the proxy to generate a header called proxy-pass whose value is the IP address of the proxy. Several proxies support this kind of feature except Envoy [or may be it does it by now in a limited way].

[rshriram]

cc @frankbu (if you have time to help)

[geeknoid]

Note that we're also planning to support this kind of functionality through Mixer policies.

[ijsnellf]

@geeknoid: is the mixer work being tracked somewhere?

[kyessenov]

@ijsnellf I'm driving the effort. All the bits are in place, but not connected end-to-end. Mixer rules will allow using expressions for header values, which can depend on request attributes or any other input from the adapters.

[linsun]

subscribe

Curious why we want to do this via mixer rule.... This is not just for telemetry. I'd think I want to do header based routing without mixer even installed.

[geeknoid]

We want Mixer adapters to be able to influence routing decisions. This makes it possible for Mixer to reach out to a database which supplies the routing info for a specific customer (which happens in API management scenarios, among others)

…

On Fri, Oct 5, 2018 at 12:48 PM Lin Sun ***@***.***> wrote: subscribe Curious why we want to do this via mixer rule.... This is not just for telemetry. I'd think I want to do header based routing without mixer even installed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#454 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVucHU3YQ1FrrChvqQxaX6lKqnBrUxfRks5uh7d7gaJpZM4TXrqN> .

[kyessenov]

@linsun We don't want to do this just with mixer rules. For simple things, route rules work fine. You need Mixer for any external adapters trying to influence request metadata. Anything that involves an external database would need dynamic rules.

[linsun]

@kyessenov @geeknoid ok great. So if I hear you correctly, this will enable users to propagate headers (such as user-agent) automatically among microservices without the need to modify their code. Further, you could do this in the minimal istio install without mixer (https://istio.io/docs/setup/kubernetes/minimal-install/) for route rules... when you bring in mixer, there is added capability such as make decisions/modify based on request metadata.

Is there a design for this? I would like to follow up this closely. Curious how you propagate the headers for the user without mixer for incoming req and outgoing req.

cc @frankbu

[kyessenov]

@linsun Let me clarify. Mixer-driven header operations are not meant for automatic header propagation. It's meant for building higher-level workflows with adapters and istio config. For example, a mixer authorization adapter may insert user-info header that also affects how envoys route traffic (by redirecting requests without user-info to a login page). The design has been in discussion for many months, see https://docs.google.com/document/d/1-coh6cK4Tk0_Yw1Vv1JxBUs2aP5miaqo4zCPSFgLiaA/edit#heading=h.qex63c29z2to, for example. I will provide more documentation likely next week.

[linsun]

@kyessenov thank you for clarifying that!