[jira] [Commented] (YARN-6027) Improve /flows API for more flexible filters fromid, collapse, userid
[ https://issues.apache.org/jira/browse/YARN-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15861739#comment-15861739 ] Sangjin Lee commented on YARN-6027: --- Absolutely. Thanks for the reminder. The idea of supporting the "collapse" here is to combine flow activities from different dates for the same flow and the user so that they are returned as a single flow activity record by the reader REST server. While we recognized that this may make rendering certain UI easier on the UI implementation standpoint, we saw a few problems with that as well. First, this goes against the design intent on flow activities as "daily activities" of flows as a fair amount of thought went into designing that table to represent daily activities. We're not saying since the schema is this way the reader has to return the data that way too to satisfy the schema. We tried to design the schema to model truly useful concepts and that way we could accomplish things like filter pushdowns. In that sense, we need to see if we can support various use cases still based on that intent and design. Another point was that if we were to introduce something like collapse we would ideally need to do this in a consistent manner across many/most endpoints. And that definitely means a large scope of introducing collapse if we do. So we agreed that we would recognize that as a separate discussion and still move forward with implementing pagination. Let me know if I missed anything major. > Improve /flows API for more flexible filters fromid, collapse, userid > - > > Key: YARN-6027 > URL: https://issues.apache.org/jira/browse/YARN-6027 > Project: Hadoop YARN > Issue Type: Sub-task > Components: timelineserver >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Labels: yarn-5355-merge-blocker > Attachments: YARN-6027-YARN-5355.0001.patch > > > In YARN-5585 , fromId is supported for retrieving entities. We need similar > filter for flows/flowRun apps and flow run and flow as well. > Along with supporting fromId, this JIRA should also discuss following points > * Should we throw an exception for entities/entity retrieval if duplicates > found? > * TimelieEntity : > ** Should equals method also check for idPrefix? > ** Does idPrefix is part of identifiers? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-6027) Improve /flows API for more flexible filters fromid, collapse, userid
[ https://issues.apache.org/jira/browse/YARN-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860820#comment-15860820 ] Rohith Sharma K S commented on YARN-6027: - Thanks [~sjlee0] for summarizing! Could you comment more about the reason for not agreeing collapse filter? (Though I was there in call, I would request other folks to add it). I will create a new JIRA for discussion more on collapse filter support. > Improve /flows API for more flexible filters fromid, collapse, userid > - > > Key: YARN-6027 > URL: https://issues.apache.org/jira/browse/YARN-6027 > Project: Hadoop YARN > Issue Type: Sub-task > Components: timelineserver >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Labels: yarn-5355-merge-blocker > Attachments: YARN-6027-YARN-5355.0001.patch > > > In YARN-5585 , fromId is supported for retrieving entities. We need similar > filter for flows/flowRun apps and flow run and flow as well. > Along with supporting fromId, this JIRA should also discuss following points > * Should we throw an exception for entities/entity retrieval if duplicates > found? > * TimelieEntity : > ** Should equals method also check for idPrefix? > ** Does idPrefix is part of identifiers? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-6027) Improve /flows API for more flexible filters fromid, collapse, userid
[ https://issues.apache.org/jira/browse/YARN-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860111#comment-15860111 ] Sangjin Lee commented on YARN-6027: --- We discussed this offline during our status call. Just to record what we agreed, can we separate the aspect of the collapse filter from this JIRA and focus on fromId and userId? I don't think there is an agreement on the collapse part, and we can still make progress with the other two filters separately. Thanks! > Improve /flows API for more flexible filters fromid, collapse, userid > - > > Key: YARN-6027 > URL: https://issues.apache.org/jira/browse/YARN-6027 > Project: Hadoop YARN > Issue Type: Sub-task > Components: timelineserver >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Labels: yarn-5355-merge-blocker > Attachments: YARN-6027-YARN-5355.0001.patch > > > In YARN-5585 , fromId is supported for retrieving entities. We need similar > filter for flows/flowRun apps and flow run and flow as well. > Along with supporting fromId, this JIRA should also discuss following points > * Should we throw an exception for entities/entity retrieval if duplicates > found? > * TimelieEntity : > ** Should equals method also check for idPrefix? > ** Does idPrefix is part of identifiers? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-6027) Improve /flows API for more flexible filters fromid, collapse, userid
[ https://issues.apache.org/jira/browse/YARN-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859344#comment-15859344 ] Varun Saxena commented on YARN-6027: Ok...I had forgotton that we currently do not limit flow runs which means that in collapse mode, if daterange is not specified, we will have to do a full table scan anyways. I have a JIRA for limiting flowruns. I will discuss with some HBase guy and check the scenario with him and handle it in that JIRA, if required. Basically its a choice between a full table scan of say 10 rows vs multiple scans with PageFilter equal to limit in each scan(or 2-3 times the limit value) and breaking out from the loop as soon as flow run limit is also reached. By default we can return 0 flow runs for flows endpoint as we already have a flowruns endpoint as well. Anyways I am not a 100% sure on this and need to check with a HBase guy. We can get back to this on the JIRA which is with me. > Improve /flows API for more flexible filters fromid, collapse, userid > - > > Key: YARN-6027 > URL: https://issues.apache.org/jira/browse/YARN-6027 > Project: Hadoop YARN > Issue Type: Sub-task > Components: timelineserver >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Labels: yarn-5355-merge-blocker > Attachments: YARN-6027-YARN-5355.0001.patch > > > In YARN-5585 , fromId is supported for retrieving entities. We need similar > filter for flows/flowRun apps and flow run and flow as well. > Along with supporting fromId, this JIRA should also discuss following points > * Should we throw an exception for entities/entity retrieval if duplicates > found? > * TimelieEntity : > ** Should equals method also check for idPrefix? > ** Does idPrefix is part of identifiers? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-6027) Improve /flows API for more flexible filters fromid, collapse, userid
[ https://issues.apache.org/jira/browse/YARN-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859062#comment-15859062 ] Rohith Sharma K S commented on YARN-6027: - [~varun_saxena] bq. Cant we apply PageFilter in steps in collapse mode? Initially I had in mind to do as you suggested in code base but it is required scan every time. Instead of scanning every time,it is better to scan once and get scanner once. However, ResultScanner is being used for retrieving which iterate through the keys should be fine. Connecting to next regions and other stuff will be handled by HBase client i.e ResultScanner. And also to apply fromId for collapsed data, first need to read all the data and apply fromid. > Improve /flows API for more flexible filters fromid, collapse, userid > - > > Key: YARN-6027 > URL: https://issues.apache.org/jira/browse/YARN-6027 > Project: Hadoop YARN > Issue Type: Sub-task > Components: timelineserver >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Labels: yarn-5355-merge-blocker > Attachments: YARN-6027-YARN-5355.0001.patch > > > In YARN-5585 , fromId is supported for retrieving entities. We need similar > filter for flows/flowRun apps and flow run and flow as well. > Along with supporting fromId, this JIRA should also discuss following points > * Should we throw an exception for entities/entity retrieval if duplicates > found? > * TimelieEntity : > ** Should equals method also check for idPrefix? > ** Does idPrefix is part of identifiers? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-6027) Improve /flows API for more flexible filters fromid, collapse, userid
[ https://issues.apache.org/jira/browse/YARN-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859028#comment-15859028 ] Rohith Sharma K S commented on YARN-6027: - [~gtCarrera9] Currently, flow activities are tracked by daily basis. When user retrieves flows using just */flows* , it returns flow entities for the user-flowname as different entities. It is useful when flow activities to be tracked by daily basis. But more generally, user wants to track flows as single entity. User need his flows given time range. In such cases, entities retrieved can not be duplicate for user-flowname. The segregation of all the flows for the combination user-flowname should be done at reader end. Default behavior is kept as-is with existing API and introducing more filters to /flows. Filter user/fromid will work without collapse mode also. All filters works independently and with combine also. I do not fully agree it is group by operation if you are pointing out from sql background. API still maintains the order of execution time. > Improve /flows API for more flexible filters fromid, collapse, userid > - > > Key: YARN-6027 > URL: https://issues.apache.org/jira/browse/YARN-6027 > Project: Hadoop YARN > Issue Type: Sub-task > Components: timelineserver >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Labels: yarn-5355-merge-blocker > Attachments: YARN-6027-YARN-5355.0001.patch > > > In YARN-5585 , fromId is supported for retrieving entities. We need similar > filter for flows/flowRun apps and flow run and flow as well. > Along with supporting fromId, this JIRA should also discuss following points > * Should we throw an exception for entities/entity retrieval if duplicates > found? > * TimelieEntity : > ** Should equals method also check for idPrefix? > ** Does idPrefix is part of identifiers? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-6027) Improve /flows API for more flexible filters fromid, collapse, userid
[ https://issues.apache.org/jira/browse/YARN-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15858664#comment-15858664 ] Li Lu commented on YARN-6027: - Thanks for the patch [~rohithsharma]! One big picture question: I'm still not 100% sure the meaning of "collapse". Seems like the use case behind this is to list all flow activities for a certain user, or group flow activities by user? If this is the case, maybe we want some parameters like groupby=user or groupby = userflow for future improvements? > Improve /flows API for more flexible filters fromid, collapse, userid > - > > Key: YARN-6027 > URL: https://issues.apache.org/jira/browse/YARN-6027 > Project: Hadoop YARN > Issue Type: Sub-task > Components: timelineserver >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Labels: yarn-5355-merge-blocker > Attachments: YARN-6027-YARN-5355.0001.patch > > > In YARN-5585 , fromId is supported for retrieving entities. We need similar > filter for flows/flowRun apps and flow run and flow as well. > Along with supporting fromId, this JIRA should also discuss following points > * Should we throw an exception for entities/entity retrieval if duplicates > found? > * TimelieEntity : > ** Should equals method also check for idPrefix? > ** Does idPrefix is part of identifiers? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-6027) Improve /flows API for more flexible filters fromid, collapse, userid
[
https://issues.apache.org/jira/browse/YARN-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857803#comment-15857803
]
Varun Saxena commented on YARN-6027:
bq. But it is expected to collapse with date range
Ok, then its fine. I was thinking we would try to display all the flows (say 10
on each page) on UI. If it is based on daterange then it should be fine in
terms of performance.
I guess we will probably display flows for the current day only.
We can probably leave a note in javadoc that a suitable daterange should be
provided in general for this REST endpoint.
bq. User can directly provide flow entity ID as fromId.
Ohh you are providing ID itself. Maybe we would like to leave a note in javadoc
and documentation that cluster part of it will be ignored. And in case of
collapse, cluster and timestamp will be ignored. In UI case, cluster would be
same as the one in REST endpoint but you can form fromID manually as well and
provide a different cluster ID than the one in REST URL path param in that
case. So we can make the behavior clear.
bq. If need to parse the errors, then why flow entity id is providing full row
key as id? I think need to change flow entity id format itself.
That is just for read. We do not make any decisions with it. But now we will.
We can encode or escape cluster and other stuff while creating ID in
FlowActivityEntity itself but when UI displays it, it may have to unescape it.
Also we would need to unescape it after splitting fromId. Changing format wont
make much difference as some delimiter or the other will have to be used and
that will have to be escaped too. Right? Cluster ID is a plain string and we
have to assume it can be anything. This would have to be done just to make the
system more robust even if we are unlikely to have a certain delimiter in
cluster or elsewhere.
bq. One optimization I can do is PageFilter can be applied in non-collapse mode
Yeah that can be done.
bq. If you look at the patch, I have removed PageFilter while scanning which
gives all the data.
Ok...Cant we apply PageFilter in steps in collapse mode? Maybe override
getResults itself. When we use it with daterange it should be fine but in cases
where daterange is not specified, this may help. What I mean is get results
from backend with PageFilter equivalent to limit. Then collapse and go back and
fetch results again if more records are required(based on limit). Something
like below. We need to check with however, if PageFilter, with limited but
possible multiple fetches will be better or getting all the data. I suspect
former may be better especially when size of table grows. Not a 100% sure
though.
{code}
int tmp=0;
while(tmp <= limit)
get results with PageFilter= limit
collapse records
tmp=tmp + number of collpased flow entities in this iteration.
end while
{code}
Additionally, a few other comments.
# In TimelineEntityFilters class javadoc, we should document collapse.
# In javadoc for fromId you mention "The fromId values should be same as fromId
info field in flow entities. It defines flow entity id.". We do not have a
fromId field in flow entities. I guess you mean id.
# In TimelineReaderWebServices#getFlows, NumberFormatException can come for
fromId as well. In handleException we should pass the correct message for this.
> Improve /flows API for more flexible filters fromid, collapse, userid
> -
>
> Key: YARN-6027
> URL: https://issues.apache.org/jira/browse/YARN-6027
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
>Reporter: Rohith Sharma K S
>Assignee: Rohith Sharma K S
> Labels: yarn-5355-merge-blocker
> Attachments: YARN-6027-YARN-5355.0001.patch
>
>
> In YARN-5585 , fromId is supported for retrieving entities. We need similar
> filter for flows/flowRun apps and flow run and flow as well.
> Along with supporting fromId, this JIRA should also discuss following points
> * Should we throw an exception for entities/entity retrieval if duplicates
> found?
> * TimelieEntity :
> ** Should equals method also check for idPrefix?
> ** Does idPrefix is part of identifiers?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-6027) Improve /flows API for more flexible filters fromid, collapse, userid
[ https://issues.apache.org/jira/browse/YARN-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857267#comment-15857267 ] Rohith Sharma K S commented on YARN-6027: - Thanks [~varun_saxena] for the review.. bq.Do we need cluster ID in fromId because we are ignoring it completely? Yes, it is required even though it is ignored, considering when fromId is being used. Do not want user to parse something and provide it as fromId. User can directly provide flow entity ID as fromId. Lets reader server handles it. Cluster Id check can be done to verify context cluster and from clusterId are equal. Ideally both should match. Otherwise we can throw exception. bq. If there is a / in cluster ID we may have to escape it to avoid parsing errors. If need to parse the errors, then why flow entity id is providing full row key as id? I think need to change flow entity id format itself. bq. If we use collapse, even with fromId, there seems to be a full table scan which will impact Yes, it does table scan. But it is expected to collapse with date range otherwise default behavior of /flows should be changed to give one day flows rather than full table data. It is a engineering issue, and may be can mention like performance will be bit slow. bq. Maybe we can send the last real ID in info field of last flow activity entity if previous query was made with collapse field Initially idea was to send last real id as fromId field info. But flows are stored per day for each user which not useful. Note that when collapse is used, we must scan to get all entities and apply fromId. Scanning can't be done half the way which end up in redundant entries for the user. Given previous comment is satisfied this should not be an issue. bq. you have mentioned that fromId validation is happening in getResult method. Could not find it ahh, I think I have missed it at global level. I have validating in one condition. Will validate at global level. bq. In processResults we first get the result from backend while applying limit and then process result for collapse and fromId filters. If you look at the patch, I have removed PageFilter while scanning which gives all the data. One optimization I can do is PageFilter can be applied in non-collapse mode because in non collapse mode scanning will start from given fromId. But the same logic can not be used for collapse mode. > Improve /flows API for more flexible filters fromid, collapse, userid > - > > Key: YARN-6027 > URL: https://issues.apache.org/jira/browse/YARN-6027 > Project: Hadoop YARN > Issue Type: Sub-task > Components: timelineserver >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Labels: yarn-5355-merge-blocker > Attachments: YARN-6027-YARN-5355.0001.patch > > > In YARN-5585 , fromId is supported for retrieving entities. We need similar > filter for flows/flowRun apps and flow run and flow as well. > Along with supporting fromId, this JIRA should also discuss following points > * Should we throw an exception for entities/entity retrieval if duplicates > found? > * TimelieEntity : > ** Should equals method also check for idPrefix? > ** Does idPrefix is part of identifiers? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-6027) Improve /flows API for more flexible filters fromid, collapse, userid
[ https://issues.apache.org/jira/browse/YARN-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856413#comment-15856413 ] Varun Saxena commented on YARN-6027: Thanks [~rohithsharma] for the patch. Few high level comments. Will take a detailed look at the patch a little later. # Do we need cluster ID in fromId because we are ignoring it completely? # If there is a / in cluster ID we may have to escape it to avoid parsing errors. # If we use collapse, even with fromId, there seems to be a full table scan which will impact the run time of this query. Maybe we can send the last real ID in info field of last flow activity entity if previous query was made with collapse field. UI can then send this ID and we can use it to make the query from that specific row instead of having a full table scan. # In processResults method you have mentioned that fromId validation is happening in getResult method. Could not find it. # In processResults we first get the result from backend while applying limit and then process result for collapse and fromId filters. In this case we may return less records than limit even if they are available. Because some entities maybe skipped due to fromId check. And even for collapse we will merge entities with same flow and user which means we will return entities less than limit. If we want behavior limit in this case to be different, we should document it. > Improve /flows API for more flexible filters fromid, collapse, userid > - > > Key: YARN-6027 > URL: https://issues.apache.org/jira/browse/YARN-6027 > Project: Hadoop YARN > Issue Type: Sub-task > Components: timelineserver >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Labels: yarn-5355-merge-blocker > Attachments: YARN-6027-YARN-5355.0001.patch > > > In YARN-5585 , fromId is supported for retrieving entities. We need similar > filter for flows/flowRun apps and flow run and flow as well. > Along with supporting fromId, this JIRA should also discuss following points > * Should we throw an exception for entities/entity retrieval if duplicates > found? > * TimelieEntity : > ** Should equals method also check for idPrefix? > ** Does idPrefix is part of identifiers? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-6027) Improve /flows API for more flexible filters fromid, collapse, userid
[
https://issues.apache.org/jira/browse/YARN-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855983#comment-15855983
]
Hadoop QA commented on YARN-6027:
-
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
36s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
20s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 9m
13s{color} | {color:green} YARN-5355 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
47s{color} | {color:green} YARN-5355 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
34s{color} | {color:green} YARN-5355 passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
5s{color} | {color:green} YARN-5355 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
45s{color} | {color:green} YARN-5355 passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase-tests
{color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
28s{color} | {color:red}
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase
in YARN-5355 has 1 extant Findbugs warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
41s{color} | {color:green} YARN-5355 passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
9s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
43s{color} | {color:green} the patch passed {color} |
| {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange}
0m 31s{color} | {color:orange}
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server: The patch generated 14 new
+ 32 unchanged - 0 fixed = 46 total (was 32) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase-tests
{color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
7s{color} | {color:green} hadoop-yarn-server-timelineservice in the patch
passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
1s{color} | {color:green} hadoop-yarn-server-timelineservice-hbase in the patch
passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 11m
26s{color} | {color:green} hadoop-yarn-server-timelineservice-hbase-tests in
the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 43m 18s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:9560f25 |
| JIRA Issue | YARN-6027 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12851368/YARN-6027-YARN-5355.0001.patch
|
| Optional
