YARN-3849 looks like a bit of a non-trivial change this late for 2.7.2, I requested Wangda offline to punt it for 2.7.3.
Thanks +Vinod > On Nov 2, 2015, at 12:43 AM, Sunil Govind <[email protected]> wrote: > > Thank you. > I will help to backport to 2.7.2. > > Thank you > Sunil > > On Mon, Nov 2, 2015 at 2:10 PM Wangda Tan <[email protected]> wrote: > >> +1 to back port it to 2.7.2, marked to 2.7.2-candidate. >> >> On Mon, Nov 2, 2015 at 12:37 AM, Sunil Govind <[email protected]> >> wrote: >> >>> Thank you Wangda. Sorry to pitch in late here. >>> >>> I feel YARN-3849 is also a good candidate for 2.7.2. This s a bug fix for >>> DRC and preemption. >>> >>> Thank You >>> Sunil >>> >>> >>> On Thu, Oct 29, 2015 at 12:26 PM Naganarasimha G R (Naga) < >>> [email protected]> wrote: >>> >>>> Thanks for sharing this important viewpoint. >>>> >>>> This sub list of NodeLabels jiras what i have selected is doing minimal >>>> modifications to the core code but tries to increase the usability of >>>> NodeLabels and fix some bugs or add missing necessary features >>>> Other additional features which were done for NodeLabels like >>> Distributed >>>> Scheduling or Delegated Centralized are all not included. >>>> May be Wangda could be better judge to further scrutinize the list and >>>> select from them or even add to them >>>> My intention here is to only make the Node Labels more usable as there >>> has >>>> been long delay for 2.8 and not heard of any approximate dates for it. >>>> >>>> Regards, >>>> + Naga >>>> >>>> >>>> ________________________________________ >>>> From: Karthik Kambatla [[email protected]] >>>> Sent: Thursday, October 29, 2015 04:04 >>>> To: [email protected] >>>> Cc: Tsuyoshi Ozawa; Vinod Vavilapalli; [email protected]; >>>> [email protected]; Vinod Kumar Vavilapalli; Wangda Tan >>>> Subject: Re: 2.7.2 release plan >>>> >>>> I would like for us to make sure later maintenance releases are more >>> stable >>>> than previous ones. IMO, increasing stability is more important than >> the >>>> timing of a release. >>>> >>>> Will adding all the patches in 2.7.3 reduce the stability going from >>> 2.7.2 >>>> to 2.7.3? If yes, can we just leave them for 2.8.0? >>>> >>>> On Wed, Oct 28, 2015 at 12:07 PM, Naganarasimha G R (Naga) < >>>> [email protected]> wrote: >>>> >>>>> Yes Vinod & Tsuyoshi, >>>>> >>>>> Within a week merging them would be difficult. I can start >> backporting >>>>> them after 2.7.2 so that it can be ported to 2.7.3 faster, also >> shall i >>>>> apply 2.7.3-candidate labels to them ? >>>>> >>>>> + Naga >>>>> ______________________________ >>>>> From: Tsuyoshi Ozawa [[email protected]] >>>>> Sent: Wednesday, October 28, 2015 23:13 >>>>> To: Vinod Vavilapalli >>>>> Cc: [email protected]; [email protected]; >>>>> [email protected]; Vinod Kumar Vavilapalli; Wangda Tan; >>>>> Tsuyoshi Ozawa; Naganarasimha G R (Naga) >>>>> Subject: Re: 2.7.2 release plan >>>>> >>>>> Vinod, >>>>> >>>>> Thank you for taking care of this. I've checked the list of changes. >>>>> As a result, I agree that we don't have enough time to backport these >>>>> changes into 2.7.2 by this weekend. For a fast move, it's better >>>>> suggestion to me to backport these tickets into 2.7.3. >>>>> >>>>> Best, >>>>> - Tsuyoshi >>>>> >>>>> On Thu, Oct 29, 2015 at 2:19 AM, Vinod Vavilapalli >>>>> <[email protected]> wrote: >>>>>> 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) < >>>>> [email protected]> 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 [[email protected]] >>>>>>> Sent: Wednesday, October 28, 2015 14:28 >>>>>>> To: [email protected] >>>>>>> Cc: [email protected]; [email protected]; >> 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) >>>>>>> <[email protected]> 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 [[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 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >>
