[
https://issues.apache.org/jira/browse/YARN-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14570941#comment-14570941
]
Varun Saxena commented on YARN-3051:
------------------------------------
bq. I noticed there is a readerLimit for read operations, which works for ATS
v1. I'm wondering if it's fine to use -1 to indicate there's no such limit? Not
sure if this feature is already there.
You mean limit to limit the number of records ?
bq. The fromId parameter, we may need to be careful on the concept of "id". In
timeline v2 we need context information to identify each entity, such as
cluster, user, flow, run. When querying with fromId, what kind of assumptions
should we make on the "id" here?
{{fromId}} is primarily there to be backward compatible with ATS v1. It is used
in context of entity ID only. This will be documented in the javadoc. I have
not changed names of the query params (if these parameters are supported in ATS
v1).
Whether we need to support same REST endpoints as ATS v1 for the sake of
backward compatibility or whether we can break the backward compatibility(in
case of no use case) is something which I wanted to discuss. Commented on
YARN-3411 as well regarding one such param.
bq. In some APIs, we're requiring clusterID and appID, but not having flow/run
information....Maybe we can have flow and run information as optional
parameters so that we can avoid full table scans when the caller does have flow
and run information?
Agree with your suggestion. Even I was thinking about including them in the
next patch as query params. This will make the parameter list even longer :)
bq. The current APIs require a pretty long list of parameters. For most of the
use cases, I think we can abstract something much simpler.
These parameters are directly fetched from query params coming in REST API and
are directly passed down to storage layer(after minor verification). Yes, we
can decide on few of the key parameters(which correspond to row key/primary
key) and have different methods for that. And have different reader API methods
for them as well.
> [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
> Affects Versions: YARN-2928
> Reporter: Sangjin Lee
> Assignee: Varun Saxena
> Attachments: YARN-3051-YARN-2928.003.patch,
> YARN-3051-YARN-2928.03.patch, YARN-3051.wip.02.YARN-2928.patch,
> YARN-3051.wip.patch, YARN-3051_temp.patch
>
>
> 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)
