Thank you for reporting, Naganarasimha. Vinod and Wangda, I will help you to backport these changes.
Best, - Tsuyoshi On Wed, Oct 28, 2015 at 2:57 PM, Naganarasimha G R (Naga) <garlanaganarasi...@huawei.com> wrote: > Hi Vinod, & Wangda > > I think it would be good to backport, following jira's related to NodeLabels > as it will improve debug ability and usability of NodeLabels > -------------------------------- > Key Summary > -------------------------------- > YARN-4215 YARN-2492 RMNodeLabels Manager Need to verify and replace > node labels for the only modified Node Label Mappings in the request > YARN-4162 YARN-2492 CapacityScheduler: Add resource usage by partition > and queue capacity by partition to REST API > YARN-4140 YARN-2492 RM container allocation delayed incase of app > submitted to Nodelabel partition > YARN-3717 YARN-2492 Expose app/am/queue's node-label-expression to RM > web UI / CLI / REST-API > YARN-3647 YARN-2492 RMWebServices api's should use updated api from > CommonNodeLabelsManager to get NodeLabel object > YARN-3593 YARN-2492 Add label-type and Improve "DEFAULT_PARTITION" in > Node Labels Page > YARN-3583 YARN-2492 Support of NodeLabel object instead of plain String > in YarnClient side. > YARN-3581 YARN-2492 Deprecate -directlyAccessNodeLabelStore in > RMAdminCLI > YARN-3579 YARN-2492 CommonNodeLabelsManager should support NodeLabel > instead of string label name when getting node-to-label/label-to-label > mappings > YARN-3565 YARN-2492 NodeHeartbeatRequest/RegisterNodeManagerRequest > should use NodeLabel object instead of String > YARN-3521 YARN-2492 Support return structured NodeLabel objects in REST > API > YARN-3362 YARN-2492 Add node label usage in RM CapacityScheduler web UI > YARN-3326 YARN-2492 Support RESTful API for getLabelsToNodes > YARN-3216 YARN-2492 Max-AM-Resource-Percentage should respect node > labels > YARN-3136 YARN-3091 getTransferredContainers can be a bottleneck during > AM registration > > Please inform if any support is required to backport them to 2.7.2 > > Regards, > + Naga > ________________________________________ > From: Kihwal Lee [kih...@yahoo-inc.com.INVALID] > Sent: Tuesday, October 27, 2015 20:42 > To: hdfs-dev@hadoop.apache.org; common-...@hadoop.apache.org > Cc: Chris Nauroth; yarn-...@hadoop.apache.org; > mapreduce-...@hadoop.apache.org; Vinod Kumar Vavilapalli; Ming Ma > Subject: Re: 2.7.2 release plan > > I think we need HDFS-8950 and HDFS-7725 in 2.7.2.It should be easy to > backport/cherry-pick HDFS-7725. For HDFS-8950, it will be nice if Ming can > chime in. > Kihwal > > From: Tsuyoshi Ozawa <oz...@apache.org> > To: "common-...@hadoop.apache.org" <common-...@hadoop.apache.org> > Cc: Chris Nauroth <cnaur...@hortonworks.com>; "yarn-...@hadoop.apache.org" > <yarn-...@hadoop.apache.org>; "hdfs-dev@hadoop.apache.org" > <hdfs-dev@hadoop.apache.org>; "mapreduce-...@hadoop.apache.org" > <mapreduce-...@hadoop.apache.org>; Vinod Kumar Vavilapalli > <vino...@apache.org> > Sent: Tuesday, October 27, 2015 2:39 AM > Subject: Re: 2.7.2 release plan > > Vinod and Chris, > > Thanks for your reply. I'll do also backport not only bug fixes but > also documentations(I think 2.7.2 includes them). It helps users a lot. > > Best, > - Tsuyoshi > > On Tuesday, 27 October 2015, Vinod Vavilapalli <vino...@hortonworks.com> > wrote: > >> +1. >> >> Thanks >> +Vinod >> >> > On Jul 16, 2015, at 8:18 AM, Chris Nauroth <cnaur...@hortonworks.com >> <javascript:;>> wrote: >> > >> > I'd be comfortable with inclusion of any doc-only patch in minor >> releases. >> > There is a lot of value to end users in pushing documentation fixes as >> > quickly as possible, and they don't bear the same risk of regressions or >> > incompatibilities as code changes. >> > >> > --Chris Nauroth >> > >> > >> > >> > >> > On 7/16/15, 12:38 AM, "Tsuyoshi Ozawa" <oz...@apache.org <javascript:;>> >> wrote: >> > >> >> Hi, >> >> >> >> thank you for starting the discussion about 2.7.2 release. >> >> >> >>> The focus obviously is to have blocker issues [2], bug-fixes and *no* >> >> features / improvements. >> >> >> >> I've committed YARN-3170, which is an improvement of documentation. I >> >> thought documentation pages which can be fit into branch-2.7 can be >> >> included easily. Should I revert it? >> >> >> >>>> I need help from all committers in automatically >> >> merging in any patch that fits the above criterion into 2.7.2 instead of >> >> only on trunk or 2.8. >> >> >> >> Sure, I'll try my best. >> >> >> >>> That way we can include not only blocker but also critical bug fixes to >> >>> 2.7.2 release. >> >> >> >> As Vinod mentioned, we should also apply major bug fixes into >> branch-2.7. >> >> >> >> Thanks, >> >> - Tsuyoshi >> >> >> >> On Thu, Jul 16, 2015 at 3:52 PM, Akira AJISAKA >> >> <ajisa...@oss.nttdata.co.jp <javascript:;>> wrote: > > >> >>> Thanks Vinod for starting 2.7.2 release plan. >> >>> >> >>>> The focus obviously is to have blocker issues [2], bug-fixes and *no* >> >>>> features / improvements. >> >>> >> >>> Can we adopt the plan as Karthik mentioned in "Additional maintenance >> >>> releases for Hadoop 2.y versions" thread? That way we can include not >> >>> only >> >>> blocker but also critical bug fixes to 2.7.2 release. >> >>> >> >>> In addition, branch-2.7 is a special case. (2.7.1 is the first stable >> >>> release) Therefore I'm thinking we can include major bug fixes as well. >> >>> >> >>> Regards, >> >>> Akira >> >>> >> >>> >> >>> On 7/16/15 04:13, Vinod Kumar Vavilapalli wrote: >> >>>> >> >>>> Hi all, >> >>>> >> >>>> >> >>>> Thanks everyone for the push on 2.7.1! Branch-2.7 is now open for >> >>>> commits >> >>>> to a 2.7.2 release. JIRA also now has a 2.7.2 version for all the >> >>>> sub-projects. >> >>>> >> >>>> >> >>>> Continuing the previous 2.7.1 thread on steady maintenance releases >> >>>> [1], >> >>>> we >> >>>> should follow up 2.7.1 with a 2.7.2 within 4 weeks. Earlier I tried a >> >>>> 2-3 >> >>>> week cycle for 2.7.1, but it seems to be impractical given the >> >>>> community >> >>>> size. So, I propose we target a release by the end for 4 weeks from >> >>>> now, >> >>>> starting the release close-down within 2-3 weeks. >> >>>> >> >>>> The focus obviously is to have blocker issues [2], bug-fixes and *no* >> >>>> features / improvements. I need help from all committers in >> >>>> automatically >> >>>> merging in any patch that fits the above criterion into 2.7.2 instead >> >>>> of >> >>>> only on trunk or 2.8. >> >>>> >> >>>> Thoughts? >> >>>> >> >>>> Thanks, >> >>>> >> >>>> +Vinod >> >>>> >> >>>> [1] A 2.7.1 release to follow up 2.7.0 >> >>>> http://markmail.org/message/zwzze6cqqgwq4rmw >> >>>> >> >>>> [2] 2.7.2 release blockers: >> >>>> https://issues.apache.org/jira/issues/?filter=12332867 >> >>>> >> >>> >> >> >> > >> > >> >> > >
