Varun Saxena commented on YARN-3862:

bq. As for the timeline filters, strictly speaking these are filters that 
filter based on the column qualifiers, and not on the values, right? 
In this JIRA filters based on column qualifiers will be handled. In YARN-3863, 
based on values.

bq. I chatted with Joep on this, and I personally feel that it would be useful 
to maintain separation between limiting the contents that are returned (akin to 
contents of SELECT in SQL) and limiting the rows that are selected (akin to the 
WHERE clause in SQL).
Currently TimelineFilterList will accept any subclass of TimelineFilter. There 
is no strict segregation with regards to column based filters and value based 
The idea was that as we will be creating the filters inside ATS code, it will 
be taken care that no mix and match will be there.
But if we add filters as part of our object model, I think we can clearly 
segregate it. 
We can have 2 separate interfaces or abstract classes(sort of facades) 
extending the TimelineFilter interface which do nothing. And the column based 
filters can extend one and value based filters other.
In TimelineFilterList, there can be 2 addFilter interfaces for these 2 classes. 
This way a list will contain only one class of filters.

> 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
>         Attachments: YARN-3862-YARN-2928.wip.01.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

Reply via email to