hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Varun Saxena (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3862) Decide which contents to retrieve and send back in response in TimelineReader
Date Tue, 24 Nov 2015 13:13:11 GMT

    [ 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)

Mime
View raw message