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

Zhijie Shen commented on YARN-3041:
-----------------------------------

bq. How stringent do we want to be on allowed parent-child relationships?

It should be take care of consistently. Thanks for the remind!

bq. I think we should rename

Sounds good.

bq. I believe we discussed this somewhere before and decided that not all 
Entities need a configuration property

Oh, I thought Sangjin suggested them still being in the generic entity. But 
it's not a big issue. We can adjust it later. At this moment, let's try to get 
a working version in.

bq. info should be named metadata
bq. whats the purpose of info ? can we name it as metadata ?

I think metadata and info mean the identical stuff. I switch to use info to be 
as close to the old data model as possible.

bq. After having HierarchicalTimelineEntity do we require isRelatedToEntities & 
relatesToEntities in TimelineEntity or vice versa?

This is required to allow a generic entity to be associated to another, and not 
just limited to parent-child limitation.

bq. If any Entity data cannot be updated on subsequent posts of time line 
Entities better to capture it before hand.

It's a good question. For an entity, we allow users to keep appending data or 
updating the fields, but we cannot know it upfront, when composing the object. 
Server should be responsible for rejecting the request with the object, whose 
change on some field is invalid.

bq. IIUC if time series metric then singleData will be null and timeSeries will 
have values and if its non time series then vice versa.

It's good to behave like a C++ union type, but I don't want to have stringent 
check for this. For example, sometimes the user just wants to create the 
metric, but the data will come later. At one moment, it's possible that neither 
single data nor time series is available.

bq. flow version is not captured as class member of FlowEntity

Good catch! I added for now. But if it's not a critical attribute. We can put 
it in info section actually.

bq. Is this valid ? i was under the assumption that only FlowRun and cluster 
will be having ApplicationEntity as child

I thought FlowRun is only necessary if there's multiple levels of flows. No?

I'm about to post a new patch. It makes changes according jackson ser/der 
requirement and adds a simple demo test.

> [Data Model] create the ATS entity/event API
> --------------------------------------------
>
>                 Key: YARN-3041
>                 URL: https://issues.apache.org/jira/browse/YARN-3041
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Sangjin Lee
>            Assignee: Zhijie Shen
>         Attachments: Data_model_proposal_v2.pdf, YARN-3041.2.patch, 
> YARN-3041.preliminary.001.patch
>
>
> Per design in YARN-2928, create the ATS entity and events API.
> Also, as part of this JIRA, create YARN system entities (e.g. cluster, user, 
> flow, flow run, YARN app, ...).



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

Reply via email to