I'd have assumed it would have gone in as one single patch, rather than a full history. I don't see why the trunk needs all the evolutionary history of a build.
What should our policy/process be here? I do currently plan to merge the s3guard in as one single squashed patch; just getting HADOOP-14809 sorted first. > On 30 Aug 2017, at 07:09, Vrushali C <vrushalic2...@gmail.com> wrote: > > I'm adding my +1 (binding) to conclude the vote. > > With 13 +1's (11 binding) and no -1's, the vote passes. We'll get on with > the merge to trunk shortly. Thanks everyone! > > Regards > Vrushali > > > On Tue, Aug 29, 2017 at 10:54 AM, varunsax...@apache.org < > varun.saxena.apa...@gmail.com> wrote: > >> +1 (binding). >> >> Kudos to all the team members for their great work! >> >> Being part of the ATSv2 team, I have been involved with either development >> or review of most of the JIRAs'. >> Tested ATSv2 in both secure and non-secure mode. Also verified that there >> is no impact when ATSv2 is turned off. >> >> Regards, >> Varun Saxena. >> >> On Tue, Aug 22, 2017 at 12:02 PM, Vrushali Channapattan < >> vrushalic2...@gmail.com> wrote: >> >>> Hi folks, >>> >>> Per earlier discussion [1], I'd like to start a formal vote to merge >>> feature branch YARN-5355 [2] (Timeline Service v.2) to trunk. The vote >>> will >>> run for 7 days, and will end August 29 11:00 PM PDT. >>> >>> We have previously completed one merge onto trunk [3] and Timeline Service >>> v2 has been part of Hadoop release 3.0.0-alpha1. >>> >>> Since then, we have been working on extending the capabilities of Timeline >>> Service v2 in a feature branch [2] for a while, and we are reasonably >>> confident that the state of the feature meets the criteria to be merged >>> onto trunk and we'd love folks to get their hands on it in a test capacity >>> and provide valuable feedback so that we can make it production-ready. >>> >>> In a nutshell, Timeline Service v.2 delivers significant scalability and >>> usability improvements based on a new architecture. What we would like to >>> merge to trunk is termed "alpha 2" (milestone 2). The feature has a >>> complete end-to-end read/write flow with security and read level >>> authorization via whitelists. You should be able to start setting it up >>> and >>> testing it. >>> >>> At a high level, the following are the key features that have been >>> implemented since alpha1: >>> - Security via Kerberos Authentication and delegation tokens >>> - Read side simple authorization via whitelist >>> - Client configurable entity sort ordering >>> - Richer REST APIs for apps, app attempts, containers, fetching metrics by >>> timerange, pagination, sub-app entities >>> - Support for storing sub-application entities (entities that exist >>> outside >>> the scope of an application) >>> - Configurable TTLs (time-to-live) for tables, configurable table >>> prefixes, >>> configurable hbase cluster >>> - Flow level aggregations done as dynamic (table level) coprocessors >>> - Uses latest stable HBase release 1.2.6 >>> >>> There are a total of 82 subtasks that were completed as part of this >>> effort. >>> >>> We paid close attention to ensure that once disabled Timeline Service v.2 >>> does not impact existing functionality when disabled (by default). >>> >>> Special thanks to a team of folks who worked hard and contributed towards >>> this effort with patches, reviews and guidance: Rohith Sharma K S, Varun >>> Saxena, Haibo Chen, Sangjin Lee, Li Lu, Vinod Kumar Vavilapalli, Joep >>> Rottinghuis, Jason Lowe, Jian He, Robert Kanter, Micheal Stack. >>> >>> Regards, >>> Vrushali >>> >>> [1] http://www.mail-archive.com/yarn-dev@hadoop.apache.org/msg27383.html >>> [2] https://issues.apache.org/jira/browse/YARN-5355 >>> [3] https://issues.apache.org/jira/browse/YARN-2928 >>> [4] https://github.com/apache/hadoop/commits/YARN-5355 >>> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
