Need generic env attribute generation adapter

[douglas-reid]

cc @andraxylia @ldemailly @mandarjog @guptasu

In testing VM TCP scenarios, it became obvious that Mixer's kubernetes adapter was insufficient for handling attribute generation for services running outside of a kubernetes cluster. There are a number of potential solutions, including making the kubernetes adapter more robust (add Endpoints / Services cache).

However, there is probably a need for a more simple, easy to configure adapter that can take a uid for a workload and generate values from handler configuration, without outside lookups. This adapter should be straightforward to add once the work on porting APAs over to the improved adapter model is complete.

Possible config story:

apiVersion: "config.istio.io/v1alpha2"
kind: attributegen
metadata:
  name: handler
  namespace: istio-system
spec:
  workloads:
  - uid: "vm://mysqldb.local"
    outputs:
      service: "mysqldb.default.svc.cluster.local"
      name: "mysqldb"
      labels:
        version: "v2"
        app: "mysqldb"        

[kyessenov]

The long term solution is to deprecate kubernetes APA and let pilot enter the environment-specific attributes. This is blocked on two things:

1. inability to forward attributes through TCP
2. inability to pass-on attributes to mixerfilter that are not pure strings.

[douglas-reid]

That long-term solution may or may not preclude the need for simple Mixer adapter that can produce operator-specified attributes from inputs (without reliance on external components). For instance, what if someone wants to use Mixer w/o Pilot?

[ldemailly]

I think annotations would be good, maybe instead of going directly to k8s mixer should get service state updates from pilot

[kyessenov]

Using Mixer w/o Pilot requires some sort of environmental binding to understand deployment topology, which is basically half of Pilot.

[douglas-reid]

@kyessenov That's not entirely true. Think about scenarios where services want to directly call into Mixer, for checks or reports. This isn't just a proxy->mixer scenario. Mixer should be usable even without the other bits of Istio, ideally.

In any case, I think there are several use cases for having a generic template for attribute derivation from a static config file (whether or not that is generated by Pilot or crafted by hand, etc.).

[andraxylia]

What is the order of precedence if both pilot provides it, and mixer derives it?

[douglas-reid]

@andraxylia right now, Mixer wins. that was not the intention. I'm currently working on a PR to change that to be received attributes take precedence over those produced by adapters.

[andraxylia]

@douglas-reid this sounds good, thanks! Please link it here when you have it, for reference.