[ 
https://issues.apache.org/jira/browse/YARN-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14385982#comment-14385982
 ] 

Zhijie Shen commented on YARN-3051:
-----------------------------------

bq. Keeping this in mind, do you think a new method will be required to fetch 
config and metrics ? I guess not.

I think we treat config and metrics in an uniform manner. We can define the 
corresponding enums of fieldsToRetrieve. 

bq. The most significant concern here is the size of configs and metrics. I 
think that's why Sangjin Lee is proposing a shallow view here.

Yeah, we used fieldsToRetrieve to specify the content we care about in this 
query. And we didn't recursively pull related entities, but just listed the 
related entities identifier. I think we should do the similar things in v2.

bq. The default view should return all fields except configs and metrics.

I propose the minimal default view to contain:

* Entity Type
* Entity ID
* Created Time
* Modified Time

All other fields can be big. Users need to specify what they want to retrieve.
 
bq. we can then say if fieldsToRetrieve is null i.e. client does not specify 
which fields to retrieve, store implementation will return all fields except 
configs and metrics.

>From REST API's point of view, if fieldsToRetrieve is not specified, how about 
>we return the minimal default view? It breaks the compatibility. Since the 
>data model is no longer compatible anyway, it shouldn't be so much additional 
>pain.

bq. So when I say get all configs for an app. I do that by specifying 
fields=configs in REST URL. And if I want metrics and configs for an app, I can 
say fields=configs,metrics.

Sounds good to me.

bq. But at least these need to be supported well:

I agree we need to support all these queries, but we don't need to make 
different REST API endpoint for each. We can always use the getEntity API, but 
use different query params, including the field-to-retrieve and the 
metrics/configs filter. Entity wrapper with the minimal view shouldn't result 
in much overhead, and the response is much self-container, such that you can 
know which entity one config/metric is related to without going back to check 
the request.

To facilitate the java developers, we can create the client lib as we did for 
the putting method. We can define the advanced to methods to get the 
configs/metrics, which hide the detail of composing the related params and 
unwrapping the response for config/metric pojo objects.

> [Storage abstraction] Create backing storage read interface for ATS readers
> ---------------------------------------------------------------------------
>
>                 Key: YARN-3051
>                 URL: https://issues.apache.org/jira/browse/YARN-3051
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Sangjin Lee
>            Assignee: Varun Saxena
>
> Per design in YARN-2928, create backing storage read interface that can be 
> implemented by multiple backing storage implementations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to