Tsuyoshi / Wangda / Naga, This looks too big of a list to me if we have to cut an RC by this weekend per my plan.
I’d suggest a fast move on things you think are low risk enough and punt everything else for next release. Thanks +Vinod > On Oct 28, 2015, at 3:08 AM, Naganarasimha G R (Naga) > <garlanaganarasi...@huawei.com> wrote: > > Thanks Tsuyoshi, > If required even i can pitch in :) > Additional to this we added the support in Mapreduce for labels in > MAPREDUCE-6304, > > Regards, > + Naga > ________________________________________ > From: Tsuyoshi Ozawa [oz...@apache.org] > Sent: Wednesday, October 28, 2015 14:28 > To: yarn-...@hadoop.apache.org > Cc: hdfs-dev@hadoop.apache.org; common-...@hadoop.apache.org; Vinod Kumar > Vavilapalli; Wangda tan > Subject: Re: 2.7.2 release plan > > 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 >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> >> >
