Apache Hadoop qbt Report: trunk+JDK8 on Windows/x64

[Apache Jenkins Server]

For more details, see https://builds.apache.org/job/hadoop-trunk-win/520/

[Jul 5, 2018 5:42:39 PM] (haibochen) YARN-7556. Fair scheduler configuration 
should allow resource types in
[Jul 5, 2018 5:54:19 PM] (rkanter) YARN-7451. Add missing tests to verify the 
presence of custom resources
[Jul 5, 2018 5:54:31 PM] (gifuma) YARN-8435. Fix NPE when the same client 
simultaneously contact for the
[Jul 5, 2018 7:22:18 PM] (aengineer) Revert "Merge branch 'trunk' of




-1 overall


The following subsystems voted -1:
compile mvninstall pathlen unit


The following subsystems voted -1 but
were configured to be filtered/ignored:
cc javac


The following subsystems are considered long running:
(runtime bigger than 1h 00m 00s)
unit


Specific tests:

Failed junit tests :

   hadoop.crypto.TestCryptoStreamsWithOpensslAesCtrCryptoCodec 
   hadoop.fs.contract.rawlocal.TestRawlocalContractAppend 
   hadoop.fs.TestFileUtil 
   hadoop.fs.TestFsShellCopy 
   hadoop.fs.TestFsShellList 
   hadoop.http.TestHttpServer 
   hadoop.http.TestHttpServerLogs 
   hadoop.io.nativeio.TestNativeIO 
   hadoop.ipc.TestIPC 
   hadoop.ipc.TestSocketFactory 
   hadoop.metrics2.impl.TestStatsDMetrics 
   hadoop.security.TestSecurityUtil 
   hadoop.security.TestShellBasedUnixGroupsMapping 
   hadoop.security.token.TestDtUtilShell 
   hadoop.util.TestDiskCheckerWithDiskIo 
   hadoop.util.TestNativeCodeLoader 
   hadoop.hdfs.client.impl.TestBlockReaderLocal 
   hadoop.hdfs.qjournal.server.TestJournalNode 
   hadoop.hdfs.qjournal.server.TestJournalNodeSync 
   hadoop.hdfs.server.datanode.fsdataset.impl.TestProvidedImpl 
   hadoop.hdfs.server.datanode.TestBlockPoolSliceStorage 
   hadoop.hdfs.server.datanode.TestBlockScanner 
   hadoop.hdfs.server.datanode.TestDataNodeFaultInjector 
   hadoop.hdfs.server.datanode.TestDataNodeVolumeFailure 
   hadoop.hdfs.server.datanode.TestDirectoryScanner 
   hadoop.hdfs.server.datanode.TestStorageReport 
   hadoop.hdfs.server.diskbalancer.TestDiskBalancer 
   hadoop.hdfs.server.diskbalancer.TestDiskBalancerRPC 
   hadoop.hdfs.server.namenode.ha.TestDFSUpgradeWithHA 
   hadoop.hdfs.server.namenode.ha.TestRetryCacheWithHA 
   hadoop.hdfs.server.namenode.metrics.TestNameNodeMetrics 
   hadoop.hdfs.server.namenode.snapshot.TestSnapshotFileLength 
   hadoop.hdfs.TestDatanodeStartupFixesLegacyStorageIDs 
   hadoop.hdfs.TestDecommission 
   hadoop.hdfs.TestDFSShell 
   hadoop.hdfs.TestDFSStripedInputStreamWithRandomECPolicy 
   hadoop.hdfs.TestDFSStripedOutputStreamWithFailure 
   hadoop.hdfs.TestDFSStripedOutputStreamWithFailureWithRandomECPolicy 
   hadoop.hdfs.TestDFSUpgradeFromImage 
   hadoop.hdfs.TestFetchImage 
   hadoop.hdfs.TestFileConcurrentReader 
   hadoop.hdfs.TestHDFSFileSystemContract 
   hadoop.hdfs.TestPread 
   hadoop.hdfs.TestReconstructStripedFile 
   hadoop.hdfs.TestSecureEncryptionZoneWithKMS 
   hadoop.hdfs.TestTrashWithSecureEncryptionZones 
   hadoop.hdfs.tools.TestDFSAdmin 
   hadoop.hdfs.web.TestWebHDFS 
   hadoop.hdfs.web.TestWebHdfsUrl 
   hadoop.fs.http.server.TestHttpFSServerWebServer 
   
hadoop.yarn.logaggregation.filecontroller.ifile.TestLogAggregationIndexFileController
 
   
hadoop.yarn.server.nodemanager.containermanager.launcher.TestContainerLaunch 
   
hadoop.yarn.server.nodemanager.containermanager.monitor.TestContainerMetrics 
   hadoop.yarn.server.nodemanager.containermanager.TestAuxServices 
   hadoop.yarn.server.nodemanager.containermanager.TestContainerManager 
   hadoop.yarn.server.nodemanager.recovery.TestNMLeveldbStateStoreService 
   hadoop.yarn.server.nodemanager.TestContainerExecutor 
   hadoop.yarn.server.nodemanager.TestNodeManagerResync 
   hadoop.yarn.server.webproxy.amfilter.TestAmFilter 
   
hadoop.yarn.server.applicationhistoryservice.TestApplicationHistoryServer 
   
hadoop.yarn.server.timeline.security.TestTimelineAuthenticationFilterForV1 
   hadoop.yarn.server.resourcemanager.recovery.TestLeveldbRMStateStore 
   
hadoop.yarn.server.resourcemanager.scheduler.capacity.conf.TestFSSchedulerConfigurationStore
 
   
hadoop.yarn.server.resourcemanager.scheduler.capacity.conf.TestLeveldbConfigurationStore
 
   
hadoop.yarn.server.resourcemanager.scheduler.capacity.TestCapacityScheduler 
   
hadoop.yarn.server.resourcemanager.scheduler.capacity.TestNodeLabelContainerAllocation
 
   
hadoop.yarn.server.resourcemanager.scheduler.capacity.TestQueueManagementDynamicEditPolicy
 
   
hadoop.yarn.server.resourcemanager.scheduler.constraint.TestPlacementProcessor 
   
hadoop.yarn.server.resourcemanager.scheduler.fair.TestAllocationFileLoaderService
 
   hadoop.yarn.server.resourcemanager.TestResourceTrackerService 
   hadoop.yarn.server.timelineservice.security.TestTimelineAuth

Re: [VOTE] Merge ContainerIO branch (HDDS-48) in to trunk

[Arpit Agarwal]

Late +1 for the merge.

Thanks for driving this improvement Hanisha and Bharat.


On 6/29/18, 3:10 PM, "Bharat Viswanadham"  wrote:

Hi All,

Given the positive response to the discussion thread [1], here is the 
formal vote thread to merge HDDS-48 in to trunk.

Summary of code changes:
1. Code changes for this branch are done in the hadoop-hdds subproject and 
hadoop-ozone subproject, there is no impact to hadoop-hdfs.
2. Added support for multiple container types in the datanode code path.
3. Added disk layout logic for the containers to supports future upgrades.
4. Added support for volume Choosing policy to distribute containers across 
disks on the datanode.
5. Changed the format of the .container file to a human-readable format 
(yaml)


 The vote will run for 7 days, ending Fri July 6th. I will start this vote 
with my +1.

Thanks,
Bharat

[1] 
https://lists.apache.org/thread.html/79998ebd2c3837913a22097102efd8f41c3b08cb1799c3d3dea4876b@%3Chdfs-dev.hadoop.apache.org%3E


-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

[RESULT][VOTE] Merge ContainerIO branch (HDDS-48) in to trunk

[Bharat Viswanadham]

The vote passes with +1s from 6 committers and 2 contributors. There are no 
-1's.
Thanks everyone for voting.

Voting Thread:
https://lists.apache.org/thread.html/b63e4569407b61a333ddf7a646dcf9ca169d2fd2cb2344d113d80697@%3Chdfs-dev.hadoop.apache.org%3E


Thanks,
Bharat


On 6/29/18, 3:14 PM, "Bharat Viswanadham"  wrote:

Fixing subject line of the mail.


Thanks,
Bharat



On 6/29/18, 3:10 PM, "Bharat Viswanadham"  
wrote:

Hi All,

Given the positive response to the discussion thread [1], here is the 
formal vote thread to merge HDDS-48 in to trunk.

Summary of code changes:
1. Code changes for this branch are done in the hadoop-hdds subproject 
and hadoop-ozone subproject, there is no impact to hadoop-hdfs.
2. Added support for multiple container types in the datanode code path.
3. Added disk layout logic for the containers to supports future 
upgrades.
4. Added support for volume Choosing policy to distribute containers 
across disks on the datanode.
5. Changed the format of the .container file to a human-readable format 
(yaml)


 The vote will run for 7 days, ending Fri July 6th. I will start this 
vote with my +1.

Thanks,
Bharat

[1] 
https://lists.apache.org/thread.html/79998ebd2c3837913a22097102efd8f41c3b08cb1799c3d3dea4876b@%3Chdfs-dev.hadoop.apache.org%3E

Re: What's the difference between branch-3 and branch-3.0?

[Jason Lowe]

branch-3 has re-appeared yet again on June 2nd.  Looks like the
inadvertent branch-3 change from HDFS-11847 was somehow pushed again?

Anyway this branch needs to be deleted yet again as committers are
accidentally committing to it again thinking their change is going
into 3.0.x.  Is an INFRA ticket still the way to clean this up?

I'm starting to wonder if we need a push hook to prevent "branch-3"
pushes until we really need a branch-3 (i.e.: when Hadoop 4.x starts
development).  Or to generalize it a bit more, block creation of
branches with the prefix of "branch-" could be blocked by default but
allowed if the first commit fit a particular form like "Initial commit
for the X.Y.Z release."  That way it shouldn't be easy to accidentally
create a new release line.

Jason

On Thu, Feb 22, 2018 at 2:55 PM, Chris Douglas  wrote:
> branch-3 has reappeared. Filed INFRA-16086 [1]. -C
>
> [1]: https://issues.apache.org/jira/browse/INFRA-16086
>
>
> On Wed, Jan 17, 2018 at 12:32 PM, Jason Lowe  wrote:
>> I filed INFRA-15859 to have branch-3 deleted.
>>
>> Jason
>>
>> On Wed, Jan 17, 2018 at 1:23 PM, Eric Payne <
>> eric.payne1...@yahoo.com.invalid> wrote:
>>
>>> +1 for removing the branch-3 branch. It should be done soon so more
>>> confusion can be avoided. Thanks Jason for tracking this down.
>>> -Eric
>>>
>>>
>>>   From: Jason Lowe 
>>>  To: Hadoop Common ; ma...@cloudera.com
>>>  Sent: Wednesday, January 17, 2018 12:42 PM
>>>  Subject: Re: What's the difference between branch-3 and branch-3.0?
>>>
>>> This was created accidentally when HDFS-11847 was committed.  As such we
>>> should delete the branch-3 branch and port over the commits that went into
>>> branch-3 instead of branch-3.0.  For the former, I'm assuming that requires
>>> an INFRA ticket since I would hope any committer would not have the ability
>>> to destroy a branch-* branch.  Unfortunately even after it's deleted I
>>> suspect we will see it reappear if someone pushes up their old copy of
>>> branch-3 again, so committers will need to be vigilant.
>>>
>>> I'll work on porting the missing changes below from branch-3 over to
>>> branch-3.0.  I'll wait for some more consensus on the branch-3 deletion
>>> before filing the INFRA ticket since deleting a branch shouldn't be done
>>> lightly.
>>>
>>> Jason
>>>
>>>
>>> commit 0802d8afa355d9a0683fdb2e9c4963e8fea8644f
>>> Author: Vinayakumar B 
>>> Date:  Wed Jan 17 14:16:48 2018 +0530
>>>
>>> HDFS-9049. Make Datanode Netty reverse proxy port to be configurable.
>>> Contributed by Vinayakumar B.
>>>
>>> (cherry picked from commit 09efdfe9e13c9695867ce4034aa6ec970c2032f1)
>>>
>>> commit db8345fa9cd124728d935f725525e2626438b4c1
>>> Author: Lei Xu 
>>> Date:  Tue Jan 16 15:15:11 2018 -0800
>>>
>>> HDFS-13004. TestLeaseRecoveryStriped.testLeaseRecovery is failing when
>>> safeLength is 0MB or larger than the test file. (Zsolt Venczel via lei)
>>>
>>> (cherry picked from commit 3bd9ea63df769345a9d02a404cfb61323a4cd7e3)
>>>
>>> commit 82741091a78d7ce62c240ec3e7f81a3a9a3fee36
>>> Author: Inigo Goiri 
>>> Date:  Mon Jan 15 12:21:24 2018 -0800
>>>
>>> HDFS-12919. RBF: Support erasure coding methods in RouterRpcServer.
>>> Contributed by Inigo Goiri.
>>>
>>> commit d3fbcd92fe53192a319683b9ac72179cb28bd978
>>> Author: Yiqun Lin 
>>> Date:  Sat Jan 6 14:31:08 2018 +0800
>>>
>>> HDFS-11848. Enhance dfsadmin listOpenFiles command to list files under
>>> a given path. Contributed by Yiqun Lin.
>>>
>>> commit ee44783515a55ab9fd368660c5cc2c2bc392132e
>>> Author: Manoj Govindassamy 
>>> Date:  Tue Jan 2 14:59:36 2018 -0800
>>>
>>> HDFS-11847. Enhance dfsadmin listOpenFiles command to list files
>>> blocking datanode decommissioning.
>>>
>>>
>>>
>>> On Wed, Jan 17, 2018 at 10:53 AM, Brahma Reddy Battula 
>>> wrote:
>>>
>>> > IMHO,we no need to have *branch-3* still trunk moves.Shall we remove as
>>> it
>>> > make confuses.??
>>> >
>>> >
>>> >
>>> >
>>> > Brahma Reddy Battula
>>> >
>>> > On Wed, Jan 17, 2018 at 9:41 PM, Jason Lowe 
>>> > wrote:
>>> >
>>> > > I recently noticed some committers posting commits to branch-3 and
>>> > marking
>>> > > the JIRA as fixed in 3.0.1.  I thought branch-3.0 was tracking 3.0.x
>>> > > releases, including branch-3.0.1 as of now, so I am confused what
>>> > branch-3
>>> > > is for.  The versions in the poms between branch-3 and branch-3.0 both
>>> > say
>>> > > they are 3.0.1-SNAPSHOT.
>>> > >
>>> > > I recall we discussed _not_ creating branch-3 until it is necessary,
>>> and
>>> > it
>>> > > is only necessary for branch-3 to exist when trunk stop tracking 3.x
>>> > > releases (i.e.: when trunk moves to 4.0.0-SNAPSHOT).
>>> > >
>>> > > Jason
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> >
>>> >
>>> > --Brahma Reddy Battula
>>> >
>>>
>>>
>>>
>>>
>
> -
> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: common-dev-h...@hadoop.apache.org
>

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

[Subru Krishnan]

 Thanks everyone particularly Anu & Sunil for resolving the issue.

Yes, Arpit I am canceling the vote and let's open trunk for commits. I'll
also close the INFRA jira.

-Subru

On Fri, Jul 6, 2018 at 11:18 AM, Arpit Agarwal 
wrote:

> Thanks Sunil!
>
> @Subru and others who voted for force push, are you okay with cancelling
> this vote and declaring trunk open for commits?
>
>
> On 7/6/18, 11:16 AM, "Sunil G"  wrote:
>
> Thanks. These patches are now restored.
>
> - Sunil
>
>
> On Fri, Jul 6, 2018 at 11:14 AM Vinod Kumar Vavilapalli <
> vino...@apache.org>
> wrote:
>
> > +1
> >
> > Thanks
> > +Vinod
> >
> >
> > On Jul 6, 2018, at 11:12 AM, Sunil G  wrote:
> >
> > I just checked.  YARN-7556 and YARN-7451 can be cherry-picked.
> > I cherry-picked in my local and compiled. Things are good.
> >
> > I can push this now  which will restore trunk to its original.
> > I can do this if there are no objection.
> >
> > - Sunil
> >
> > On Fri, Jul 6, 2018 at 11:10 AM Arpit Agarwal <
> aagar...@hortonworks.com>
> > wrote:
> >
> > afaict YARN-8435 is still in trunk. YARN-7556 and YARN-7451 are not.
> >
> >
> > From: Giovanni Matteo Fumarola 
> > Date: Friday, July 6, 2018 at 10:59 AM
> > To: Vinod Kumar Vavilapalli 
> > Cc: Anu Engineer , Arpit Agarwal <
> > aagar...@hortonworks.com>, "su...@apache.org" , "
> > yarn-...@hadoop.apache.org" , "
> > hdfs-...@hadoop.apache.org" , "
> > common-dev@hadoop.apache.org" , "
> > mapreduce-...@hadoop.apache.org" 
> > Subject: Re: [VOTE] reset/force push to clean up inadvertent merge
> commit
> > pushed to trunk
> >
> > Everything seems ok except the 3 commits: YARN-8435, YARN-7556,
> YARN-7451
> > are not anymore in trunk due to the revert.
> >
> > Haibo/Robert if you can recommit your patches I will commit mine
> > subsequently to preserve the original order.
> >
> > (My apology for the mess I did with the merge commit)
> >
> > On Fri, Jul 6, 2018 at 10:42 AM, Vinod Kumar Vavilapalli <
> > vino...@apache.org>
> wrote:
> > I will add that the branch also successfully compiles.
> >
> > Let's just move forward as is, unblock commits and just fix things if
> > anything is broken.
> >
> > +Vinod
> >
> > On Jul 6, 2018, at 10:30 AM, Anu Engineer  >
> > >
> wrote:
> >
> >
> > Hi All,
> >
> > [ Thanks to Arpit for working offline and verifying that branch is
> >
> > indeed good.]
> >
> >
> > I want to summarize what I know of this issue and also solicit other
> >
> > points of view.
> >
> >
> > We reverted the commit(c163d1797) from the branch, as soon as we
> noticed
> >
> > it. That is, we have made no other commits after the merge commit.
> >
> >
> > We used the following command to revert
> > git revert -c c163d1797ade0f47d35b4a44381b8ef1dfec5b60 -m 1
> >
> > Giovanni's branch had three commits + merge, The JIRAs he had were
> >
> > YARN-7451, YARN-7556, YARN-8435.
> >
> >
> > The issue seems to be the revert of merge has some diffs. I am not a
> >
> > YARN developer, so the only problem is to look at the revert and see
> if
> > there were any spurious edits in Giovanni's original commit + merge.
> >
> > If there are none, we don't need a reset/force push.  But if we find
> an
> >
> > issue I am more than willing to go the force commit route.
> >
> >
> > The revert takes the trunk back to the point of the first commit from
> >
> > Giovanni which is YARN-8435. His branch was also rewriting the order
> of
> > commits which we have lost due to the revert.
> >
> >
> > Based on what I know so far, I am -1 on the force push.
> >
> > In other words, I am trying to understand why we need the force
> push. I
> >
> > have left a similar comment in JIRA (
> > https://issues.apache.org/jira/browse/INFRA-16727) too.
> >
> >
> >
> > Thanks
> > Anu
> >
> >
> > On 7/6/18, 10:24 AM, "Arpit Agarwal"  mailto:
> >
> > aagar...@hortonworks.com>> wrote:
> >
> >
> >   -1 for the force push. Nothing is broken in trunk. The history
> looks
> >
> > ugly for two commits and we can live with it.
> >
> >
> >   The revert restored the branch to Giovanni's intent. i.e. only
> >
> > YARN-8435 is applied. Verified there is no delta between hashes
> 0d9804d and
> > 39ad989 (HEAD).
> >
> >
> >   39ad989 2018-07-05 aengineer@ o {apache/trunk} Revert "Merge
> branch
> >
> > 't...
> >
> >   c163d17 2018-07-05 gifuma@apa M─┐ Merge branch 'trunk' of
> >
> > https://git-...
> >
> >   99febe7 2018-07-05 rkanter@ap │

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

[Arpit Agarwal]

Thanks Sunil!

@Subru and others who voted for force push, are you okay with cancelling this 
vote and declaring trunk open for commits?


On 7/6/18, 11:16 AM, "Sunil G"  wrote:

Thanks. These patches are now restored.

- Sunil


On Fri, Jul 6, 2018 at 11:14 AM Vinod Kumar Vavilapalli 
wrote:

> +1
>
> Thanks
> +Vinod
>
>
> On Jul 6, 2018, at 11:12 AM, Sunil G  wrote:
>
> I just checked.  YARN-7556 and YARN-7451 can be cherry-picked.
> I cherry-picked in my local and compiled. Things are good.
>
> I can push this now  which will restore trunk to its original.
> I can do this if there are no objection.
>
> - Sunil
>
> On Fri, Jul 6, 2018 at 11:10 AM Arpit Agarwal 
> wrote:
>
> afaict YARN-8435 is still in trunk. YARN-7556 and YARN-7451 are not.
>
>
> From: Giovanni Matteo Fumarola 
> Date: Friday, July 6, 2018 at 10:59 AM
> To: Vinod Kumar Vavilapalli 
> Cc: Anu Engineer , Arpit Agarwal <
> aagar...@hortonworks.com>, "su...@apache.org" , "
> yarn-...@hadoop.apache.org" , "
> hdfs-...@hadoop.apache.org" , "
> common-dev@hadoop.apache.org" , "
> mapreduce-...@hadoop.apache.org" 
> Subject: Re: [VOTE] reset/force push to clean up inadvertent merge commit
> pushed to trunk
>
> Everything seems ok except the 3 commits: YARN-8435, YARN-7556, YARN-7451
> are not anymore in trunk due to the revert.
>
> Haibo/Robert if you can recommit your patches I will commit mine
> subsequently to preserve the original order.
>
> (My apology for the mess I did with the merge commit)
>
> On Fri, Jul 6, 2018 at 10:42 AM, Vinod Kumar Vavilapalli <
> vino...@apache.org> wrote:
> I will add that the branch also successfully compiles.
>
> Let's just move forward as is, unblock commits and just fix things if
> anything is broken.
>
> +Vinod
>
> On Jul 6, 2018, at 10:30 AM, Anu Engineer 
> > wrote:
>
>
> Hi All,
>
> [ Thanks to Arpit for working offline and verifying that branch is
>
> indeed good.]
>
>
> I want to summarize what I know of this issue and also solicit other
>
> points of view.
>
>
> We reverted the commit(c163d1797) from the branch, as soon as we noticed
>
> it. That is, we have made no other commits after the merge commit.
>
>
> We used the following command to revert
> git revert -c c163d1797ade0f47d35b4a44381b8ef1dfec5b60 -m 1
>
> Giovanni's branch had three commits + merge, The JIRAs he had were
>
> YARN-7451, YARN-7556, YARN-8435.
>
>
> The issue seems to be the revert of merge has some diffs. I am not a
>
> YARN developer, so the only problem is to look at the revert and see if
> there were any spurious edits in Giovanni's original commit + merge.
>
> If there are none, we don't need a reset/force push.  But if we find an
>
> issue I am more than willing to go the force commit route.
>
>
> The revert takes the trunk back to the point of the first commit from
>
> Giovanni which is YARN-8435. His branch was also rewriting the order of
> commits which we have lost due to the revert.
>
>
> Based on what I know so far, I am -1 on the force push.
>
> In other words, I am trying to understand why we need the force push. I
>
> have left a similar comment in JIRA (
> https://issues.apache.org/jira/browse/INFRA-16727) too.
>
>
>
> Thanks
> Anu
>
>
> On 7/6/18, 10:24 AM, "Arpit Agarwal" 
> aagar...@hortonworks.com>> wrote:
>
>
>   -1 for the force push. Nothing is broken in trunk. The history looks
>
> ugly for two commits and we can live with it.
>
>
>   The revert restored the branch to Giovanni's intent. i.e. only
>
> YARN-8435 is applied. Verified there is no delta between hashes 0d9804d 
and
> 39ad989 (HEAD).
>
>
>   39ad989 2018-07-05 aengineer@ o {apache/trunk} Revert "Merge branch
>
> 't...
>
>   c163d17 2018-07-05 gifuma@apa M─┐ Merge branch 'trunk' of
>
> https://git-...
>
>   99febe7 2018-07-05 rkanter@ap │ o YARN-7451. Add missing tests to
>
> veri...
>
>   1726247 2018-07-05 haibochen@ │ o YARN-7556. Fair scheduler
>
> configurat...
>
>   0d9804d 2018-07-05 gifuma@apa o │ YARN-8435. Fix NPE when the same
>
> cli...
>
>   71df8c2 2018-07-05 nanda@apac o─┘ HDDS-212. Introduce
>
> NodeStateManager...
>
>
>   Regards,
>   Arpit
>
>
>   On 7/5/18, 2:37 PM, "Subru Krishnan" 
> su...@apache.org>> wrote:
>
>
>   Folks,
>
>   There was a merge commit accidentally pushed to trunk, you can

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

[Sunil G]

Thanks. These patches are now restored.

- Sunil


On Fri, Jul 6, 2018 at 11:14 AM Vinod Kumar Vavilapalli 
wrote:

> +1
>
> Thanks
> +Vinod
>
>
> On Jul 6, 2018, at 11:12 AM, Sunil G  wrote:
>
> I just checked.  YARN-7556 and YARN-7451 can be cherry-picked.
> I cherry-picked in my local and compiled. Things are good.
>
> I can push this now  which will restore trunk to its original.
> I can do this if there are no objection.
>
> - Sunil
>
> On Fri, Jul 6, 2018 at 11:10 AM Arpit Agarwal 
> wrote:
>
> afaict YARN-8435 is still in trunk. YARN-7556 and YARN-7451 are not.
>
>
> From: Giovanni Matteo Fumarola 
> Date: Friday, July 6, 2018 at 10:59 AM
> To: Vinod Kumar Vavilapalli 
> Cc: Anu Engineer , Arpit Agarwal <
> aagar...@hortonworks.com>, "su...@apache.org" , "
> yarn-...@hadoop.apache.org" , "
> hdfs-...@hadoop.apache.org" , "
> common-dev@hadoop.apache.org" , "
> mapreduce-...@hadoop.apache.org" 
> Subject: Re: [VOTE] reset/force push to clean up inadvertent merge commit
> pushed to trunk
>
> Everything seems ok except the 3 commits: YARN-8435, YARN-7556, YARN-7451
> are not anymore in trunk due to the revert.
>
> Haibo/Robert if you can recommit your patches I will commit mine
> subsequently to preserve the original order.
>
> (My apology for the mess I did with the merge commit)
>
> On Fri, Jul 6, 2018 at 10:42 AM, Vinod Kumar Vavilapalli <
> vino...@apache.org> wrote:
> I will add that the branch also successfully compiles.
>
> Let's just move forward as is, unblock commits and just fix things if
> anything is broken.
>
> +Vinod
>
> On Jul 6, 2018, at 10:30 AM, Anu Engineer 
> > wrote:
>
>
> Hi All,
>
> [ Thanks to Arpit for working offline and verifying that branch is
>
> indeed good.]
>
>
> I want to summarize what I know of this issue and also solicit other
>
> points of view.
>
>
> We reverted the commit(c163d1797) from the branch, as soon as we noticed
>
> it. That is, we have made no other commits after the merge commit.
>
>
> We used the following command to revert
> git revert -c c163d1797ade0f47d35b4a44381b8ef1dfec5b60 -m 1
>
> Giovanni's branch had three commits + merge, The JIRAs he had were
>
> YARN-7451, YARN-7556, YARN-8435.
>
>
> The issue seems to be the revert of merge has some diffs. I am not a
>
> YARN developer, so the only problem is to look at the revert and see if
> there were any spurious edits in Giovanni's original commit + merge.
>
> If there are none, we don't need a reset/force push.  But if we find an
>
> issue I am more than willing to go the force commit route.
>
>
> The revert takes the trunk back to the point of the first commit from
>
> Giovanni which is YARN-8435. His branch was also rewriting the order of
> commits which we have lost due to the revert.
>
>
> Based on what I know so far, I am -1 on the force push.
>
> In other words, I am trying to understand why we need the force push. I
>
> have left a similar comment in JIRA (
> https://issues.apache.org/jira/browse/INFRA-16727) too.
>
>
>
> Thanks
> Anu
>
>
> On 7/6/18, 10:24 AM, "Arpit Agarwal" 
> aagar...@hortonworks.com>> wrote:
>
>
>   -1 for the force push. Nothing is broken in trunk. The history looks
>
> ugly for two commits and we can live with it.
>
>
>   The revert restored the branch to Giovanni's intent. i.e. only
>
> YARN-8435 is applied. Verified there is no delta between hashes 0d9804d and
> 39ad989 (HEAD).
>
>
>   39ad989 2018-07-05 aengineer@ o {apache/trunk} Revert "Merge branch
>
> 't...
>
>   c163d17 2018-07-05 gifuma@apa M─┐ Merge branch 'trunk' of
>
> https://git-...
>
>   99febe7 2018-07-05 rkanter@ap │ o YARN-7451. Add missing tests to
>
> veri...
>
>   1726247 2018-07-05 haibochen@ │ o YARN-7556. Fair scheduler
>
> configurat...
>
>   0d9804d 2018-07-05 gifuma@apa o │ YARN-8435. Fix NPE when the same
>
> cli...
>
>   71df8c2 2018-07-05 nanda@apac o─┘ HDDS-212. Introduce
>
> NodeStateManager...
>
>
>   Regards,
>   Arpit
>
>
>   On 7/5/18, 2:37 PM, "Subru Krishnan" 
> su...@apache.org>> wrote:
>
>
>   Folks,
>
>   There was a merge commit accidentally pushed to trunk, you can
>
> find the
>
>   details in the mail thread [1].
>
>   I have raised an INFRA ticket [2] to reset/force push to clean up
>
> trunk.
>
>
>   Can we have a quick vote for INFRA sign-off to proceed as this is
>
> blocking
>
>   all commits?
>
>   Thanks,
>   Subru
>
>   [1]
>
>
> http://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201807.mbox/%3CCAHqguubKBqwfUMwhtJuSD7X1Bgfro_P6FV%2BhhFhMMYRaxFsF9Q%40mail.gmail.com%3E
>
>   [2] https://issues.apache.org/jira/browse/INFRA-16727
>
>
>
>   -
>   To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
>
>  >
>
>   For additional commands, e-mail: common-dev-h...@hadoop.apache.org
>
>  >
>
>
>
>
> 

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

[Anu Engineer]

@Sunil G +1, Thanks for fixing this issue.

--Anu


On 7/6/18, 11:12 AM, "Sunil G"  wrote:

I just checked.  YARN-7556 and YARN-7451 can be cherry-picked.
I cherry-picked in my local and compiled. Things are good.

I can push this now  which will restore trunk to its original.
I can do this if there are no objection.

- Sunil

On Fri, Jul 6, 2018 at 11:10 AM Arpit Agarwal 
wrote:

> afaict YARN-8435 is still in trunk. YARN-7556 and YARN-7451 are not.
>
>
> From: Giovanni Matteo Fumarola 
> Date: Friday, July 6, 2018 at 10:59 AM
> To: Vinod Kumar Vavilapalli 
> Cc: Anu Engineer , Arpit Agarwal <
> aagar...@hortonworks.com>, "su...@apache.org" , "
> yarn-...@hadoop.apache.org" , "
> hdfs-...@hadoop.apache.org" , "
> common-dev@hadoop.apache.org" , "
> mapreduce-...@hadoop.apache.org" 
> Subject: Re: [VOTE] reset/force push to clean up inadvertent merge commit
> pushed to trunk
>
> Everything seems ok except the 3 commits: YARN-8435, YARN-7556, YARN-7451
> are not anymore in trunk due to the revert.
>
> Haibo/Robert if you can recommit your patches I will commit mine
> subsequently to preserve the original order.
>
> (My apology for the mess I did with the merge commit)
>
> On Fri, Jul 6, 2018 at 10:42 AM, Vinod Kumar Vavilapalli <
> vino...@apache.org> wrote:
> I will add that the branch also successfully compiles.
>
> Let's just move forward as is, unblock commits and just fix things if
> anything is broken.
>
> +Vinod
>
> > On Jul 6, 2018, at 10:30 AM, Anu Engineer  > wrote:
> >
> > Hi All,
> >
> > [ Thanks to Arpit for working offline and verifying that branch is
> indeed good.]
> >
> > I want to summarize what I know of this issue and also solicit other
> points of view.
> >
> > We reverted the commit(c163d1797) from the branch, as soon as we noticed
> it. That is, we have made no other commits after the merge commit.
> >
> > We used the following command to revert
> > git revert -c c163d1797ade0f47d35b4a44381b8ef1dfec5b60 -m 1
> >
> > Giovanni's branch had three commits + merge, The JIRAs he had were
> YARN-7451, YARN-7556, YARN-8435.
> >
> > The issue seems to be the revert of merge has some diffs. I am not a
> YARN developer, so the only problem is to look at the revert and see if
> there were any spurious edits in Giovanni's original commit + merge.
> > If there are none, we don't need a reset/force push.  But if we find an
> issue I am more than willing to go the force commit route.
> >
> > The revert takes the trunk back to the point of the first commit from
> Giovanni which is YARN-8435. His branch was also rewriting the order of
> commits which we have lost due to the revert.
> >
> > Based on what I know so far, I am -1 on the force push.
> >
> > In other words, I am trying to understand why we need the force push. I
> have left a similar comment in JIRA (
> https://issues.apache.org/jira/browse/INFRA-16727) too.
> >
> >
> > Thanks
> > Anu
> >
> >
> > On 7/6/18, 10:24 AM, "Arpit Agarwal"  aagar...@hortonworks.com>> wrote:
> >
> >-1 for the force push. Nothing is broken in trunk. The history looks
> ugly for two commits and we can live with it.
> >
> >The revert restored the branch to Giovanni's intent. i.e. only
> YARN-8435 is applied. Verified there is no delta between hashes 0d9804d 
and
> 39ad989 (HEAD).
> >
> >39ad989 2018-07-05 aengineer@ o {apache/trunk} Revert "Merge branch
> 't...
> >c163d17 2018-07-05 gifuma@apa M─┐ Merge branch 'trunk' of
> https://git-...
> >99febe7 2018-07-05 rkanter@ap │ o YARN-7451. Add missing tests to
> veri...
> >1726247 2018-07-05 haibochen@ │ o YARN-7556. Fair scheduler
> configurat...
> >0d9804d 2018-07-05 gifuma@apa o │ YARN-8435. Fix NPE when the same
> cli...
> >71df8c2 2018-07-05 nanda@apac o─┘ HDDS-212. Introduce
> NodeStateManager...
> >
> >Regards,
> >Arpit
> >
> >
> >On 7/5/18, 2:37 PM, "Subru Krishnan"  su...@apache.org>> wrote:
> >
> >Folks,
> >
> >There was a merge commit accidentally pushed to trunk, you can
> find the
> >details in the mail thread [1].
> >
> >I have raised an INFRA ticket [2] to reset/force push to clean up
> trunk.
> >
> >Can we have a quick vote for INFRA sign-off to proceed as this is
> blocking
> >all commits?
> >
> >Thanks,
> >Subru
> >
> >[1]
> >
> 
http://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201807.mbox/%3CCAHqguubKBqwfUMwhtJuS

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

[Arpit Agarwal]

+1 from me.

Also +1 to reopen trunk for all commits.


On 7/6/18, 11:12 AM, "Sunil G"  wrote:

I just checked.  YARN-7556 and YARN-7451 can be cherry-picked.
I cherry-picked in my local and compiled. Things are good.

I can push this now  which will restore trunk to its original.
I can do this if there are no objection.

- Sunil

On Fri, Jul 6, 2018 at 11:10 AM Arpit Agarwal 
wrote:

> afaict YARN-8435 is still in trunk. YARN-7556 and YARN-7451 are not.
>
>
> From: Giovanni Matteo Fumarola 
> Date: Friday, July 6, 2018 at 10:59 AM
> To: Vinod Kumar Vavilapalli 
> Cc: Anu Engineer , Arpit Agarwal <
> aagar...@hortonworks.com>, "su...@apache.org" , "
> yarn-...@hadoop.apache.org" , "
> hdfs-...@hadoop.apache.org" , "
> common-dev@hadoop.apache.org" , "
> mapreduce-...@hadoop.apache.org" 
> Subject: Re: [VOTE] reset/force push to clean up inadvertent merge commit
> pushed to trunk
>
> Everything seems ok except the 3 commits: YARN-8435, YARN-7556, YARN-7451
> are not anymore in trunk due to the revert.
>
> Haibo/Robert if you can recommit your patches I will commit mine
> subsequently to preserve the original order.
>
> (My apology for the mess I did with the merge commit)
>
> On Fri, Jul 6, 2018 at 10:42 AM, Vinod Kumar Vavilapalli <
> vino...@apache.org> wrote:
> I will add that the branch also successfully compiles.
>
> Let's just move forward as is, unblock commits and just fix things if
> anything is broken.
>
> +Vinod
>
> > On Jul 6, 2018, at 10:30 AM, Anu Engineer  > wrote:
> >
> > Hi All,
> >
> > [ Thanks to Arpit for working offline and verifying that branch is
> indeed good.]
> >
> > I want to summarize what I know of this issue and also solicit other
> points of view.
> >
> > We reverted the commit(c163d1797) from the branch, as soon as we noticed
> it. That is, we have made no other commits after the merge commit.
> >
> > We used the following command to revert
> > git revert -c c163d1797ade0f47d35b4a44381b8ef1dfec5b60 -m 1
> >
> > Giovanni's branch had three commits + merge, The JIRAs he had were
> YARN-7451, YARN-7556, YARN-8435.
> >
> > The issue seems to be the revert of merge has some diffs. I am not a
> YARN developer, so the only problem is to look at the revert and see if
> there were any spurious edits in Giovanni's original commit + merge.
> > If there are none, we don't need a reset/force push.  But if we find an
> issue I am more than willing to go the force commit route.
> >
> > The revert takes the trunk back to the point of the first commit from
> Giovanni which is YARN-8435. His branch was also rewriting the order of
> commits which we have lost due to the revert.
> >
> > Based on what I know so far, I am -1 on the force push.
> >
> > In other words, I am trying to understand why we need the force push. I
> have left a similar comment in JIRA (
> https://issues.apache.org/jira/browse/INFRA-16727) too.
> >
> >
> > Thanks
> > Anu
> >
> >
> > On 7/6/18, 10:24 AM, "Arpit Agarwal"  aagar...@hortonworks.com>> wrote:
> >
> >-1 for the force push. Nothing is broken in trunk. The history looks
> ugly for two commits and we can live with it.
> >
> >The revert restored the branch to Giovanni's intent. i.e. only
> YARN-8435 is applied. Verified there is no delta between hashes 0d9804d 
and
> 39ad989 (HEAD).
> >
> >39ad989 2018-07-05 aengineer@ o {apache/trunk} Revert "Merge branch
> 't...
> >c163d17 2018-07-05 gifuma@apa M─┐ Merge branch 'trunk' of
> https://git-...
> >99febe7 2018-07-05 rkanter@ap │ o YARN-7451. Add missing tests to
> veri...
> >1726247 2018-07-05 haibochen@ │ o YARN-7556. Fair scheduler
> configurat...
> >0d9804d 2018-07-05 gifuma@apa o │ YARN-8435. Fix NPE when the same
> cli...
> >71df8c2 2018-07-05 nanda@apac o─┘ HDDS-212. Introduce
> NodeStateManager...
> >
> >Regards,
> >Arpit
> >
> >
> >On 7/5/18, 2:37 PM, "Subru Krishnan"  su...@apache.org>> wrote:
> >
> >Folks,
> >
> >There was a merge commit accidentally pushed to trunk, you can
> find the
> >details in the mail thread [1].
> >
> >I have raised an INFRA ticket [2] to reset/force push to clean up
> trunk.
> >
> >Can we have a quick vote for INFRA sign-off to proceed as this is
> blocking
> >all commits?
> >
> >Thanks,
> >Subru
> >
> >[1]
> >
> 
http://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201807.mbox/%3CCAHqguubKBqwfUMw

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

[Vinod Kumar Vavilapalli]

+1

Thanks
+Vinod

> On Jul 6, 2018, at 11:12 AM, Sunil G  wrote:
> 
> I just checked.  YARN-7556 and YARN-7451 can be cherry-picked.
> I cherry-picked in my local and compiled. Things are good.
> 
> I can push this now  which will restore trunk to its original.
> I can do this if there are no objection.
> 
> - Sunil
> 
> On Fri, Jul 6, 2018 at 11:10 AM Arpit Agarwal  >
> wrote:
> 
>> afaict YARN-8435 is still in trunk. YARN-7556 and YARN-7451 are not.
>> 
>> 
>> From: Giovanni Matteo Fumarola 
>> Date: Friday, July 6, 2018 at 10:59 AM
>> To: Vinod Kumar Vavilapalli 
>> Cc: Anu Engineer , Arpit Agarwal <
>> aagar...@hortonworks.com>, "su...@apache.org" , "
>> yarn-...@hadoop.apache.org" , "
>> hdfs-...@hadoop.apache.org" , "
>> common-dev@hadoop.apache.org" , "
>> mapreduce-...@hadoop.apache.org" 
>> Subject: Re: [VOTE] reset/force push to clean up inadvertent merge commit
>> pushed to trunk
>> 
>> Everything seems ok except the 3 commits: YARN-8435, YARN-7556, YARN-7451
>> are not anymore in trunk due to the revert.
>> 
>> Haibo/Robert if you can recommit your patches I will commit mine
>> subsequently to preserve the original order.
>> 
>> (My apology for the mess I did with the merge commit)
>> 
>> On Fri, Jul 6, 2018 at 10:42 AM, Vinod Kumar Vavilapalli <
>> vino...@apache.org > >> wrote:
>> I will add that the branch also successfully compiles.
>> 
>> Let's just move forward as is, unblock commits and just fix things if
>> anything is broken.
>> 
>> +Vinod
>> 
>>> On Jul 6, 2018, at 10:30 AM, Anu Engineer >> 
>> >> wrote:
>>> 
>>> Hi All,
>>> 
>>> [ Thanks to Arpit for working offline and verifying that branch is
>> indeed good.]
>>> 
>>> I want to summarize what I know of this issue and also solicit other
>> points of view.
>>> 
>>> We reverted the commit(c163d1797) from the branch, as soon as we noticed
>> it. That is, we have made no other commits after the merge commit.
>>> 
>>> We used the following command to revert
>>> git revert -c c163d1797ade0f47d35b4a44381b8ef1dfec5b60 -m 1
>>> 
>>> Giovanni's branch had three commits + merge, The JIRAs he had were
>> YARN-7451, YARN-7556, YARN-8435.
>>> 
>>> The issue seems to be the revert of merge has some diffs. I am not a
>> YARN developer, so the only problem is to look at the revert and see if
>> there were any spurious edits in Giovanni's original commit + merge.
>>> If there are none, we don't need a reset/force push.  But if we find an
>> issue I am more than willing to go the force commit route.
>>> 
>>> The revert takes the trunk back to the point of the first commit from
>> Giovanni which is YARN-8435. His branch was also rewriting the order of
>> commits which we have lost due to the revert.
>>> 
>>> Based on what I know so far, I am -1 on the force push.
>>> 
>>> In other words, I am trying to understand why we need the force push. I
>> have left a similar comment in JIRA (
>> https://issues.apache.org/jira/browse/INFRA-16727 
>> ) too.
>>> 
>>> 
>>> Thanks
>>> Anu
>>> 
>>> 
>>> On 7/6/18, 10:24 AM, "Arpit Agarwal" >> > aagar...@hortonworks.com >> wrote:
>>> 
>>>   -1 for the force push. Nothing is broken in trunk. The history looks
>> ugly for two commits and we can live with it.
>>> 
>>>   The revert restored the branch to Giovanni's intent. i.e. only
>> YARN-8435 is applied. Verified there is no delta between hashes 0d9804d and
>> 39ad989 (HEAD).
>>> 
>>>   39ad989 2018-07-05 aengineer@ o {apache/trunk} Revert "Merge branch
>> 't...
>>>   c163d17 2018-07-05 gifuma@apa M─┐ Merge branch 'trunk' of
>> https://git- ...
>>>   99febe7 2018-07-05 rkanter@ap │ o YARN-7451. Add missing tests to
>> veri...
>>>   1726247 2018-07-05 haibochen@ │ o YARN-7556. Fair scheduler
>> configurat...
>>>   0d9804d 2018-07-05 gifuma@apa o │ YARN-8435. Fix NPE when the same
>> cli...
>>>   71df8c2 2018-07-05 nanda@apac o─┘ HDDS-212. Introduce
>> NodeStateManager...
>>> 
>>>   Regards,
>>>   Arpit
>>> 
>>> 
>>>   On 7/5/18, 2:37 PM, "Subru Krishnan" >> > su...@apache.org >> wrote:
>>> 
>>>   Folks,
>>> 
>>>   There was a merge commit accidentally pushed to trunk, you can
>> find the
>>>   details in the mail thread [1].
>>> 
>>>   I have raised an INFRA ticket [2] to reset/force push to clean up
>> trunk.
>>> 
>>>   Can we have a quick vote for INFRA sign-off to proceed as this is
>> blocking
>>>   all commits?
>>> 
>>>   Thanks,
>>>   Subru
>>> 
>>>   [1]
>>> 
>> http://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201807.mbox/%3CCAHqguubKBqwfUMwhtJuSD7X1Bgfro_P6FV%2BhhFhMMYRaxFsF9Q%40mail.gmail.com%3E
>>  
>> 

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

[Sunil G]

I just checked.  YARN-7556 and YARN-7451 can be cherry-picked.
I cherry-picked in my local and compiled. Things are good.

I can push this now  which will restore trunk to its original.
I can do this if there are no objection.

- Sunil

On Fri, Jul 6, 2018 at 11:10 AM Arpit Agarwal 
wrote:

> afaict YARN-8435 is still in trunk. YARN-7556 and YARN-7451 are not.
>
>
> From: Giovanni Matteo Fumarola 
> Date: Friday, July 6, 2018 at 10:59 AM
> To: Vinod Kumar Vavilapalli 
> Cc: Anu Engineer , Arpit Agarwal <
> aagar...@hortonworks.com>, "su...@apache.org" , "
> yarn-...@hadoop.apache.org" , "
> hdfs-...@hadoop.apache.org" , "
> common-dev@hadoop.apache.org" , "
> mapreduce-...@hadoop.apache.org" 
> Subject: Re: [VOTE] reset/force push to clean up inadvertent merge commit
> pushed to trunk
>
> Everything seems ok except the 3 commits: YARN-8435, YARN-7556, YARN-7451
> are not anymore in trunk due to the revert.
>
> Haibo/Robert if you can recommit your patches I will commit mine
> subsequently to preserve the original order.
>
> (My apology for the mess I did with the merge commit)
>
> On Fri, Jul 6, 2018 at 10:42 AM, Vinod Kumar Vavilapalli <
> vino...@apache.org> wrote:
> I will add that the branch also successfully compiles.
>
> Let's just move forward as is, unblock commits and just fix things if
> anything is broken.
>
> +Vinod
>
> > On Jul 6, 2018, at 10:30 AM, Anu Engineer  > wrote:
> >
> > Hi All,
> >
> > [ Thanks to Arpit for working offline and verifying that branch is
> indeed good.]
> >
> > I want to summarize what I know of this issue and also solicit other
> points of view.
> >
> > We reverted the commit(c163d1797) from the branch, as soon as we noticed
> it. That is, we have made no other commits after the merge commit.
> >
> > We used the following command to revert
> > git revert -c c163d1797ade0f47d35b4a44381b8ef1dfec5b60 -m 1
> >
> > Giovanni's branch had three commits + merge, The JIRAs he had were
> YARN-7451, YARN-7556, YARN-8435.
> >
> > The issue seems to be the revert of merge has some diffs. I am not a
> YARN developer, so the only problem is to look at the revert and see if
> there were any spurious edits in Giovanni's original commit + merge.
> > If there are none, we don't need a reset/force push.  But if we find an
> issue I am more than willing to go the force commit route.
> >
> > The revert takes the trunk back to the point of the first commit from
> Giovanni which is YARN-8435. His branch was also rewriting the order of
> commits which we have lost due to the revert.
> >
> > Based on what I know so far, I am -1 on the force push.
> >
> > In other words, I am trying to understand why we need the force push. I
> have left a similar comment in JIRA (
> https://issues.apache.org/jira/browse/INFRA-16727) too.
> >
> >
> > Thanks
> > Anu
> >
> >
> > On 7/6/18, 10:24 AM, "Arpit Agarwal"  aagar...@hortonworks.com>> wrote:
> >
> >-1 for the force push. Nothing is broken in trunk. The history looks
> ugly for two commits and we can live with it.
> >
> >The revert restored the branch to Giovanni's intent. i.e. only
> YARN-8435 is applied. Verified there is no delta between hashes 0d9804d and
> 39ad989 (HEAD).
> >
> >39ad989 2018-07-05 aengineer@ o {apache/trunk} Revert "Merge branch
> 't...
> >c163d17 2018-07-05 gifuma@apa M─┐ Merge branch 'trunk' of
> https://git-...
> >99febe7 2018-07-05 rkanter@ap │ o YARN-7451. Add missing tests to
> veri...
> >1726247 2018-07-05 haibochen@ │ o YARN-7556. Fair scheduler
> configurat...
> >0d9804d 2018-07-05 gifuma@apa o │ YARN-8435. Fix NPE when the same
> cli...
> >71df8c2 2018-07-05 nanda@apac o─┘ HDDS-212. Introduce
> NodeStateManager...
> >
> >Regards,
> >Arpit
> >
> >
> >On 7/5/18, 2:37 PM, "Subru Krishnan"  su...@apache.org>> wrote:
> >
> >Folks,
> >
> >There was a merge commit accidentally pushed to trunk, you can
> find the
> >details in the mail thread [1].
> >
> >I have raised an INFRA ticket [2] to reset/force push to clean up
> trunk.
> >
> >Can we have a quick vote for INFRA sign-off to proceed as this is
> blocking
> >all commits?
> >
> >Thanks,
> >Subru
> >
> >[1]
> >
> http://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201807.mbox/%3CCAHqguubKBqwfUMwhtJuSD7X1Bgfro_P6FV%2BhhFhMMYRaxFsF9Q%40mail.gmail.com%3E
> >[2] https://issues.apache.org/jira/browse/INFRA-16727
> >
> >
> >
> >-
> >To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
> 
> >For additional commands, e-mail: common-dev-h...@hadoop.apache.org
> 
> >
> >
> >
> > -
> > To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org common-de

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

[Arpit Agarwal]

afaict YARN-8435 is still in trunk. YARN-7556 and YARN-7451 are not.


From: Giovanni Matteo Fumarola 
Date: Friday, July 6, 2018 at 10:59 AM
To: Vinod Kumar Vavilapalli 
Cc: Anu Engineer , Arpit Agarwal 
, "su...@apache.org" , 
"yarn-...@hadoop.apache.org" , 
"hdfs-...@hadoop.apache.org" , 
"common-dev@hadoop.apache.org" , 
"mapreduce-...@hadoop.apache.org" 
Subject: Re: [VOTE] reset/force push to clean up inadvertent merge commit 
pushed to trunk

Everything seems ok except the 3 commits: YARN-8435, YARN-7556, YARN-7451 are 
not anymore in trunk due to the revert.

Haibo/Robert if you can recommit your patches I will commit mine subsequently 
to preserve the original order.

(My apology for the mess I did with the merge commit)

On Fri, Jul 6, 2018 at 10:42 AM, Vinod Kumar Vavilapalli 
mailto:vino...@apache.org>> wrote:
I will add that the branch also successfully compiles.

Let's just move forward as is, unblock commits and just fix things if anything 
is broken.

+Vinod

> On Jul 6, 2018, at 10:30 AM, Anu Engineer 
> mailto:aengin...@hortonworks.com>> wrote:
>
> Hi All,
>
> [ Thanks to Arpit for working offline and verifying that branch is indeed 
> good.]
>
> I want to summarize what I know of this issue and also solicit other points 
> of view.
>
> We reverted the commit(c163d1797) from the branch, as soon as we noticed it. 
> That is, we have made no other commits after the merge commit.
>
> We used the following command to revert
> git revert -c c163d1797ade0f47d35b4a44381b8ef1dfec5b60 -m 1
>
> Giovanni's branch had three commits + merge, The JIRAs he had were YARN-7451, 
> YARN-7556, YARN-8435.
>
> The issue seems to be the revert of merge has some diffs. I am not a YARN 
> developer, so the only problem is to look at the revert and see if there were 
> any spurious edits in Giovanni's original commit + merge.
> If there are none, we don't need a reset/force push.  But if we find an issue 
> I am more than willing to go the force commit route.
>
> The revert takes the trunk back to the point of the first commit from 
> Giovanni which is YARN-8435. His branch was also rewriting the order of 
> commits which we have lost due to the revert.
>
> Based on what I know so far, I am -1 on the force push.
>
> In other words, I am trying to understand why we need the force push. I have 
> left a similar comment in JIRA 
> (https://issues.apache.org/jira/browse/INFRA-16727) too.
>
>
> Thanks
> Anu
>
>
> On 7/6/18, 10:24 AM, "Arpit Agarwal" 
> mailto:aagar...@hortonworks.com>> wrote:
>
>-1 for the force push. Nothing is broken in trunk. The history looks ugly 
> for two commits and we can live with it.
>
>The revert restored the branch to Giovanni's intent. i.e. only YARN-8435 
> is applied. Verified there is no delta between hashes 0d9804d and 39ad989 
> (HEAD).
>
>39ad989 2018-07-05 aengineer@ o {apache/trunk} Revert "Merge branch 't...
>c163d17 2018-07-05 gifuma@apa M─┐ Merge branch 'trunk' of https://git-...
>99febe7 2018-07-05 rkanter@ap │ o YARN-7451. Add missing tests to veri...
>1726247 2018-07-05 haibochen@ │ o YARN-7556. Fair scheduler configurat...
>0d9804d 2018-07-05 gifuma@apa o │ YARN-8435. Fix NPE when the same cli...
>71df8c2 2018-07-05 nanda@apac o─┘ HDDS-212. Introduce NodeStateManager...
>
>Regards,
>Arpit
>
>
>On 7/5/18, 2:37 PM, "Subru Krishnan" 
> mailto:su...@apache.org>> wrote:
>
>Folks,
>
>There was a merge commit accidentally pushed to trunk, you can find the
>details in the mail thread [1].
>
>I have raised an INFRA ticket [2] to reset/force push to clean up 
> trunk.
>
>Can we have a quick vote for INFRA sign-off to proceed as this is 
> blocking
>all commits?
>
>Thanks,
>Subru
>
>[1]
>
> http://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201807.mbox/%3CCAHqguubKBqwfUMwhtJuSD7X1Bgfro_P6FV%2BhhFhMMYRaxFsF9Q%40mail.gmail.com%3E
>[2] https://issues.apache.org/jira/browse/INFRA-16727
>
>
>
>-
>To unsubscribe, e-mail: 
> common-dev-unsubscr...@hadoop.apache.org
>For additional commands, e-mail: 
> common-dev-h...@hadoop.apache.org
>
>
>
> -
> To unsubscribe, e-mail: 
> common-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: 
> common-dev-h...@hadoop.apache.org

-
To unsubscribe, e-mail: 
yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: 
yarn-dev-h...@hadoop.apache.org

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

[Sunil G]

Yes these patches can be cherry-picked.

git cherry-pick 17262470246232d0f0651d627a4961e55b1efe6a
git cherry-pick 99febe7fd50c31c0f5dd40fa7f376f2c1f64f8c3

I will try this now and will compile.

- Sunil


On Fri, Jul 6, 2018 at 10:59 AM Giovanni Matteo Fumarola <
giovanni.fumar...@gmail.com> wrote:

> Everything seems ok except the 3 commits: YARN-8435, YARN-7556, YARN-7451
> are not anymore in trunk due to the revert.
>
> Haibo/Robert if you can recommit your patches I will commit mine
> subsequently to preserve the original order.
>
> (My apology for the mess I did with the merge commit)
>
> On Fri, Jul 6, 2018 at 10:42 AM, Vinod Kumar Vavilapalli <
> vino...@apache.org
> > wrote:
>
> > I will add that the branch also successfully compiles.
> >
> > Let's just move forward as is, unblock commits and just fix things if
> > anything is broken.
> >
> > +Vinod
> >
> > > On Jul 6, 2018, at 10:30 AM, Anu Engineer 
> > wrote:
> > >
> > > Hi All,
> > >
> > > [ Thanks to Arpit for working offline and verifying that branch is
> > indeed good.]
> > >
> > > I want to summarize what I know of this issue and also solicit other
> > points of view.
> > >
> > > We reverted the commit(c163d1797) from the branch, as soon as we
> noticed
> > it. That is, we have made no other commits after the merge commit.
> > >
> > > We used the following command to revert
> > > git revert -c c163d1797ade0f47d35b4a44381b8ef1dfec5b60 -m 1
> > >
> > > Giovanni's branch had three commits + merge, The JIRAs he had were
> > YARN-7451, YARN-7556, YARN-8435.
> > >
> > > The issue seems to be the revert of merge has some diffs. I am not a
> > YARN developer, so the only problem is to look at the revert and see if
> > there were any spurious edits in Giovanni's original commit + merge.
> > > If there are none, we don't need a reset/force push.  But if we find an
> > issue I am more than willing to go the force commit route.
> > >
> > > The revert takes the trunk back to the point of the first commit from
> > Giovanni which is YARN-8435. His branch was also rewriting the order of
> > commits which we have lost due to the revert.
> > >
> > > Based on what I know so far, I am -1 on the force push.
> > >
> > > In other words, I am trying to understand why we need the force push. I
> > have left a similar comment in JIRA (https://issues.apache.org/
> > jira/browse/INFRA-16727) too.
> > >
> > >
> > > Thanks
> > > Anu
> > >
> > >
> > > On 7/6/18, 10:24 AM, "Arpit Agarwal"  wrote:
> > >
> > >-1 for the force push. Nothing is broken in trunk. The history looks
> > ugly for two commits and we can live with it.
> > >
> > >The revert restored the branch to Giovanni's intent. i.e. only
> > YARN-8435 is applied. Verified there is no delta between hashes 0d9804d
> and
> > 39ad989 (HEAD).
> > >
> > >39ad989 2018-07-05 aengineer@ o {apache/trunk} Revert "Merge branch
> > 't...
> > >c163d17 2018-07-05 gifuma@apa M─┐ Merge branch 'trunk' of
> > https://git-...
> > >99febe7 2018-07-05 rkanter@ap │ o YARN-7451. Add missing tests to
> > veri...
> > >1726247 2018-07-05 haibochen@ │ o YARN-7556. Fair scheduler
> > configurat...
> > >0d9804d 2018-07-05 gifuma@apa o │ YARN-8435. Fix NPE when the same
> > cli...
> > >71df8c2 2018-07-05 nanda@apac o─┘ HDDS-212. Introduce
> > NodeStateManager...
> > >
> > >Regards,
> > >Arpit
> > >
> > >
> > >On 7/5/18, 2:37 PM, "Subru Krishnan"  wrote:
> > >
> > >Folks,
> > >
> > >There was a merge commit accidentally pushed to trunk, you can
> > find the
> > >details in the mail thread [1].
> > >
> > >I have raised an INFRA ticket [2] to reset/force push to clean
> up
> > trunk.
> > >
> > >Can we have a quick vote for INFRA sign-off to proceed as this
> is
> > blocking
> > >all commits?
> > >
> > >Thanks,
> > >Subru
> > >
> > >[1]
> > >http://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/
> > 201807.mbox/%3CCAHqguubKBqwfUMwhtJuSD7X1Bgfro_P6FV%2BhhFhMMYRaxFsF9Q%
> > 40mail.gmail.com%3E
> > >[2] https://issues.apache.org/jira/browse/INFRA-16727
> > >
> > >
> > >
> > >
> -
> > >To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
> > >For additional commands, e-mail: common-dev-h...@hadoop.apache.org
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
> > > For additional commands, e-mail: common-dev-h...@hadoop.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
> > For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
> >
> >
>

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

[Giovanni Matteo Fumarola]

Everything seems ok except the 3 commits: YARN-8435, YARN-7556, YARN-7451
are not anymore in trunk due to the revert.

Haibo/Robert if you can recommit your patches I will commit mine
subsequently to preserve the original order.

(My apology for the mess I did with the merge commit)

On Fri, Jul 6, 2018 at 10:42 AM, Vinod Kumar Vavilapalli  wrote:

> I will add that the branch also successfully compiles.
>
> Let's just move forward as is, unblock commits and just fix things if
> anything is broken.
>
> +Vinod
>
> > On Jul 6, 2018, at 10:30 AM, Anu Engineer 
> wrote:
> >
> > Hi All,
> >
> > [ Thanks to Arpit for working offline and verifying that branch is
> indeed good.]
> >
> > I want to summarize what I know of this issue and also solicit other
> points of view.
> >
> > We reverted the commit(c163d1797) from the branch, as soon as we noticed
> it. That is, we have made no other commits after the merge commit.
> >
> > We used the following command to revert
> > git revert -c c163d1797ade0f47d35b4a44381b8ef1dfec5b60 -m 1
> >
> > Giovanni's branch had three commits + merge, The JIRAs he had were
> YARN-7451, YARN-7556, YARN-8435.
> >
> > The issue seems to be the revert of merge has some diffs. I am not a
> YARN developer, so the only problem is to look at the revert and see if
> there were any spurious edits in Giovanni's original commit + merge.
> > If there are none, we don't need a reset/force push.  But if we find an
> issue I am more than willing to go the force commit route.
> >
> > The revert takes the trunk back to the point of the first commit from
> Giovanni which is YARN-8435. His branch was also rewriting the order of
> commits which we have lost due to the revert.
> >
> > Based on what I know so far, I am -1 on the force push.
> >
> > In other words, I am trying to understand why we need the force push. I
> have left a similar comment in JIRA (https://issues.apache.org/
> jira/browse/INFRA-16727) too.
> >
> >
> > Thanks
> > Anu
> >
> >
> > On 7/6/18, 10:24 AM, "Arpit Agarwal"  wrote:
> >
> >-1 for the force push. Nothing is broken in trunk. The history looks
> ugly for two commits and we can live with it.
> >
> >The revert restored the branch to Giovanni's intent. i.e. only
> YARN-8435 is applied. Verified there is no delta between hashes 0d9804d and
> 39ad989 (HEAD).
> >
> >39ad989 2018-07-05 aengineer@ o {apache/trunk} Revert "Merge branch
> 't...
> >c163d17 2018-07-05 gifuma@apa M─┐ Merge branch 'trunk' of
> https://git-...
> >99febe7 2018-07-05 rkanter@ap │ o YARN-7451. Add missing tests to
> veri...
> >1726247 2018-07-05 haibochen@ │ o YARN-7556. Fair scheduler
> configurat...
> >0d9804d 2018-07-05 gifuma@apa o │ YARN-8435. Fix NPE when the same
> cli...
> >71df8c2 2018-07-05 nanda@apac o─┘ HDDS-212. Introduce
> NodeStateManager...
> >
> >Regards,
> >Arpit
> >
> >
> >On 7/5/18, 2:37 PM, "Subru Krishnan"  wrote:
> >
> >Folks,
> >
> >There was a merge commit accidentally pushed to trunk, you can
> find the
> >details in the mail thread [1].
> >
> >I have raised an INFRA ticket [2] to reset/force push to clean up
> trunk.
> >
> >Can we have a quick vote for INFRA sign-off to proceed as this is
> blocking
> >all commits?
> >
> >Thanks,
> >Subru
> >
> >[1]
> >http://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/
> 201807.mbox/%3CCAHqguubKBqwfUMwhtJuSD7X1Bgfro_P6FV%2BhhFhMMYRaxFsF9Q%
> 40mail.gmail.com%3E
> >[2] https://issues.apache.org/jira/browse/INFRA-16727
> >
> >
> >
> >-
> >To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
> >For additional commands, e-mail: common-dev-h...@hadoop.apache.org
> >
> >
> >
> > -
> > To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
> > For additional commands, e-mail: common-dev-h...@hadoop.apache.org
>
>
> -
> To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
>
>

Apache Hadoop qbt Report: trunk+JDK8 on Linux/x86

[Apache Jenkins Server]

For more details, see 
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/

[Jul 1, 2018 11:41:46 AM] (nanda) HADOOP-15574: Suppress build error if there 
are no docs after excluding




-1 overall


The following subsystems voted -1:
asflicense findbugs pathlen unit xml


The following subsystems voted -1 but
were configured to be filtered/ignored:
cc checkstyle javac javadoc pylint shellcheck shelldocs whitespace


The following subsystems are considered long running:
(runtime bigger than 1h  0m  0s)
unit


Specific tests:

Failed CTEST tests :

   test_test_libhdfs_threaded_hdfs_static 
   test_libhdfs_threaded_hdfspp_test_shim_static 

Failed junit tests :

   hadoop.hdfs.web.TestWebHdfsTimeouts 
   hadoop.hdfs.client.impl.TestBlockReaderLocal 
   hadoop.hdfs.server.blockmanagement.TestUnderReplicatedBlocks 
   hadoop.yarn.server.resourcemanager.applicationsmanager.TestAMRestart 
   hadoop.yarn.client.api.impl.TestAMRMClient 
   
hadoop.yarn.server.timelineservice.reader.TestTimelineReaderWebServicesHBaseStorage
 
   
hadoop.yarn.server.timelineservice.storage.flow.TestHBaseStorageFlowRunCompaction
 
   hadoop.yarn.server.timelineservice.storage.flow.TestHBaseStorageFlowRun 
   
hadoop.yarn.server.timelineservice.storage.TestHBaseTimelineStorageDomain 
   
hadoop.yarn.server.timelineservice.storage.TestHBaseTimelineStorageEntities 
   
hadoop.yarn.server.timelineservice.storage.TestHBaseTimelineStorageSchema 
   
hadoop.yarn.server.timelineservice.storage.flow.TestHBaseStorageFlowActivity 
   hadoop.yarn.server.timelineservice.storage.TestHBaseTimelineStorageApps 
   hadoop.yarn.applications.distributedshell.TestDistributedShell 
   hadoop.mapred.TestMRTimelineEventHandling 
  

   cc:

   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/diff-compile-cc-root.txt
  [4.0K]

   javac:

   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/diff-compile-javac-root.txt
  [360K]

   checkstyle:

   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/diff-checkstyle-root.txt
  [4.0K]

   pathlen:

   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/pathlen.txt
  [12K]

   pylint:

   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/diff-patch-pylint.txt
  [24K]

   shellcheck:

   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/diff-patch-shellcheck.txt
  [20K]

   shelldocs:

   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/diff-patch-shelldocs.txt
  [16K]

   whitespace:

   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/whitespace-eol.txt
  [9.4M]
   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/whitespace-tabs.txt
  [1.1M]

   xml:

   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/xml.txt
  [4.0K]

   findbugs:

   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/branch-findbugs-hadoop-hdds_client.txt
  [68K]
   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/branch-findbugs-hadoop-hdds_container-service.txt
  [52K]
   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/branch-findbugs-hadoop-hdds_server-scm.txt
  [64K]
   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/branch-findbugs-hadoop-hdds_tools.txt
  [16K]
   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/branch-findbugs-hadoop-ozone_client.txt
  [8.0K]
   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/branch-findbugs-hadoop-ozone_common.txt
  [24K]
   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/branch-findbugs-hadoop-ozone_objectstore-service.txt
  [8.0K]
   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/branch-findbugs-hadoop-ozone_ozone-manager.txt
  [4.0K]
   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/branch-findbugs-hadoop-ozone_ozonefs.txt
  [8.0K]
   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/branch-findbugs-hadoop-ozone_tools.txt
  [4.0K]

   javadoc:

   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/diff-javadoc-javadoc-root.txt
  [760K]

   CTEST:

   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/patch-hadoop-hdfs-project_hadoop-hdfs-native-client-ctest.txt
  [116K]

   unit:

   
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/829/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
  [336K]
  

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

[Vinod Kumar Vavilapalli]

I will add that the branch also successfully compiles.

Let's just move forward as is, unblock commits and just fix things if anything 
is broken.

+Vinod

> On Jul 6, 2018, at 10:30 AM, Anu Engineer  wrote:
> 
> Hi All,
> 
> [ Thanks to Arpit for working offline and verifying that branch is indeed 
> good.]
> 
> I want to summarize what I know of this issue and also solicit other points 
> of view.
> 
> We reverted the commit(c163d1797) from the branch, as soon as we noticed it. 
> That is, we have made no other commits after the merge commit.
> 
> We used the following command to revert 
> git revert -c c163d1797ade0f47d35b4a44381b8ef1dfec5b60 -m 1
> 
> Giovanni's branch had three commits + merge, The JIRAs he had were YARN-7451, 
> YARN-7556, YARN-8435.
> 
> The issue seems to be the revert of merge has some diffs. I am not a YARN 
> developer, so the only problem is to look at the revert and see if there were 
> any spurious edits in Giovanni's original commit + merge. 
> If there are none, we don't need a reset/force push.  But if we find an issue 
> I am more than willing to go the force commit route.
> 
> The revert takes the trunk back to the point of the first commit from 
> Giovanni which is YARN-8435. His branch was also rewriting the order of 
> commits which we have lost due to the revert.
> 
> Based on what I know so far, I am -1 on the force push.
> 
> In other words, I am trying to understand why we need the force push. I have 
> left a similar comment in JIRA 
> (https://issues.apache.org/jira/browse/INFRA-16727) too.
> 
> 
> Thanks
> Anu
> 
> 
> On 7/6/18, 10:24 AM, "Arpit Agarwal"  wrote:
> 
>-1 for the force push. Nothing is broken in trunk. The history looks ugly 
> for two commits and we can live with it.
> 
>The revert restored the branch to Giovanni's intent. i.e. only YARN-8435 
> is applied. Verified there is no delta between hashes 0d9804d and 39ad989 
> (HEAD).
> 
>39ad989 2018-07-05 aengineer@ o {apache/trunk} Revert "Merge branch 't...
>c163d17 2018-07-05 gifuma@apa M─┐ Merge branch 'trunk' of https://git-...
>99febe7 2018-07-05 rkanter@ap │ o YARN-7451. Add missing tests to veri...
>1726247 2018-07-05 haibochen@ │ o YARN-7556. Fair scheduler configurat...
>0d9804d 2018-07-05 gifuma@apa o │ YARN-8435. Fix NPE when the same cli...
>71df8c2 2018-07-05 nanda@apac o─┘ HDDS-212. Introduce NodeStateManager...
> 
>Regards,
>Arpit
> 
> 
>On 7/5/18, 2:37 PM, "Subru Krishnan"  wrote:
> 
>Folks,
> 
>There was a merge commit accidentally pushed to trunk, you can find the
>details in the mail thread [1].
> 
>I have raised an INFRA ticket [2] to reset/force push to clean up 
> trunk.
> 
>Can we have a quick vote for INFRA sign-off to proceed as this is 
> blocking
>all commits?
> 
>Thanks,
>Subru
> 
>[1]
>
> http://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201807.mbox/%3CCAHqguubKBqwfUMwhtJuSD7X1Bgfro_P6FV%2BhhFhMMYRaxFsF9Q%40mail.gmail.com%3E
>[2] https://issues.apache.org/jira/browse/INFRA-16727
> 
> 
> 
>-
>To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
>For additional commands, e-mail: common-dev-h...@hadoop.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: common-dev-h...@hadoop.apache.org


-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

[Anu Engineer]

Hi All,

[ Thanks to Arpit for working offline and verifying that branch is indeed good.]

I want to summarize what I know of this issue and also solicit other points of 
view.

We reverted the commit(c163d1797) from the branch, as soon as we noticed it. 
That is, we have made no other commits after the merge commit.

We used the following command to revert 
git revert -c c163d1797ade0f47d35b4a44381b8ef1dfec5b60 -m 1

Giovanni's branch had three commits + merge, The JIRAs he had were YARN-7451, 
YARN-7556, YARN-8435.

The issue seems to be the revert of merge has some diffs. I am not a YARN 
developer, so the only problem is to look at the revert and see if there were 
any spurious edits in Giovanni's original commit + merge. 
If there are none, we don't need a reset/force push.  But if we find an issue I 
am more than willing to go the force commit route.

The revert takes the trunk back to the point of the first commit from Giovanni 
which is YARN-8435. His branch was also rewriting the order of commits which we 
have lost due to the revert.
 
Based on what I know so far, I am -1 on the force push.

In other words, I am trying to understand why we need the force push. I have 
left a similar comment in JIRA 
(https://issues.apache.org/jira/browse/INFRA-16727) too.


Thanks
Anu


On 7/6/18, 10:24 AM, "Arpit Agarwal"  wrote:

-1 for the force push. Nothing is broken in trunk. The history looks ugly 
for two commits and we can live with it.

The revert restored the branch to Giovanni's intent. i.e. only YARN-8435 is 
applied. Verified there is no delta between hashes 0d9804d and 39ad989 (HEAD).

39ad989 2018-07-05 aengineer@ o {apache/trunk} Revert "Merge branch 't...
c163d17 2018-07-05 gifuma@apa M─┐ Merge branch 'trunk' of https://git-...
99febe7 2018-07-05 rkanter@ap │ o YARN-7451. Add missing tests to veri...
1726247 2018-07-05 haibochen@ │ o YARN-7556. Fair scheduler configurat...
0d9804d 2018-07-05 gifuma@apa o │ YARN-8435. Fix NPE when the same cli...
71df8c2 2018-07-05 nanda@apac o─┘ HDDS-212. Introduce NodeStateManager...

Regards,
Arpit


On 7/5/18, 2:37 PM, "Subru Krishnan"  wrote:

Folks,

There was a merge commit accidentally pushed to trunk, you can find the
details in the mail thread [1].

I have raised an INFRA ticket [2] to reset/force push to clean up trunk.

Can we have a quick vote for INFRA sign-off to proceed as this is 
blocking
all commits?

Thanks,
Subru

[1]

http://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201807.mbox/%3CCAHqguubKBqwfUMwhtJuSD7X1Bgfro_P6FV%2BhhFhMMYRaxFsF9Q%40mail.gmail.com%3E
[2] https://issues.apache.org/jira/browse/INFRA-16727



-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

[Arpit Agarwal]

-1 for the force push. Nothing is broken in trunk. The history looks ugly for 
two commits and we can live with it.

The revert restored the branch to Giovanni's intent. i.e. only YARN-8435 is 
applied. Verified there is no delta between hashes 0d9804d and 39ad989 (HEAD).

39ad989 2018-07-05 aengineer@ o {apache/trunk} Revert "Merge branch 't...
c163d17 2018-07-05 gifuma@apa M─┐ Merge branch 'trunk' of https://git-...
99febe7 2018-07-05 rkanter@ap │ o YARN-7451. Add missing tests to veri...
1726247 2018-07-05 haibochen@ │ o YARN-7556. Fair scheduler configurat...
0d9804d 2018-07-05 gifuma@apa o │ YARN-8435. Fix NPE when the same cli...
71df8c2 2018-07-05 nanda@apac o─┘ HDDS-212. Introduce NodeStateManager...

Regards,
Arpit


On 7/5/18, 2:37 PM, "Subru Krishnan"  wrote:

Folks,

There was a merge commit accidentally pushed to trunk, you can find the
details in the mail thread [1].

I have raised an INFRA ticket [2] to reset/force push to clean up trunk.

Can we have a quick vote for INFRA sign-off to proceed as this is blocking
all commits?

Thanks,
Subru

[1]

http://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201807.mbox/%3CCAHqguubKBqwfUMwhtJuSD7X1Bgfro_P6FV%2BhhFhMMYRaxFsF9Q%40mail.gmail.com%3E
[2] https://issues.apache.org/jira/browse/INFRA-16727

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

[Sean Busbey]

-1 (non-binding)

force pushes are extremely disruptive. there's no way to know who's
updated their local git repo to include these changes since the commit
went in. if a merge commit is so disruptive that we need to subject folks
to the inconvenience of a force push then we should have more tooling
in place to avoid them (like client side git hooks for all committers).

On Thu, Jul 5, 2018 at 4:37 PM, Subru Krishnan  wrote:
> Folks,
>
> There was a merge commit accidentally pushed to trunk, you can find the
> details in the mail thread [1].
>
> I have raised an INFRA ticket [2] to reset/force push to clean up trunk.
>
> Can we have a quick vote for INFRA sign-off to proceed as this is blocking
> all commits?
>
> Thanks,
> Subru
>
> [1]
> http://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201807.mbox/%3CCAHqguubKBqwfUMwhtJuSD7X1Bgfro_P6FV%2BhhFhMMYRaxFsF9Q%40mail.gmail.com%3E
> [2] https://issues.apache.org/jira/browse/INFRA-16727



-- 
busbey

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

Re: [DISCUSS]: securing ASF Hadoop releases out of the box

[Steve Loughran]

> On 6 Jul 2018, at 00:04, Eric Yang  wrote:
> 
> +1 on Non-routable IP idea.  My preference is to start in Hadoop-common to 
> minimize the scope and incrementally improve.  However, this will be 
> incompatible change for initial user experience on public cloud.  What would 
> be the right release vehicle for this work (3.2+ or 4.x)?

3.2+

as for public cloud, that's precisely where you don't want to be wide open 
unless you are in some VPN setup. If you can't set up network rules here, 
should you be trying to install ASF hadoop out the box into a VM.

We should ping the Bigtop people here for their input.

> 
> Regards,
> Eric
> 
> On 7/5/18, 2:33 PM, "larry mccay"  wrote:
> 
>+1 from me as well.
> 
>On Thu, Jul 5, 2018 at 5:19 PM, Steve Loughran 
>wrote:
> 
>> 
>> 
>>> On 5 Jul 2018, at 23:15, Anu Engineer  wrote:
>>> 
>>> +1, on the Non-Routable Idea. We like it so much that we added it to the
>> Ozone roadmap.
>>> https://issues.apache.org/jira/browse/HDDS-231
>>> 
>>> If there is consensus on bringing this to Hadoop in general, we can
>> build this feature in common.
>>> 
>>> --Anu
>>> 
>> 
>> 
>> +1 to out the box, everywhere. Web UIs included
>> 
>> 
>> -
>> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
>> For additional commands, e-mail: common-dev-h...@hadoop.apache.org
>> 
>> 
> 
> 


-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org