Local Mixer setup - rules are ignored


#1

Hi everyone,

I went through this guide on developing an out-of-process adapter for Mixer (https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Walkthrough). After spending a couple of days I got to the end, but one final issue is that while mixs server does pick up my adapter, handler, and instance from configuration, it doesn’t pick up the rule. Therefore, my adapter is not actually being called.

Here’s my configuration:

# handler for adapter applicationinsightsadapter
apiVersion: "config.istio.io/v1alpha2"
kind: handler
metadata:
 name: h1
 namespace: istio-system
spec:
 adapter: applicationinsightsadapter
 connection:
   address: "[::]:33393" #replaces at runtime by the test
 params:
   file_path: "out.txt"
---
# instance for template metric
apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
 name: i1
 namespace: istio-system
spec:
 template: metric
 params:
   value: request.size | 123
   dimensions:
     response_code: "200"
---
# rule to dispatch to handler h1
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
 name: r1
 namespace: istio-system
spec:
 actions:
 - handler: h1
   instances:
   - i1
---

Here’s the debug output from Mixer (the part that appears relevant):

2019-02-08T00:27:17.735735Z     debug   Processing incoming handler config: name='h1.handler.istio-system'
&Handler{Name:,Adapter:applicationinsightsadapter,Params:&google_protobuf1.Struct{Fields:map[string]*Value{file_path: &Value{Kind:&Value_StringValue{StringValue:out.txt,},XXX_unrecognized:[],},},XXX_unrecognized:[],},Connection:&Connection{Address:[::]:33393,Timeout:<nil>,Authentication:nil,},CompiledAdapter:,}
2019-02-08T00:27:17.737227Z     debug   Begin processing rule configurations.
2019-02-08T00:27:17.737484Z     info    Built new config.Snapshot: id='4'
2019-02-08T00:27:17.737803Z     debug   config.Snapshot creation error=<nil>, contents:
ID: 4
TemplatesStatic:
  Name: apikey
  Name: authorization
  Name: checknothing
  Name: edge
  Name: kubernetes
  Name: listentry
  Name: logentry
  Name: metric
  Name: quota
  Name: reportnothing
  Name: servicecontrolreport
  Name: tracespan
AdaptersStatic:
  Name: bypass
  Name: circonus
  Name: cloudwatch
  Name: denier
  Name: dogstatsd
  Name: fluentd
  Name: kubernetesenv
  Name: listchecker
  Name: memquota
  Name: noop
  Name: opa
  Name: prometheus
  Name: rbac
  Name: redisquota
  Name: servicecontrol
  Name: signalfx
  Name: solarwinds
  Name: stackdriver
  Name: statsd
  Name: stdio
  Name: zipkin
HandlersStatic:
InstancesStatic:
Rules:
AdaptersDynamic:
  Name:      applicationinsightsadapter.adapter.istio-system
  Templates:
  -  metric.template.istio-system

TemplatesDynamic:
  Resource Name:  metric.template.istio-system
    Name:  metric.template.istio-system
    InternalPackageDerivedName:  metric
HandlersDynamic:
  Name:    h1.handler.istio-system
  Adapter: applicationinsightsadapter.adapter.istio-system

As you can see, adapter, handler, and template are there, but the rules section is empty.

I’ve experimented with moving the rule around in the yaml configuration, and it appears that if I put the rule in front of everything else I do get an error “handler not found” (which makes sense), but as long as the rule remains at the end of the file - I can put any non-existent values in its fields, and there’s not even an error.

Is there a trick I should be aware of?

Thank you.


#2

Order in yaml file should not matter. Mixer consumes config in a eventual consistent manner. The error could occur momentarily when rule config gets processed while handler config not yet arrives. I am wondering after moving the rule to the top, does everything eventually start to work or you still cannot see anything in your adapter?


#3

Judging by stdout output alone, Mixer ingests configuration as soon as I hit Save on the file (I guess it watched the directory), and then doesn’t re-ingest it until I hit Save again. Not sure how that eventual consistency works, but no, no matter what I do, I could never get my out of process adapter called, or see any evidence in Mixer logs that it even tried.


#4

If I move the rule definition to the top of the file, here’s what I get.

2019-02-08T19:42:22.877145Z     debug   Begin processing rule configurations.
2019-02-08T19:42:22.877661Z     debug   Processing incoming rule: name='r1.rule.istio-system'
&Rule{Match:,Actions:[&Action{Handler:h1,Instances:[i1],Name:,}],RequestHeaderOperations:[],ResponseHeaderOperations:[],Sampling:nil,}
2019-02-08T19:42:22.878194Z     debug   Processing action: r1.rule.istio-system[0]
2019-02-08T19:42:22.878483Z     error   Handler not found: handler='h1'
2019-02-08T19:42:22.878790Z     error   No valid actions found in rule
2019-02-08T19:42:22.879251Z     info    Built new config.Snapshot: id='4'
2019-02-08T19:42:22.879613Z     debug   config.Snapshot creation error=2 errors occurred:

* action='r1.rule.istio-system[0]': Handler not found: handler='h1'
* rule=r1.rule.istio-system: No valid actions found in rule, contents:
ID: 4

It fails, but at least there’s evidence that it’s looking at it. I’m not seeing any output from Mixer after that unless I change the configuration again.


#5

Turns out if I separate all three definitions into 3 separate files - it works. When it’s all in one file it looks like only the first definition is being looked at. I tried messing with YAML’s — and …, but couldn’t fix it, so I guess leaving it all separate by now. Not sure if this is a YAML thing (I’m new to YAML), or Mixer thing. I’m very curious about how a single YAML containing multiple resources should look like in order for it to work.


#6

I don’t see anything wrong with your multi-resource YAML. Perhaps, you have some duplicate rule that is shadowing the rule? Peter is correct in that the order should not matter.


#7

The only thing weird that I can think of is that I’m working in Linux subsystem for Windows, so I’m editing the YAML file under Windows while everything else is happening under Ubuntu. Maybe there’s an issue with line endings or something, but I’m unable to find a problem.