[
https://issues.apache.org/jira/browse/YARN-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024477#comment-15024477
]
Varun Saxena commented on YARN-3862:
------------------------------------
bq. Whether we make TimelineFilter part of the object model or not, we'll still
need to come up with a way to support filter queries on the URLs, no?
Decision about making it part of an object model was to primarily decide on how
much control we want to give the client.
Moreover, the thought behind making it as part of object model is that the
client will create an object of type TimelineFilterList and this will converted
into a JSON string and sent in the query param. Something like below where
metricFilters is a query param. This can become quite complex as a filterlist
can have another filterlist in it but at the server side it will be easy to
parse as JSON converter will do it for us. This though can make the URL quite
big.
{{&metricFilters=\{"operator": "AND", "filters": \[\{"type":
"COMPARE","key":"metric1", "value": "12345", "compareop":
"GREATER_THAN\},\{"type": "COMPARE","key":"metric23", "value": "12",
"compareop": "EQUALS\}\]\}}}
Or we can alternatively define some other way to represent this. Say something
like below for instance. Here, we will have to do the parsing ourselves. We can
go with acronyms like gt for greater than, eq for equals, ge for greater than
equals and so on. As you can see below, it is exactly same query as above but
as its not JSON representation, it will be a lot shorter.
{{&metricFilters=(metric1 gt 12345) AND (metric23 eq 12)}}
This is what I meant by that we have to decide whether to keep it as part of
object model or not.
bq. I just wanted to understand whether we need to make that call as part of
this JIRA. Did I understand this correctly, or did I miss something important?
Current code is not hooked up to the REST layer, so it wont work end to end.
However, the current patch has already become quite big. So we can handle REST
related changes in another JIRA. I am fine with that.
> Decide which contents to retrieve and send back in response in TimelineReader
> -----------------------------------------------------------------------------
>
> Key: YARN-3862
> URL: https://issues.apache.org/jira/browse/YARN-3862
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Affects Versions: YARN-2928
> Reporter: Varun Saxena
> Assignee: Varun Saxena
> Labels: yarn-2928-1st-milestone
> Attachments: YARN-3862-YARN-2928.wip.01.patch,
> YARN-3862-YARN-2928.wip.02.patch, YARN-3862-YARN-2928.wip.03.patch,
> YARN-3862-feature-YARN-2928.wip.03.patch
>
>
> Currently, we will retrieve all the contents of the field if that field is
> specified in the query API. In case of configs and metrics, this can become a
> lot of data even though the user doesn't need it. So we need to provide a way
> to query only a set of configs or metrics.
> As a comma spearated list of configs/metrics to be returned will be quite
> cumbersome to specify, we have to support either of the following options :
> # Prefix match
> # Regex
> # Group the configs/metrics and query that group.
> We also need a facility to specify a metric time window to return metrics in
> a that window. This may be useful in plotting graphs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
