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 [[email protected]] Sent: Tuesday, October 27, 2015 20:42 To: [email protected]; [email protected] Cc: Chris Nauroth; [email protected]; [email protected]; 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 <[email protected]> To: "[email protected]" <[email protected]> Cc: Chris Nauroth <[email protected]>; "[email protected]" <[email protected]>; "[email protected]" <[email protected]>; "[email protected]" <[email protected]>; Vinod Kumar Vavilapalli <[email protected]> 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 <[email protected]> wrote: > +1. > > Thanks > +Vinod > > > On Jul 16, 2015, at 8:18 AM, Chris Nauroth <[email protected] > <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" <[email protected] <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 > >> <[email protected] <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 > >>>> > >>> > >> > > > > > >
