[jira] [Created] (HADOOP-9498) ActiveStandbyElector doesn't work with secure ZooKeeper
nemon lou created HADOOP-9498: - Summary: ActiveStandbyElector doesn't work with secure ZooKeeper Key: HADOOP-9498 URL: https://issues.apache.org/jira/browse/HADOOP-9498 Project: Hadoop Common Issue Type: Bug Components: ha Affects Versions: 2.0.3-alpha Reporter: nemon lou When security is enabled for ZooKeeper, client will receive SaslAuthenticated or AuthFailed event from server side. As for now ActiveStandbyElector does not know these events ,it then raise fatalError and exit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Getting to Hadoop 2.X beta
On 23 April 2013 17:25, Roman Shaposhnik wrote: > Hi! > > Now that Hadoop 2.0.4-alpha is released I'd like > to open up a discussion on what practical steps > would it take for us as a community to get > Hadoop 2.X from alpha to beta? > > There's quite a few preconditions to be met for a piece of > software to reach beta status. Quite a few of them are now > being discussed in a neighboring thread 'Compatibility in > Apache Hadoop' ( http://s.apache.org/VE1 ) but I'd like to > kick off a broader discussion: what do you think a *complete* > list should look like, before we can honestly signal this > change to the rest of the world. > > It would be very nice if the things that are offered as part > of the criteria are easily quantifiable, but lets brainstorm > first anyway. We can always stack-rank and quantify later. > > I need to get YARN-117 in before the service lifecycle is frozen forever
[jira] [Created] (HADOOP-9499) TestWebHdfsUrl timeouts too conservative for Windows
Arpit Agarwal created HADOOP-9499: - Summary: TestWebHdfsUrl timeouts too conservative for Windows Key: HADOOP-9499 URL: https://issues.apache.org/jira/browse/HADOOP-9499 Project: Hadoop Common Issue Type: Bug Components: test Affects Versions: 3.0.0 Reporter: Arpit Agarwal Assignee: Arpit Agarwal Fix For: 3.0.0 TestWebHdfsUrl#testSecureAuthParamsInUrl fails with timeout. The 4 second timeout is too low when I test in a Windows VM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-9500) TestUserGroupInformation#testGetServerSideGroups fails on Windows due to failure to find winutils.exe
Chris Nauroth created HADOOP-9500: - Summary: TestUserGroupInformation#testGetServerSideGroups fails on Windows due to failure to find winutils.exe Key: HADOOP-9500 URL: https://issues.apache.org/jira/browse/HADOOP-9500 Project: Hadoop Common Issue Type: Bug Components: test Affects Versions: 3.0.0 Reporter: Chris Nauroth Assignee: Chris Nauroth The test attempts to run the winutils groups command, but the initialization logic fails to find the path to winutils.exe. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HADOOP-9498) ActiveStandbyElector doesn't work with secure ZooKeeper
[ https://issues.apache.org/jira/browse/HADOOP-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Lipcon resolved HADOOP-9498. - Resolution: Duplicate > ActiveStandbyElector doesn't work with secure ZooKeeper > --- > > Key: HADOOP-9498 > URL: https://issues.apache.org/jira/browse/HADOOP-9498 > Project: Hadoop Common > Issue Type: Bug > Components: ha >Affects Versions: 2.0.3-alpha >Reporter: nemon lou > > When security is enabled for ZooKeeper, > client will receive SaslAuthenticated or AuthFailed event from server side. > As for now ActiveStandbyElector does not know these events ,it then raise > fatalError and exit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-9501) Change ls command to display and execute and sticky bit permission.
Brandon Li created HADOOP-9501: -- Summary: Change ls command to display and execute and sticky bit permission. Key: HADOOP-9501 URL: https://issues.apache.org/jira/browse/HADOOP-9501 Project: Hadoop Common Issue Type: Bug Components: fs Affects Versions: 3.0.0 Reporter: Brandon Li Assignee: Brandon Li Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HADOOP-9458) In branch-1, RPC.getProxy(..) may call proxy.getProtocolVersion(..) without retry
[ https://issues.apache.org/jira/browse/HADOOP-9458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun C Murthy resolved HADOOP-9458. --- Resolution: Fixed Fix Version/s: 1.2.0 +1 I just committed this, thanks Nic! Also, thanks to [~arpitgupta] for verifying this! > In branch-1, RPC.getProxy(..) may call proxy.getProtocolVersion(..) without > retry > - > > Key: HADOOP-9458 > URL: https://issues.apache.org/jira/browse/HADOOP-9458 > Project: Hadoop Common > Issue Type: Bug > Components: ipc >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE >Priority: Critical > Fix For: 1.2.0 > > Attachments: c9458_20130406.patch > > > RPC.getProxy(..) may call proxy.getProtocolVersion(..) without retry even > when client has specified retry in the conf. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Getting to Hadoop 2.X beta
On Wed, Apr 24, 2013 at 9:42 AM, Steve Loughran wrote: >> There's quite a few preconditions to be met for a piece of >> software to reach beta status. Quite a few of them are now >> being discussed in a neighboring thread 'Compatibility in >> Apache Hadoop' ( http://s.apache.org/VE1 ) but I'd like to >> kick off a broader discussion: what do you think a *complete* >> list should look like, before we can honestly signal this >> change to the rest of the world. >> >> It would be very nice if the things that are offered as part >> of the criteria are easily quantifiable, but lets brainstorm >> first anyway. We can always stack-rank and quantify later. >> > I need to get YARN-117 in before the service lifecycle is frozen forever We certainly need to get a list of blocker JIRAs for what would be our first beta release. This actually, raises a practical, question: what do we tag those? Or to put it another way: can we all agree that 2.0.5 should be our first beta release? Thanks, Roman.
[jira] [Resolved] (HADOOP-9502) chmod does not return error exit codes for some exceptions
[
https://issues.apache.org/jira/browse/HADOOP-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tsz Wo (Nicholas), SZE resolved HADOOP-9502.
Resolution: Fixed
Fix Version/s: 1.2.0
Hadoop Flags: Reviewed
I have committed this.
> chmod does not return error exit codes for some exceptions
> --
>
> Key: HADOOP-9502
> URL: https://issues.apache.org/jira/browse/HADOOP-9502
> Project: Hadoop Common
> Issue Type: Bug
> Components: fs
>Reporter: Ramya Sunil
>Assignee: Tsz Wo (Nicholas), SZE
>Priority: Minor
> Fix For: 1.2.0
>
> Attachments: c9502_20130424.patch
>
>
> When some dfs operations fail due to SnapshotAccessControlException, valid
> exit codes are not returned.
> E.g:
> {noformat}
> -bash-4.1$ hadoop dfs -chmod -R 755
> /user/foo/hdfs-snapshots/test0/.snapshot/s0
> chmod: changing permissions of
> 'hdfs://:8020/user/foo/hdfs-snapshots/test0/.snapshot/s0':org.apache.hadoop.hdfs.server.namenode.snapshot.SnapshotAccessControlException:
> Modification on read-only snapshot is disallowed
> -bash-4.1$ echo $?
> 0
> -bash-4.1$ hadoop dfs -chown -R hdfs:users
> /user/foo/hdfs-snapshots/test0/.snapshot/s0
> chown: changing ownership of
> 'hdfs://:8020/user/foo/hdfs-snapshots/test0/.snapshot/s0':org.apache.hadoop.hdfs.server.namenode.snapshot.SnapshotAccessControlException:
> Modification on read-only snapshot is disallowed
> -bash-4.1$ echo $?
> 0
> {noformat}
> Similar problems exist for some other exceptions such as SafeModeException.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-9503) Allow a configurable sleep between IPC client connect timeouts
Varun Sharma created HADOOP-9503: Summary: Allow a configurable sleep between IPC client connect timeouts Key: HADOOP-9503 URL: https://issues.apache.org/jira/browse/HADOOP-9503 Project: Hadoop Common Issue Type: Improvement Components: ipc Reporter: Varun Sharma Priority: Minor HADOOP 9106 introduced a configurable retry timeout when there are socket timeouts errors. Since the IPC client is used by a wide variety of applications including realtime/online ones (like hbase + hdfs), we sometimes need fast fail timeouts which are < 3 seconds. Achieving such a timeout for connect is very difficult with a 1 second sleep in b/w retries. It would be good to have a configurable parameter to reduce this sleep. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Getting to Hadoop 2.X beta
To add to it, here's what have been experiences as a disconnect during the release cycle of 2.0.4-alpha using BigTop 0.6.6 as the integration platform and management stack of choice: 1. Need for improved feedback from the downstream projects 2. Need for improved feedback from the DevOps Which boils down to getting sufficient buy-in from downstreams and devops communities that they are now willing to consider branch-2 as being landing spot for their Hadoop 2.X needs. I belive the recent effort around 2.0.4-alpha and BigTop 0.6.0 might be sufficient to convince both communities to: 1. migrate their Hadoop 2.X profiles to at least 2.0.4-alpha 2. start to run integration tests against Hadoop 2.X profile 3. start to publish Maven artifacts 4. in general agree to treat Hadoop 2.X issues with at least the same priority as the issues in default profiles are treated (which are mostly Hadoop 1.X profiles). that would be a good start. BigTop can certainly help with a lot of techicalities and moving parts of the process. That would require tighter coordination between releases, of course. The question I don't have an answer for is how to engage DevOps community. Thoughts? Cos On Wed, Apr 24, 2013 at 03:38PM, Roman Shaposhnik wrote: > On Wed, Apr 24, 2013 at 9:42 AM, Steve Loughran > wrote: > >> There's quite a few preconditions to be met for a piece of > >> software to reach beta status. Quite a few of them are now > >> being discussed in a neighboring thread 'Compatibility in > >> Apache Hadoop' ( http://s.apache.org/VE1 ) but I'd like to > >> kick off a broader discussion: what do you think a *complete* > >> list should look like, before we can honestly signal this > >> change to the rest of the world. > >> > >> It would be very nice if the things that are offered as part > >> of the criteria are easily quantifiable, but lets brainstorm > >> first anyway. We can always stack-rank and quantify later. > >> > > I need to get YARN-117 in before the service lifecycle is frozen forever > > We certainly need to get a list of blocker JIRAs for what would be > our first beta release. This actually, raises a practical, question: > what do we tag those? > > Or to put it another way: can we all agree that 2.0.5 should be our > first beta release? > > Thanks, > Roman. signature.asc Description: Digital signature
