Thanks Sangjin for the link to the previous discussions on this! I think that helps answer Steve's questions.
As decided on that thread [1], YARN-5355 as a feature branch was merged to trunk via "git merge --no-ff" . Although trunk already had TSv2 code (alpha1) prior to this merge, we chose to develop on a feature branch YARN-5355 so that we could control when changes went into trunk and didn't inadvertently disrupt trunk. Is the latest merge causing any conflicts or issues for s3guard, Steve? thanks Vrushali [1] https://lists.apache.org/thread.html/43cd65c6b6c3c0e8ac2b3c76afd9eff1f78b177fabe9c4a96d9b3d0b@1440189889@%3Ccommon-dev.hadoop.apache.org%3E On Wed, Aug 30, 2017 at 2:37 PM, Sangjin Lee <sj...@apache.org> wrote: > I recall this discussion about a couple of years ago: > https://lists.apache.org/thread.html/43cd65c6b6c3c0e8ac2b3c76afd9ef > f1f78b177fabe9c4a96d9b3d0b@1440189889@%3Ccommon-dev.hadoop.apache.org%3E > > On Wed, Aug 30, 2017 at 2:32 PM, Steve Loughran <ste...@hortonworks.com> > wrote: > >> 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/msg27 >> 383.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: yarn-dev-unsubscr...@hadoop.apache.org >> For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org >> >> >
