Issues with mixer configuratation

[istio]

Issues with mixer configuratation

[ZackButcher]

I filed istio/old_mixer_repo#796 but at second look that may be a red herring. I think we may have a bug using adapter produced attributes in selector clauses; I'll need to do some testing to confirm.

Mixer has two mechanism for injecting attributes into a request's context: we get a bag of attributes from Envoy, and attributes type adapters can produce more attributes in Mixer at runtime. source.labels happens to be one of the attributes produced in Mixer by an adapter (in a default deployment, the kubernetes adapter produces the source.labels attribute; you determine this by looking at the manifest). We know that using adapter-produced attributes is fine in general (by default Mixer ships with metrics that use source.labels as a dimension), but I'm not confident we've tested using them in selection clauses. I'll do some manual testing and update this issue.

[ZackButcher]

@douglas-reid FYI

[ZackButcher]

To provide a bit more context, the specific error you're getting is returned in two cases:

1. When an attribute is used in an expression (selector clauses are expressions) but is not present in a manifest. This is akin to using a variable name that hasn't been declared, is caught by our static validation when a new config is pushed to Mixer.
2. When an attribute is declared in a manifest but doesn't actually have a value at runtime. This can occur per request.

I suspect that due to the special nature of the source.labels attribute (that it's produced by Mixer at runtime, not by Envoy when it calls Mixer), we're incorrectly falling in to case 2 even though we actually do have values for source.labels in hand.

[mandarjog]

If an attribute is missing from manifest, you get a config validation error.

This error occurs on the request path which is 2.

[mandarjog]

hey @christopherL91, thanks for reporting this.

How did you apply the rule?
You should apply it with scope=global and subject=fqdn of the service

if you applied to global / global then it overwrote all the global rules with your rule.
One of those rules produce kubernetes label attributes. It could explain what you are seeing.

If it is not that, can you provide us with logs and full configuration from Mixer?
Thanks.

[ldemailly]

closing this for now assuming mandar's comment resolved the issue, if not please reopen