Add framework support for evaluating a query

[jcooklin]

As a user when I ask for /acme/reactor/foo/* the framework should expand this to [’/acme/reactor/foo/in’,’/acme/reactor/foo/out’,’/acme/reactor/foo/inst’] before calling the plugin.

If the users asks for ‘/acme/reactor/*/in the framework would request [‘/acme/reactor/foo/in’,’/acme/reactor/bar/in’] from the framework.

The framework should support a query that includes a tuple. A query with a tuple would begin and end with brackets and be comma separated (e.g. [val1,val2] ). So, as a user I could request /acme/reactor/*/[‘out’,’in’] and the framework would expand this to [‘/acme/reactor/foo/in’,’/acme/reactor/foo/out’,’/acme/reactor/bar/in’,’/acme/reactor/bar/out’] before calling the plugin.

The framework should not attempt to evaluate a query if the plugin accepts a query at that location. For example, as a user if I ask for /acme/coldfusion/cgroups/*/inst the request should not be evaluated by the framework but passes it as is to the plugin which will evaluate the request at runtime likely returning many metrics.

Given metric catalog:

/acme/coldfusion/foo/out
/acme/coldfusion/cgroups/*/inst
/acme/reactor/total_inst
/acme/reactor/foo/in
/acme/reactor/foo/out
/acme/reactor/foo/inst
/acme/reactor/bar/in
/acme/reactor/bar/out
/acme/reactor/bar/inst

*Note: Regex support should should also be considered

[geauxvirtual]

If the users asks for ‘/acme/reactor/*/in the framework would request
[‘/acme/reactor/foo/in’,’/acme/reactor/bar/in’] from the framework.

How would the framework know what to request if the plugin only told the framework about one metric /acme/reactor/*/in?

I see this case as just passing /acme/reactor/*/in to the plugin and letting the plugin return all metrics that match this.

[jcooklin]

@geauxvirtual, If i understand what you are saying correctly that's what I was trying to describe when I said

The framework should not attempt to evaluate a query if the plugin accepts a query at that location. For example, as a user if I ask for /acme/coldfusion/cgroups/*/inst the request should not be evaluated by the framework but passes it as is to the plugin which will evaluate the request at runtime likely returning many metrics.

It probably wasn't obvious that /acme/coldfusion/cgroups/*/inst in my example was the namespace provided by the plugin to the catalog (through the GetMetricTypes call).

[geauxvirtual]

No, I understood that part, but it seems the two statements contradict each other.

If the users asks for ‘/acme/reactor/*/in the framework would request [‘/acme/reactor/foo/in’,’/acme/reactor/bar/in’] from the framework.

And

The framework should not attempt to evaluate a query if the plugin accepts a query at that location. For example, as a user if I ask for /acme/coldfusion/cgroups/*/inst the request should not be evaluated by the framework but passes it as is to the plugin which will evaluate the request at runtime likely returning many metrics.

[pittma]

I think understand this question.

The difference that is in the first excerpt you quoted the plugin author _did not_ provide an * in their advertised metrics, but we are allowing the query anyways. This way, on the framework, we take the * and expand it to the known metrics.

In the second excerpt, the plugin author _did_ provide an *, so the framework does not attempt the expansion, and puts the onus on the author to handle the query.

No, I understood that part, but it seems the two statements contradict each other.

[geauxvirtual]

Yep, I better understand now after talking to Joel. I did not correlate the listed metric catalog with the examples above.

[jcooklin]

Closed by #803